前篇文章笔者已经对大数据的一些基本概念做了解释和分类。本篇主要对大数据处理中的一个重要的部分-计算引擎进行详细的介绍，内容不涉及具体计算处理细节，只关注各自特点及适用场景。
一、计算引擎时间轴
大数据计算引擎的发展历程主要分为四个阶段，目前主流的计算引擎是第三代Spark以及最近比较火的Flink。
1.第一代
Hadoop 承载的 MapReduce，将任务分成两个阶段，分别是map（切分）和reduce（合并），主要是批处理任务。
2.第二代
支持 DAG（有向无环图） 的框架：Tez 、Oozie，主要还是批处理任务。
3.第三代
Job 内部的 DAG（有向无环图）支持（不跨越 Job），以及强调的实时计算，代表Spark。
4.第四代
对流计算的支持，以及更一步的实时性：Flink。
如今，笔者测试的大数据处理平台计算层目前支持Spark和Flink两种计算引擎，资源调度依赖于YARN来执行，以实现批流合一（批量、流式的概念上篇文章已经介绍介绍）。
二、批处理-MR、Tez与Spark
1、MapReduce
MapReduce是利用磁盘的高I/O操作实现并行计算的框架 。它的2种Map 和 Reduce 的输与输出数据都是键值对〈key，value〉，可以用两个公式对它们进行简单的描述。
Map (k1，v1)→list(k2，v2) 公式1
Reduce (k2，list(v2))→list(v2) 公式2
在一个问题的计算过程中，Map操作将数据自动地进行分区，并分布到多台处理机上进行并行处理。Reduce 操作会根据中间数据的键值 key 通过分区函数(如 Hash函数)处理并分布到不同处理机上进行相同的计算。
shuffle阶段：将map的输出作为reduce的输入的过程就是shuffle了。Shuffle分为2个阶段。
a.Mapper 端的Shuffle：由 Mapper 产生的结果并不会直接写入到磁盘中，而是先存储在内存中，当内存中的数据量达到设定的阀值时，一次性写入到本地磁盘中。并同时进行 sort（排序）、combine（合并）、partition（分片）等操作。其中，sort 是把 Mapper 产生的结果按照 key 值进行排序；combine 是把key值相同的记录进行合并；partition 是把 数据均衡的分配给 Reducer。
b.Reducer 端的 Shuffle：由于Mapper和Reducer往往不在同一个节点上运行，所以 Reducer 需要从多个节点上下载Mapper的结果数据，并对这些数据进行处理，然后才能被 Reducer处理。
MR问题：
有些任务，比如词频统计(WordCount)可以通过一次 Map 和 Reduce 过程解决，但是单个 MapReduce 能够完成的操作毕竟有限，大部分复杂的问题就需要分解成多个MapReduce 过程。每个 Reduce 操作的结果 作为下一个 Map 操作的输入数据，在处理这种迭代计算时，由于MR必须先存储，后运算，在进行需要多次MR组合的计算时，每次MR除了Shuffle的磁盘开销外，Reduce之后也会写到磁盘，导致它在迭代计算中性能不足。
2、Tez
为了克服Hadoop MapReduce难以支持迭代计算的缺陷，Tez应运而生。Tez是Apache最新的支持DAG作业的开源计算框架，它可以将多个有依赖的作业转换为一个作业从而大幅提升DAG作业的性能。
3、Spark
Spark是一种基于内存的开源计算框架，它的作用相当于MapReduce，它是基于内存的计算引擎。Spark将迭代过程的中间数据缓存到内存中，根据需要多次重复使用。减少了硬盘读写，能够将多个操作进行合并后计算，因此提升了计算速度。
Spark的DAG实质上就是把计算和计算之间的编排变得更为细致紧密，使得很多MR任务中需要落盘的非Shuffle操作得以在内存中直接参与后续的运算，DAG相比Hadoop的MapReduce在大多数情况下可以减少shuffle次数。如果计算不涉及与其他节点进行数据交换，Spark可以在内存中一次性完成这些操作，也就是中间结果无须落盘，减少了磁盘IO的操作。
Spark的RDD是Spark中最主要的数据结构，可以直观的认为RDD就是要处理的数据集。RDD是分布式的数据集，每个RDD都支持MapReduce类操作，经过MapReduce操作后会产生新的RDD，而不会修改原有RDD。RDD的数据集是分区的，因此可以把每个数据分区放到不同的分区上进行计算，而实际上大多数MapReduce操作都是在分区上进行计算的。Spark不会把每一个MapReduce操作都发起运算，而是尽量的把操作累计起来一起计算。Spark把操作划分为转换（transformation）和动作（action），对RDD进行的转换操作会叠加起来，直到对RDD进行动作操作时才会发起计算。这种特性也使Spark可以减少中间结果的吞吐，可以快速的进行多次迭代计算。
Spark问题
Spark有如此多优点，但是如果数据超过1T了基本就不能用spark了，还是会选择MapReduce，成也内存，败也内存。如果数据过大，Spark就会粗心啊OOM内存溢出等问题。
三、实时处理-Spark straming与Flink
1、 Spark Streaming
Spark Streaming是Spark核心API的一个扩展，可以实现高吞吐量的、具备容错机制的实时流数据的处理。支持从多种数据源获取数据，包括Kafk、Flume、ZeroM等。
Spark Streaming在内部的处理机制是，接收实时流的数据，把数据按照batch size（如1秒）拆分一段一段的数据（Discretized Stream），每一段数据都转换成Spark中的RDD（Resilient Distributed Dataset），然后将Spark Streaming中对DStream的Transformation操作变为针对Spark中对RDD的Transformation操作，将RDD经过操作变成中间结果保存在内存中。整个流式计算根据业务的需求可以对中间的结果进行叠加或者存储到外部设备。下图显示了Spark Streaming的整个流程。
2、Flink
Apache Flink是一个面向数据流处理和批量数据处理的分布式的开源计算框架，其处理的主要场景就是流数据，批数据只是流数据的一个极限特例而已。它是真正的流处理引擎，是准实时的。
Flink的DataStream API，对数据流进行流处理操作，将流式的数据抽象成分布式的数据流，用户可以方便的采用Flink提供的各种操作符对分布式数据流进行各种操作。
Spark和Flink两种计算引擎而言，本身在设计思路上有很多差异点。Spark相比Flink是一个更为成熟的计算框架，Flink在实时计算能力方面有较多的改进和优势。在选择的时候应该从场景出发，对实时性要求较高的场景可以使用Flink，如果说对实时性要求不高，或者不是那么的高使用Spark就可以了。
总结
Hadoop MR主要针对大数据量的批处理任务，Spark针对数据量稍小点（小于1T）的批处理任务，处理速度相对MR快。Spark Straming计算模式是微批处理的，达到near 实时，相对Flink成熟稳定，Flink是real实时的计算框架，相对还不是十分成熟。
Q
本文转载自 360质量效能