标签：处理 Flink MapReduce Hadoop 选型 Spark 数据 对比
公司要开搞大数据了，针对大数据的一般姿势做了个简单调研。
一、通用架构
二、组件选择
1、Hdfs、HBase
Hdfs：分布式文件存储，无缝对接所有大数据相关组件。高容错（多副本）、高吞吐。适合一次写入，多次读出。不适合低延迟读取、小文件存储（寻址时间超过读取时间）。
HBase：非关系型分布式数据库，基于Hdfs，高容错、高吞吐。HBase采用的是Key/Value的存储方式，即使随着数据量增大，也几乎不会导致查询的性能下降。
2、Flume、Sqoop
Flume：最主要的作用就是，实时读取服务器本地磁盘的数据，将数据写入到HDFS/Kafka/HBase。
Sqoop：用来在RDBMS和Hadoop之间进行数据传输的工具就是我们所说的Sqoop。在这里，RDBMS指的是MySQL，Oracle SQL等，而Hadoop指的是Hive，HDFS和HBase等。 我们使用Sqoop将数据从RDBMS导入Hadoop,也可用于将数据从Hadoop导出到RDBMS
3、Kafaka
高并发的基石。吞吐量远远领先于同类别的MQ。
LinkedIn团队做了个实验研究，对比Kafka与Apache ActiveMQ V5.4和RabbitMQ V2.4的性能
生产者 消费者
4、MapReduce & Hive & Spark & Flink & Beam
4.1、演变史
4.2、MapReduce 到 Hive 到 SparkSQL的演变
4.3、MapReduce 、 Spark 、Flink
MapReduce
Spark
Flink
MapReduce：
MapReduce 模型的抽象层次低，大量的底层逻辑都需要开发者手工完成。
只提供 Map 和 Reduce 两个操作。比如两个数据集的 Join 是很基本而且常用的功能，但是在 MapReduce 的世界中，需要对这两个数据集做一次 Map 和 Reduce 才能得到结果。
在 Hadoop 中，每一个 Job 的计算结果都会存储在 HDFS 文件存储系统中，所以每一步计算都要进行硬盘的读取和写入，大大增加了系统的延迟。
Spark：
Spark 最基本的数据抽象叫作弹性分布式数据集（Resilient Distributed Dataset, RDD），它代表一个可以被分区（partition）的只读数据集，它内部可以有很多分区，每个分区又有大量的数据记录（record）。
RDD 是 Spark 最基本的数据结构。Spark 定义了很多对 RDD 的操作。如 Map、Filter、flatMap、groupByKey 和 Union 等等，极大地提升了对各种复杂场景的支持。
相对于 Hadoop 的 MapReduce 会将中间数据存放到硬盘中，Spark 会把中间数据缓存在内存中，从而减少了很多由于硬盘读写而导致的延迟，大大加快了处理速度。
Flink
在 Flink 中，程序天生是并行和分布式的。一个 Stream 可以包含多个分区（Stream Partitions），一个操作符可以被分成多个操作符子任务，每一个子任务是在不同的线程或者不同的机器节点中独立执行的。
性能对比
可以看出，Hadoop 做每一次迭代运算的时间基本相同，而 Spark 除了第一次载入数据到内存以外，别的迭代时间基本可以忽略。
4.4、几种处理引擎对比
| API | 类SQL | 性能 | 容错性 | 实时性 | 批处理 | 流处理 | Exactly once语义 | 社区活跃度 | |
|---|---|---|---|---|---|---|---|---|---|
| MapReduce | 复杂 | 没有 | 低 | 低 | 低 | 中 | 不支持 | 无 | 低 |
| Hive | 简单 | 有 | 低 | 高 | 低 | 中 | 不支持 | 无 | 中 |
| Spark | 简单 | 有 | 高 | 高 | 中高（秒级） | 高 | 中 | 支持 | 高 |
| Flink | 简单 | 有 | 高 | 高 | 高（微妙级） | 中 | 高 | 支持 | 中 |
| Beam | 或者代表着未来。目前在谷歌内部使用、生态还没发展起来。拭目以待 | ||||||||
附1：
在流处理系统中，我们对应数据记录的处理，有3种级别的语义定义，以此来衡量这个流处理系统的能力。
- At most once（最多一次）。每条数据记录最多被处理一次，潜台词也表明数据会有丢失（没被处理掉）的可能。
- At least once（最少一次）。每条数据记录至少被处理一次。这个比上一点强的地方在于这里至少保证数据不会丢，至少被处理过，唯一不足之处在于数据可能会被重复处理。
- Exactly once（恰好一次）。每条数据记录正好被处理一次。没有数据丢失，也没有重复的数据处理。这一点是3个语义里要求最高的。
4.5、使用场景
MapReduce：仅仅用来学习，理解大数据的原理。
Hive：类SQL引擎，适合做报表分析
Spark： Spark 存在的一个缺点——无法高效应对低延迟的流处理场景入手。对于以下场景，你可以选择 Spark。
- 数据量非常大而且逻辑复杂的批数据处理，并且对计算效率有较高要求（比如用大数据分析来构建推荐系统进行个性化推荐、广告定点投放等）；
- 基于历史数据的交互式查询，要求响应较快；
- 基于实时数据流的数据处理，延迟性要求在在数百毫秒到数秒之间。
Spark 完美满足这些场景的需求， 而且它可以一站式解决这些问题，无需用别的数据处理平台。
Flink：由于 Flink 是为了提升流处理而创建的平台，所以它适用于各种需要非常低延迟（微秒到毫秒级）的实时数据处理场景，比如实时日志报表分析。
而且 Flink 用流处理去模拟批处理的思想，比 Spark 用批处理去模拟流处理的思想扩展性更好，所以我相信将来 Flink 会发展的越来越好，
生态和社区各方面追上 Spark。比如，阿里巴巴就基于 Flink 构建了公司范围内全平台使用的数据处理平台 Blink，美团、饿了么等公司也都接受 Flink 作为数据处理解决方案。
可以说，Spark 和 Flink 都在某种程度上统一了批处理和流处理。
三、任务分工
标签：处理,Flink,MapReduce,Hadoop,选型,Spark,数据,对比 来源： https://www.cnblogs.com/kbian/p/12343058.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。