导读：一个完整的大数据平台应该提供离线计算、即席查询、实时计算、实时查询这几个方面的功能，这些都离不开大数据的处理框架，那么如何针对不同大数据处理框架的类型进行比较和选择呢？

科技改变世界

“科技改变世界”，这句话已经深入人心，科技渗透到各个领域，并且已经成为各行各业发展的重要元素。

毫无疑问，现在大家越来越重视科技，重视大数据。因为每一个数据的背后都代表着一个甚至无数个重要的隐藏信息，这些信息对于企业/个人鏖战商海起着至关重要的作用。而一个完整的大数据平台应该提供离线计算、即席查询、实时计算、实时查询这几个方面的功能，这些都离不开大数据的处理框架，那么如何针对大数据处理框架的类型进行比较和选择呢？

一、大数据简介

大家都知道，大数据并不仅仅只是字面上的意思，不能单纯的理解为数据大。我们先来简单介绍一下大数据的定义和特征：

大数据

1、大数据的定义

大数据（big data），指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新的处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

大数据的5V特点

2. 大数据的5V特点

大数据系统的基本需求与传统系统并没有本质上的不同。但大数据系统虽然具有海量的数据规模，但是对数据的接入和处理速度上也有较高的要求，而且在每个阶段都要对数据进行处理。这些特点也为设计解决方案提供了新的挑战，当然也会激发一切创新的可能性。

大数据5V特点 = Volume + Velocity + Variety + Value + Veracity

（1）Volume ：数据量大

第一个特征是数据量大，即数据信息量巨大，从TB级别跃升到PB级别。大数据的起始计量单位至少是P(1000个T)、E(100万个T)或Z(10亿个T)。

（2）Velocity： 数据处理速度快、时效高

第二个特征是处理速度快，时效性要求高。在数据处理速度方面，有一个著名的“1s定律”，也称为“秒级定律”，即要求在秒级这样的短时间范围内作出正确的数据分析，一旦超出这个时间，数据的价值也会因此大打折扣。这正是大数据区分于传统数据挖掘最显著的特征。

传统的数据处理方法，因为其既有的技术架构和路线，已经无法高效处理如此海量的数据，而对于相关组织来说，如果投入巨大采集的信息成本，却无法通过及时处理反馈有效信息，那将是得不偿失的。可以说，大数据时代对人类的数据驾驭能力提出了新的挑战，也为人们获得更为深刻、全面的洞察能力提供了前所未有的空间与机遇。

（3）Variety 数据多样性

第三个特征是数据多样性，即数据类型繁多，不仅包括传统的格式化数据，还包括来自互联网的网络日志、音频、视频、图片、地理位置信息等等，多类型的数据对数据的处理能力提出了更高的要求。

（4）

第四个特征是数据价值密度相对较低。如随着物联网的广泛应用，信息感知无处不在，信息海量，但价值密度较低，如何通过强大的机器算法更迅速地完成数据的价值“提纯”，是大数据时代亟待解决的难题。

（5）Veracity数据真实性

第五个特征是数据真实性，即更加强调真实有价值的数据，一些企业或者个人为了达到某种商业目的，或者是为了所谓的“面子工程”，可能会伪造数据，或者数据的来源过于单一性，这都会造成的数据的真实性存在质疑。

大数据处理流程

二、大数据处理流程

通过上文，我们简单的了解了大数据的概念，也明确了大数据的五大特征，那么大数据系统如何在实际中处理数据的呢?虽然不同公司的有着不同的架构设计，但基本流程是大致相同的，虽然接下来介绍的流程不适用于所有情况，但他们仍未大多数公司所使用。大数据处理的基本流程是：

1. 大数据采集

大数据的采集，又称为数据获取，是指从传感器和其它待测设备等模拟和数字被测单元中自动采集信息的过程，并且用户可以通过这些数据库来进行简单的查询和处理工作。比如，电商会使用传统的关系型数据库MySQL和Oracle等来存储每一笔事务数据，除此之外，Redis和MongoDB这样的NoSQL数据库也常用于数据的采集。

在大数据的采集过程中，其主要特点和挑战是并发数高，因为同时有可能会有成千上万的用户来进行访问和操作，比如火车票售票网站和购物网站，它们并发的访问量在峰值时达到上百万，所以需要在采集端部署大量数据库才能支撑。并且如何在这些数据库之间 进行负载均衡和分片的确是需要深入的思考和设计。

2. 大数据导入/预处理

数据预处理的三个核心步骤是：清洗，转换，简化。虽然采集端本身会有很多数据库，但是如果要对这些海量数据进行有效的分析，还是应该将这些来自前端的数据导入到一个集中的大型的分布式数据库，或者分布式存储集群，并且可以在导入基础上做一些简单的清洗和预处理工作。

