【大数据】技术选型对比

公司要开搞大数据了，针对大数据的一般姿势做了个简单调研。

一、通用架构

二、组件选择

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 都在某种程度上统一了批处理和流处理。