许多入门教程在导入数据时只教如何导入预处理过的数据，例如手写体数字或者电影评分数据，用一行代码就能搞定，但实际操作没那么简单。遇到实际问题，都需要先找到正确的数据集，最终预测的结论依赖于最初导入的数据。导入与预处理过程的特点和挑战主要是导入的数据量大，每秒钟的导入量经常会达到百兆，甚至千兆级别。

3. 大数据统计/分析

在大数据时代，统计是数据分析的灵魂。统计与分析主要利用分布式数据库，或者分布式计算集群来对存储于其内的海量数据进行普通的分析和分类汇总等，以满足大多数常见的分析需求，在这方面，一些实时性需求会用到EMC的GreenPlum、Oracle的Exadata，以及基于 MySQL的列式存储Infobright等，而一些批处理，或者基于半结构化数据的需求可以使用Hadoop。统计与分析这部分的主要特点和挑战是分析涉及的数据量大，其对系统资源，特别是I/O会有极大的占用。

4. 大数据挖掘

与前面统计和分析过程不同的是，数据挖掘一般没有什么预先设定好的主题，数据挖掘基于数据库理论，机器学习，人工智能，现代统计学等，从海量的数据中发现隐含的知识和规律，在很多领域中都有应用。比较典型算法有用于聚类的Kmeans、用于统计学习的SVM和用于分类的NaiveBayes，主要使用的工具有Hadoop的Mahout等。该过程的特点和挑战主要是用于挖掘的算法很复杂，并且计算涉及的数据量和计算量都很大，常用数据挖掘算法都以单线程为主。

普遍的大数据处理流程至少应该满足这以上四个点的步骤，才能算得上是一个比较完整的大数据处理过程。当然，更加深入研究大数据流程的话，还会有更多有特点的、更加深入的、更加专业的大数据分析方法。

5、数据质量和数据管理

大数据分析离不开数据质量和数据管理，高质量的数据和有效的数据管理，无论是在学术研究还是在商业应用领域，都能够保证分析结果的真实和有价值。大数据最重要的应用领域之一就是预测性分析，从大数据中挖掘出特点，通过科学的建立模型，之后便可以通过模型带入新的数据，从而预测未来的数据。

三、大数据处理框架

分析了这么多大数据的方方面面，让大家对大数据有个基本的了解，我们接下来来聊一聊本文的重点——大数据处理框架。

1、大数据框架的定义

大数据处理框架负责对大数据系统中的数据进行计算。数据包括从持久存储中读取的数据或通过消息队列等方式接入到系统中的数据。大数据框架作为大数据系统一个最基本的组件。处理框架负责对系统中的数据进行计算，例如处理从非易失存储中读取的数据，或处理刚刚摄入到系统中的数据。数据的计算则是指从大量单一数据点中提取信息和见解的过程。除了大数据处理框架，我们可能还听到过“大数据计算框架”、“大数据框架”，这些术语没有严格的区分，但基本可以理解为是一种东西，只不过是对“big data processing framework”不同的翻译(大数据框架是“big data framework”的翻译)。

（1）“引擎”和“框架”的区别与联系

还有一个名词是“大数据处理引擎”，那么这个“引擎”和我们说的“框架”又有什么关系呢?非结构化数据的多元化给数据分析带来新的挑战和机遇，我们也需要一套更为系统号的工具的去分析数据，提炼数据。大数据处理引擎需要设计到有足够的人工智能，让气足以从数据中主动地提取有价值的信息。

其实并没有关于区分两者概念的权威官方说法，但一般来说，前者是实际负责处理操作的组件，而后者可以理解为用来完成同样工作的一系列组件。

接下来将为大家介绍这些框架：

仅批处理框架：

• Apache Hadoop

仅流处理框架：

• Apache Storm

• Apache Samza

混合框架：

• Apache Spark

• Apache Flink

四、不同的大数据处理框架分析 -

接下来我们将着重介绍以下大数据框架，按照对所处理的数据形式和得到结果的时效性分类，数据处理框架可以分为两类，从不同方面分析他们，希望能为大家在选择不同处理框架时。

1、仅批处理框架

（1）批处理框架简介

批处理是一种用来计算大规模数据集的方法。批处理的过程包括将一个大的任务分解为较小的任务，分别在集群中的每个计算机上进行计算，根据中间结果重新组合数据，然后计算和组合最终结果。

（2）批处理框架特征

批处理系统中的数据集一般符合以下特征：

• ①、有限性：批处理数据集代表数据的有限集合(无限的数据，数据之所以无限，因为他不是一批量可以处理完成的，连续不断的数据一般会使用流处理系统来进行处理，后面会提到)

• ②、持久性：批处理系统处理的数据，一般存储在持久存储系统上(比如存储在硬盘上、数据库中)

• ③、海量性：极海量的数据通常只能使用批处理系统来进行集中处理。批处理系统在设计之初就充分的考虑了数据量巨大的问题，实际上批处理系统也是为此而生的。

（3）适用对象：海量的持久数据

当处理非常巨大的数据集时，批处理系统最为有效。批处理系统在大数据世界中有着悠久的历史。批处理系统主要适合操作大量的、静态的数据，而且要等到这一批量处理完成后，才能得到相应的处理结果。

由于批处理系统在处理海量的持久数据方面的出色表现，所以批处理系统常常被用来处理历史记录信息。例如：很多OLAP(在线分析处理)系统的底层计算框架就是使用的批处理系统，但是由于处理海量数据需要耗费很多时间，所以批处理系统一般不适合用于对延时要求较高的场景数据。

Apache Hadoop框架

2、Apache Hadoop

说起大数据处理框架，永远也绕不开Hadoop。Hadoop的处理功能来自MapReduce引擎。MapReduce的处理技术符合使用键值对的map、shuffle、reduce算法要求。

（1）基本处理过程包括：

• ①、 从HDFS文件系统读取数据集

• ②、将数据集拆分成小块并分配给所有可用节点

• ③、 针对每个节点上的数据子集进行计算(计算的中间态结果会重新写入HDFS)

• ④、重新分配中间态结果并按照键进行分组

• ⑤、通过对每个节点计算的结果进行汇总和组合对每个键的值进行“Reducing”

• ⑥、将计算而来的最终结果重新写入 HDFS

Hadoop分布式文件系统HDFS：HDFS是一种分布式文件系统，它具有很高的容错性，适合部署在廉价的机器集群上。HDFS能提供高吞吐量的数据访问，非常适合在大规模数据集上使用。它可以用于存储数据源，也可以存储计算的最终结果。

资源管理器YARN：YARN可以为上层应用提供统一的资源管理和调度，它可以管理服务器的资源(主要是CPU和内存)，并负责调度作业的运行。在Hadoop中，它被设计用来管理MapReduce的计算服务。但现在很多其他的大数据处理框架也可以将YARN作为资源管理器，比如Spark。

MapReduce：即为Hadoop中默认的数据处理引擎，也是Google的MapReduce论文思想的开源实现。使用HDFS作为数据源，使用YARN进行资源管理。

3、批处理框架的

由于这种方法严重依赖持久存储，每个任务需要多次执行读取和写入操作，因此速度相对较慢。但另一方面由于磁盘空间通常是服务器上最丰富的资源，这意味着MapReduce可以处理非常海量的数据集。同时也意味着相比其他类似技术，Hadoop的MapReduce通常可以在廉价硬件上运行，因为该技术并不需要将一切都存储在内存中。MapReduce具备极高的缩放潜力，生产环境中曾经出现过包含数万个节点的应用。

MapReduce的学习曲线较为陡峭，虽然Hadoop生态系统的其他周边技术可以大幅降低这一问题的影响，但通过Hadoop集群快速实现某些应用时依然需要注意这个问题。

围绕Hadoop已经形成了辽阔的生态系统，Hadoop集群本身也经常被用作其他软件的组成部件。很多其他处理框架和引擎通过与Hadoop集成也可以使用HDFS和YARN资源管理器。

4、批处理框架总结

从今天的眼光来看，MapReduce作为Hadoop默认的数据处理引擎，存在着很多的不足。比如：编程模型抽象程度较低，仅支持Map和Reduce两种操作，需要手工编写大量的代码;Map的中间结果需要写入磁盘，多个MR之间需要使用HDFS交换数据，因此不适合迭代计算(机器学习、图计算);任务的启动和调度开销较大等。随着更多高性能处理引擎的发展，目前在企业中使用MapReduce进行计算的应用已经呈下降趋势(HDFS及YARN仍然被广泛使用)，但虽然如此，MapReduce作为最早的大数据处理引擎，仍然值得被我们铭记。

五、不同的大数据处理框架分析 - 仅流处理框架

1、流处理框架

（1）、流处理框架定义

我们了解了批处理框架的定义，那么什么是流处理框架的定义呢？

小学的时候可能我们经常会遇到这样的数学题类型：

一个水池有一个进水管和一个出水管，只打开进水管8个小时充满水，只打开出水管6个小时流光水，那么同时打开进水管和出水管，水池多长时间充满水?

看到这里，大家是不是在各种列方程式来解答这道题呢？大家的答案不知道是否和我的一样，这个水池永远也充不满！因为出水管出水比较快。

“流处理系统”就相当于这个“水池”，把流进来的“水”就相当于“数据”，比如我们加“盐”让他变成“盐水”，然后再把加工过“盐水”，即“处理过的数据”，从出水管放出去。这样，数据就像水流一样永不停止，而且在水池中就被处理过了。举这个例子大家是不是更好理解一点呢？所以，这种处理永不停止的接入数据的系统就叫做流处理系统。

（2）、流处理系统的方法

流处理系统与批处理系统所处理的数据不同之处在于，流处理系统并不对已经存在的数据集进行操作，而是对从外部系统接入的的数据进行处理。流处理系统可以分为两种：

• ①、逐项处理： 每次处理一条数据，是真正意义上的流处理。

• ②、微批处理： 这种处理方式把一小段时间内的数据当作一个微批次，对这个微批次内的数据进行处理。

（3）、流处理数据的影响

流处理中的数据集是“无边界”的，这就产生了几个重要的影响：

• ①、完整数据集只能代表截至目前已经进入到系统中的数据总量。

• ②、工作数据集也许更相关，在特定时间只能代表某个单一数据项。

• ③、处理工作是基于事件的，除非明确停止否则没有“尽头”。

• ④、处理结果立刻可用，并会随着新数据的抵达继续更新。

（4）、流处理适应对象：（几乎）无限量的且需要响应的数据

流处理系统可以处理几乎无限量的数据，但同一时间只能处理一条(真正的流处理)或很少量(微批处理，Micro-batch Processing)数据，不同记录间只维持最少量的状态。虽然大部分系统提供了用于维持某些状态的方法，但流处理主要针对副作用更少，更加功能性的处理(Functional processing)进行优化。

功能性操作主要侧重于状态或副作用有限的离散步骤。针对同一个数据执行同一个操作会或略其他因素产生相同的结果，此类处理非常适合流处理，因为不同项的状态通常是某些困难、限制，以及某些情况下不需要的结果的结合体。因此虽然某些类型的状态管理通常是可行的，但这些框架通常在不具备状态管理机制时更简单也更高效。

此类处理非常适合某些类型的工作负载。有近实时处理需求的任务很适合使用流处理模式。分析、服务器或应用程序错误日志，以及其他基于时间的衡量指标是最适合的类型，因为对这些领域的数据变化做出响应对于业务职能来说是极为关键的。流处理很适合用来处理必须对变动或峰值做出响应，并且关注一段时间内变化趋势的数据。

Apache Storm

2、Apache Storm

（1）Apache Storm概念

Apache Storm是一种侧重于低延迟的流处理框架，它可以处理海量的接入数据，以近实时方式处理数据。Storm延时可以达到亚秒级。

Storm含有如下关键概念：

在Storm中，先要设计一个用于实时计算的图状结构，我们称之为拓扑（topology）。Storm的流处理可对框架中名为Topology(拓扑)的DAG(Directed Acyclic Graph，有向无环图)进行编排。这些拓扑描述了当数据片段进入系统后，需要对每个传入的片段执行的不同转换或步骤。

这个拓扑将会被提交给集群，由集群中的主控节点（master node）分发代码，将任务分配给工作节点（worker node）执行。一个拓扑中包括spout和bolt两种角色，其中spout发送消息，负责将数据流以tuple元组的形式发送出去；而bolt则负责转换这些数据流，在bolt中可以完成计算、过滤等操作，bolt自身也可以随机将数据发送给其他bolt。由spout发射出的tuple是不可变数组，对应着固定的键值对。

拓扑包含：

• ①、Stream：普通的数据流，这是一种会持续抵达系统的无边界数据。

• ②、Spout：位于拓扑边缘的数据流来源，例如可以是API或查询等，从这里可以产生待处理的数据。

• ③、Bolt：Bolt代表需要消耗流数据，对其应用操作，并将结果以流的形式进行输出的处理步骤。Bolt需要与每个Spout建立连接，随后相互连接以组成所有必要的处理。在拓扑的尾部，可以使用最终的Bolt输出作为相互连接的其他系统的输入。

（2）、Storm优势和局限

目前来说Storm可能是近实时处理领域的最佳解决方案。该技术可以用极低延迟处理数据，可用于希望获得最低延迟的工作负载。如果处理速度直接影响用户体验，例如需要将处理结果直接提供给访客打开的网站页面，此时Storm将会是一个很好的选择。

Storm与Trident配合使得用户可以用微批代替纯粹的流处理。虽然借此用户可以获得更大灵活性打造更符合要求的工具，但同时这种做法会削弱该技术相比其他解决方案最大的优势。话虽如此，但多一种流处理方式总是好的。

Core Storm无法保证消息的处理顺序。Core Storm为消息提供了“至少一次”的处理保证，这意味着可以保证每条消息都能被处理，但也可能发生重复。Trident提供了严格的一次处理保证，可以在不同批之间提供顺序处理，但无法在一个批内部实现顺序处理。

Trident拓扑包含：

• ①、流批(Stream batch)：这是指流数据的微批，可通过分块提供批处理语义。

• ②、操作(Operation)：是指可以对数据执行的批处理过程。

在互操作性方面，Storm可与Hadoop的YARN资源管理器进行集成，因此可以很方便地融入现有Hadoop部署。除了支持大部分处理框架，Storm还可支持多种语言，为用户的拓扑定义提供了更多选择。

（3）、Storm优势和局限

目前来说Storm可能是近实时处理领域的最佳解决方案。该技术可以用极低延迟处理数据，可用于希望获得最低延迟的工作负载。如果处理速度直接影响用户体验，例如需要将处理结果直接提供给访客打开的网站页面，此时Storm将会是一个很好的选择。

Storm与Trident配合使得用户可以用微批代替纯粹的流处理。虽然借此用户可以获得更大灵活性打造更符合要求的工具，但同时这种做法会削弱该技术相比其他解决方案最大的优势。话虽如此，但多一种流处理方式总是好的。

Core Storm无法保证消息的处理顺序。Core Storm为消息提供了“至少一次”的处理保证，这意味着可以保证每条消息都能被处理，但也可能发生重复。Trident提供了严格的一次处理保证，可以在不同批之间提供顺序处理，但无法在一个批内部实现顺序处理。

在互操作性方面，Storm可与Hadoop的YARN资源管理器进行集成，因此可以很方便地融入现有Hadoop部署。除了支持大部分处理框架，Storm还可支持多种语言，为用户的拓扑定义提供了更多选择。

（4）、Storm总结

对于延迟需求很高的纯粹的流处理工作负载，Storm可能是最适合的技术。该技术可以保证每条消息都被处理，可配合多种编程语言使用。由于Storm无法进行批处理，如果需要这些能力可能还需要使用其他软件。如果对严格的一次处理保证有比较高的要求，此时可考虑使用Trident。不过这种情况下其他流处理框架也许更适合。

Samza

3、Apache Samza

（1）Apache Samza概念

Samza处理数据流时，会分别按次处理每条收到的消息。Samza的流单位既不是元组，也不是Dstream，而是一条条消息。在Samza中，数据流被切分开来，每个部分都由一组只读消息的有序数列构成，而这些消息每条都有一个特定的ID（offset）。该系统还支持批处理，即逐次处理同一个数据流分区的多条消息。Samza的执行与数据流模块都是可插拔式的，尽管Samza的特色是依赖Hadoop的Yarn（另一种资源调度器）和Apache Kafka。所以提到Apache Samza，就不得不提到当前最流行的大数据消息中间件：Apache Kafka。Apache Kafka是一个分布式的消息中间件系统，具有高吞吐、低延时等特点，并且自带了容错机制。

Kafka

以下是Kafka的关键概念：

• ①、Broker：由于Kafka是分布式消息中间件，所以需要多个节点来存储数据。Broker即为Kafka集群中的单个节点。

• ②、Topic：用于存储写入Kafka的数据流。如同它的字面含义——主题，不同主题的数据流最好写入不同的topic，方便后续的处理。

• ③、Partition：每个topic都有1到多个partition，便于分散到不同的borker中。多个partition的数据合并在一起组成了topic完整的数据。

• ④、Producer：消息的生产者，用来将消息写入到Kafka集群。

• ⑤、Consumer：消息的消费者，用来读取Kafka中的消息并进行处理。

虽然Kafka被广泛应用于各种流处理系统做数据源，但Samza可以更好的发挥Kafka架构的优势。根据官网的解释，Samza由三个层次组成：

①.数据流层、②.执行层、③.处理层

性对应的支持三个层次的组件分别为：①.Kafka、②.YARN、③.Samza API

（2）、Samza优势和局限

也就是说，Samza使用Kafka提供了数据流，使用YARN进行资源管理，自身仅提供了操作数据流的API。Samza对Kafka和YARN的依赖在很多方面上与MapReduce对HDFS和YARN的依赖相似。

如果已经拥有Hadoop集群和Kafka集群环境，那么使用Samza作为流处理系统无疑是一个非常好的选择。由于可以很方便的将处理过的数据再次写入Kafka，Samza尤其适合不同团队之间合作开发，处理不同阶段的多个数据流。

乍看之下，Samza对Kafka类查询系统的依赖似乎是一种限制，然而这也可以为系统提供一些独特的保证和功能，这些内容也是其他流处理系统不具备的。

例如Kafka已经提供了可以通过低延迟方式访问的数据存储副本，此外还可以为每个数据分区提供非常易用且低成本的多订阅者模型。所有输出内容，包括中间态的结果都可写入到Kafka，并可被下游步骤独立使用。

这种对Kafka的紧密依赖在很多方面类似于MapReduce引擎对HDFS的依赖。虽然在批处理的每个计算之间对HDFS的依赖导致了一些严重的性能问题，但也避免了流处理遇到的很多其他问题。

Samza与Kafka之间紧密的关系使得处理步骤本身可以非常松散地耦合在一起。无需事先协调，即可在输出的任何步骤中增加任意数量的订阅者，对于有多个团队需要访问类似数据的组织，这一特性非常有用。多个团队可以全部订阅进入系统的数据话题，或任意订阅其他团队对数据进行过某些处理后创建的话题。这一切并不会对数据库等负载密集型基础架构造成额外的压力。

直接写入Kafka还可避免回压(Backpressure)问题。回压是指当负载峰值导致数据流入速度超过组件实时处理能力的情况，这种情况可能导致处理工作停顿并可能丢失数据。按照设计，Kafka可以将数据保存很长时间，这意味着组件可以在方便的时候继续进行处理，并可直接重启动而无需担心造成任何后果。

Samza可以使用以本地键值存储方式实现的容错检查点系统存储数据。这样Samza即可获得“至少一次”的交付保障，但面对由于数据可能多次交付造成的失败，该技术无法对汇总后状态(例如计数)提供精确恢复。

Samza提供的高级抽象使其在很多方面比Storm等系统提供的基元(Primitive)更易于配合使用。目前Samza只支持JVM语言，这意味着它在语言支持方面不如Storm灵活。

（3）、Samza总结

对于已经具备或易于实现Hadoop和Kafka的环境，Apache Samza是流处理工作负载一个很好的选择。Samza本身很适合有多个团队需要使用(但相互之间并不一定紧密协调)不同处理阶段的多个数据流的组织。Samza可大幅简化很多流处理工作，可实现低延迟的性能。如果部署需求与当前系统不兼容，也许并不适合使用，但如果需要极低延迟的处理，或对严格的一次处理语义有较高需求，此时依然适合考虑。

六、批处理系统与流处理系统的联系与区别

不论是哪种处理方式，其实时性都要远远好于批处理系统。因此，流处理系统非常适合应用于对实时性要求较高的场景，比如日志分析，设备监控、网站实时流量变化等等。由于很多情况下，我们想要尽快看到计算结果，所以近些年流处理系统的应用越来越广泛。

七、混合处理系统：批处理和流处理

一些处理框架既可以进行批处理，也可以进行流处理。这种情况我们可以把它称之为混合处理系统。这些框架可以使用相同或相关的API处理历史和实时数据。当前主流的混合处理框架主要为Spark和Flink。

虽然专注于一种处理方式可能非常适合特定场景，但是混合框架为数据处理提供了通用的解决方案。

Apache Spark

1、Apache Spark

如果说如今大数据处理框架处于一个群星闪耀的年代，那Spark无疑就是所有星星中最闪亮的那一颗。

（1）、Apache Spark的概念

Spark Streaming是核心Spark API的一个扩展，它并不会像Storm那样一次一个地处理数据流，而是在处理前按时间间隔预先将其切分为一段一段的批处理作业。Spark针对持续性数据流的抽象称为DStream（DiscretizedStream），一个DStream是一个微批处理（micro-batching）的RDD（弹性分布式数据集）；而RDD则是一种分布式数据集，能够以两种方式并行运作，分别是任意函数和滑动窗口数据的转换。

（2）Spark的优势

Spark由加州大学伯克利分校AMP实验室开发，最初的设计受到了MapReduce思想的启发，但不同于MapReduce的是，Spark通过内存计算模型和执行优化大幅提高了对数据的处理能力(在不同情况下，速度可以达到MR的10-100倍，甚至更高)。相比于MapReduce，Spark具有如下优点：

提供了内存计算模型RDD(Resilient Distributed Dataset，弹性分布式数据集)，将数据读入内存中生成一个RDD，再对RDD进行计算。并且每次计算结果可以缓存在内存中，减少了磁盘IO。因此很适用于迭代计算。

不同于MapReduce的MR模型，Spark采用了DAG编程模型，将不同步骤的操作串联成一个有向无环图，可以有效减少任务间的数据传递，提高了性能。

提供了丰富的编程模型，可以轻松实现过滤、连接、聚合等操作，代码量相比MapReduce少到令人发指，因此可以提高开发人员的生产力。

支持Java、Scala、Python和R四种编程语言，为不同语言的使用者降低了学习成本。

而Spark的流处理能力，则是由Spark Streaming模块提供的。Spark在设计之初与MapReduce一样是用于批处理系统，为了适应于流处理模式，Spark提出了微批次(Micro-Batch)的概念，即把一小段时间内的接入数据作为一个微批次来处理。这样做的优点是在设计Spark Streaming时可以很大程度上重用批处理模块(Spark Core)的代码，开发人员也不必学习两套编程模型。但缺点就是，与Storm等原生的流处理系统相比，Spark Streaming的延时会相对高一些。

除了最初开发用于批处理的Spark Core和用于流处理的Spark Streaming，Spark还提供了其他编程模型用于支持图计算(GraphX)、交互式查询(Spark SQL)和机器学习(MLlib)。

（3）Spark的局限性

但Spark也不是没有缺点。在批处理领域，由于内存是比硬盘更昂贵的资源，所以Spark集群的成本比MapReduce集群更高。而在流处理领域，微批次的架构使得它的延时要比Storm等流处理系统略高。不过瑕不掩瑜，Spark依然是如今最炙手可热的数据处理框架。

Apache Flink

2、Apache Flink

有趣的是，同样作为混合处理框架，Flink的思想与Spark是完全相反的：Spark把流拆分成若干个小批次来处理，而Flink把批处理任务当作有界的流来处理。其本质原因是，Spark最初是被设计用来进行批处理的，而Flink最初是被设计用来进行流处理的。这种流处理优先的方式叫做Kappa架构，与之相对的使用批处理优先的架构叫做Lambda架构。Kappa架构会使用处理流的方式处理一切，以此来简化编程模型。这一切是在最近流处理引擎逐渐成熟起来才有可能实现的。

（1）Flink流处理模型

Flink的流处理模型将逐项输入的数据作为真实的流处理。Flink提供了DataStream API用于处理无尽的数据流。

Flink的基本组件包括：

①、Stream(流)是指在系统中流转的，永恒不变的无边界数据集

②、Operator：Operator(操作方)是指针对数据流执行操作以产生其他数据流的功能

③、Source：Source(源)是指数据流进入系统的入口点④、Sink：Sink是数据流(stream)流出Flink系统后的位置。

④、Sink(槽)是指数据流离开Flink系统后进入到的位置，槽可以是数据库或到其他系统的连接器

Flink的流处理思想与Storm类似，以source接入数据，通过不同的operator进行transformation，最后输出到sink。

（3）、Flink的优势

与Spark相同，Flink也提供了较为完整的数据处理方式。除了上面介绍的流处理(DataStream API)和批处理(DataSet API)之外，Flink还提供了类SQL查询(Table API)、图计算(Gelly)和机器学习库(Flink ML)。而令人惊讶的是，在很多性能测试中，Flink甚至略优于Spark。

在目前的数据处理框架领域，Flink可谓独树一帜。虽然Spark同样也提供了批处理和流处理的能力，但Spark流处理的微批次架构使其响应时间略长。Flink流处理优先的方式实现了低延迟、高吞吐和真正逐条处理。

（4）、Flink局限性

同样，Flink也并不是完美的。Flink目前最大的缺点就是缺乏在大型公司实际生产项目中的成功应用案例。相对于Spark来讲，它还不够成熟，社区活跃度也没有Spark那么高。但假以时日，Flink必然会改变数据处理框架的格局。

（5）、Flink批处理模型

Flink的批处理模型在很大程度上仅仅是对流处理模型的扩展。此时模型不再从持续流中读取数据，而是从持久存储中以流的形式读取有边界的数据集。Flink会对这些处理模型使用完全相同的运行时。

Flink可以对批处理工作负载实现一定的优化。例如由于批处理操作可通过持久存储加以支持，Flink可以不对批处理工作负载创建快照。数据依然可以恢复，但常规处理操作可以执行得更快。

另一个优化是对批处理任务进行分解，这样即可在需要的时候调用不同阶段和组件。借此Flink可以与集群的其他用户更好地共存。对任务提前进行分析使得Flink可以查看需要执行的所有操作、数据集的大小，以及下游需要执行的操作步骤，借此实现进一步的优化。

（6）Flink批处理模型优势和局限

Flink目前是处理框架领域一个独特的技术。虽然Spark也可以执行批处理和流处理，但Spark的流处理采取的微批架构使其无法适用于很多用例。Flink流处理为先的方法可提供低延迟，高吞吐率，近乎逐项处理的能力。

Flink的很多组件是自行管理的。虽然这种做法较为罕见，但出于性能方面的原因，该技术可自行管理内存，无需依赖原生的Java垃圾回收机制。与Spark不同，待处理数据的特征发生变化后Flink无需手工优化和调整，并且该技术也可以自行处理数据分区和自动缓存等操作。

Flink会通过多种方式对工作进行分许进而优化任务。这种分析在部分程度上类似于SQL查询规划器对关系型数据库所做的优化，可针对特定任务确定最高效的实现方法。该技术还支持多阶段并行执行，同时可将受阻任务的数据集合在一起。对于迭代式任务，出于性能方面的考虑，Flink会尝试在存储数据的节点上执行相应的计算任务。此外还可进行“增量迭代”，或仅对数据中有改动的部分进行迭代。

在用户工具方面，Flink提供了基于Web的调度视图，借此可轻松管理任务并查看系统状态。用户也可以查看已提交任务的优化方案，借此了解任务最终是如何在集群中实现的。对于分析类任务，Flink提供了类似SQL的查询，图形化处理，以及机器学习库，此外还支持内存计算。

Flink能很好地与其他组件配合使用。如果配合Hadoop 堆栈使用，该技术可以很好地融入整个环境，在任何时候都只占用必要的资源。该技术可轻松地与YARN、HDFS和Kafka 集成。在兼容包的帮助下，Flink还可以运行为其他处理框架，例如Hadoop和Storm编写的任务。

目前Flink最大的局限之一在于这依然是一个非常“年幼”的项目。现实环境中该项目的大规模部署尚不如其他处理框架那么常见，对于Flink在缩放能力方面的局限目前也没有较为深入的研究。随着快速开发周期的推进和兼容包等功能的完善，当越来越多的组织开始尝试时，可能会出现越来越多的Flink部署。

总结

Flink提供了低延迟流处理，同时可支持传统的批处理任务。Flink也许最适合有极高流处理需求，并有少量批处理任务的组织。该技术可兼容原生Storm和Hadoop程序，可在YARN管理的集群上运行，因此可以很方便地进行评估。其快速开发的工作效率，引起人们的关注。

八、大数据处理框架的选择

1. 对于初学者

由于Apache Hadoop在大数据领域的广泛使用，因此仍推荐作为初学者学习数据处理框架的首选。虽然MapReduce因为性能原因以后的应用会越来越少，但是YARN和HDFS依然作为其他框架的基础组件被大量使用(比如HBase依赖于HDFS，YARN可以为Spark、Samza等框架提供资源管理)。学习Hadoop可以为以后的进阶打下基础。

Apache Spark在目前的企业应用中应该是当之无愧的王者。在批处理领域，虽然Spark与MapReduce的市场占有率不相上下，但Spark稳定上升，而MapReduce却稳定下降。而在流处理领域，Spark Streaming与另一大流处理系统Apache Storm共同占据了大部分市场(当然很多公司会使用内部研发的数据处理框架，但它们多数并不开源)。伯克利的正统出身、活跃的社区以及大量的商用案例都是Spark的优势。除了可用于批处理和流处理系统，Spark还支持交互式查询、图计算和机器学习。Spark在未来几年内仍然会是大数据处理的主流框架，推荐同学们认真学习。

另一个作为混合处理框架的Apache Flink则潜力无限，被称作“下一代数据处理框架”。虽然目前存在社区活跃度不够高、商用案例较少等情况，不过“是金子总会发光”，如果Flink能在商业应用上有突出表现，则可能挑战Spark的地位。

2. 对于企业应用

相较于稳定性而言，企业更关心的是敏捷性和创新性，通过大数据技术，可以帮助公司及时实现这一愿望。大数据分析不仅使企业能够跟随瞬息万变的潮流而不断更新，而且还具有预测未来发展趋势的能力，使企业占据有竞争力的优势。

如果企业中只需要批处理工作，并且对时间并不敏感，那么可以使用成本较其他解决方案更低的Hadoop集群。

如果企业仅进行流处理，并且对低延迟有着较高要求，Storm更加适合，如果对延迟不非常敏感，可以使用Spark Streaming。而如果企业内部已经存在Kafka和Hadoop集群，并且需要多团队合作开发(下游团队会使用上游团队处理过的数据作为数据源)，那么Samza是一个很好的选择。

如果需要同时兼顾批处理与流处理任务，那么Spark是一个很好的选择。混合处理框架的另一个好处是，降低了开发人员的学习成本，从而为企业节约人力成本。Flink提供了真正的流处理能力并且同样具备批处理能力，但商用案例较少，对于初次尝试数据处理的企业来说，大规模使用Flink存在一定风险。

全文总结：

通常，我们需要解决一件事情，首先应该明确事件基本情况、时间、结果。所以对于大数据如何选取适合的解决方案，主要取决于待处理数据的状态，对处理所需时间的需求，以及希望得到的结果。同时还需注意这个大数据项目的侧重点，了解这些，从自身实际经济情况出发，选择适合企业/个人的解决方案。

閱讀更多 數據先行者 的文章

關鍵字: 大数据 解析 解决方案