Spark与Flink的对比

一、引言

• 随着大数据的普及，出现了许多的的流式处理框架，比如我们常用的Spark，Flink，Storm以及Samza，这里主要列举Spark和Flink的区别。
• 当提及大数据时，我们无法忽视流式计算的重要性，它能够完成强大的实时分析。而说起流式计算，我们也无法忽视最强大的数据处理引擎：Spark和Flink。
• Apache Spark自2014年以来迅速普及。它提供了一个适用常见数据处理场景的统一引擎，如批处理、流处理、交互式查询和机器学习。在某些情况下，它的性能是前一代Hadoop MapReduce的数百倍。凭借其高性能的处理和广泛的场景支持，它在大数据开发方面受到早期用户的长期青睐。
• 在Spark出现后不久，Apache Flink就作为强劲对手进入公众视野，并在2016年左右名声大噪。当Spark早期用户在实时流处理等场景中面临可用性问题时，Flink提供了一个支持各种场景的高级流处理引擎，Flink的优势还不仅仅于此。
• 在这场短暂的竞争中，Spark在持续优化它的实时流处理能力，2.3版（2月份）中引入了一个持续流处理模型，将流处理延迟降至毫秒级。同样，Flink也是一个强大的创新者。这两个框架中谁会成为定义下一代大数据计算的主流，这还有待观察。
• 为了阐明这个问题，本文将全面分析它们各自的技术和用途

二、Spark和Flink处理引擎

• 数据模型和处理模型

为了理解Spark和Flink引擎的特性，首先必须检查它们各自的数据模型。

Spark使用弹性分布式数据集（Resilient Distributed Dataset，RDD），RDD比MapReduce的文件模型更抽象，依赖于运算关系以确保可恢复性。RDD通常用于分布式共享内存或完全虚拟化，也就是说，当下游处理完全在本地时，可以对一些中间结果进行优化和省略。这节省了大量不必要的输入和输出，是Spark早期性能优势的主要基础。

Spark还使用RDD上的转换（操作符）来描述数据处理，每个操作符（如map、filter、join）生成一个新的RDD，所有的操作符形成一个有向无环图（Directed Acyclic Graph，DAG）。Spark简单地将图的边划分为2类：宽依赖和窄依赖。当上下游数据不需要混洗时，边是一个窄依赖。在这种情况下，上下游操作可以在同一个stage中进行本地处理，并且可以忽略上游结果RDD的物化，下图呈现了这里涉及的基本概念。

---

---

相比之下，Flink的基本数据模型由数据流组成，例如事件序列。数据流作为数据的基本模型，可能不如表或数据块那样直观和熟悉，但仍然可以提供一组完全等效的特性。人们普遍认为数据流是没有边界的，但它也可以是一个有边界的有限流，处理这些流相当于批处理。

为了描述数据处理过程，Flink在数据流上使用操作符，每个操作符生成一个新的数据流。从操作符、DAG和上下游操作符的链接来看，整体模型和Spark大体相同。Flink的定点相当于Spark中的阶段，将操作符划分为定点的过程和上图中在Spark DAG中划分为stage的过程基本相同。

相比之下，Flink的基本数据模型由数据流组成，例如事件序列。数据流作为数据的基本模型，可能不如表或数据块那样直观和熟悉，但仍然可以提供一组完全等效的特性。人们普遍认为数据流是没有边界的，但它也可以是一个有边界的有限流，处理这些流相当于批处理。

为了描述数据处理过程，Flink在数据流上使用操作符，每个操作符生成一个新的数据流。从操作符、DAG和上下游操作符的链接来看，整体模型和Spark大体相同。Flink的定点相当于Spark中的阶段，将操作符划分为定点的过程和上图中在Spark DAG中划分为stage的过程基本相同。

---

• 数据处理场景

• 除了批处理之外，Spark还支持实时数据流处理、交互查询、机器学习和图形计算等场景。
• 

实时数据流处理和批处理的主要区别在于低延迟要求。Spark RDD是基于内存的，可以很容易地将其切割成更小的块进行处理，快速处理这些小数据块就可以实现低延迟。

如果所有的数据都在内存中并且处理速度足够快，Spark还可以支持交互式查询。

Spark的机器学习和图形计算可以看作是不同类别的RDD操作符。Spark提供了支持公共操作的库，用户或第三方也可以扩展和提供更多的操作。值得一提的是，Spark的RDD模型与机器学习模型训练过程中的迭代计算非常兼容。从一开始，它就在某些场景中带来了显著的性能改进。

基于这些特性，Spark本质上是一个基于内存的批处理程序。它比Hadoop MapReduce更快，并且能使用足够快的批处理来实现各种场景。

实时数据流处理和批处理的主要区别在于低延迟要求。Spark RDD是基于内存的，可以很容易地将其切割成更小的块进行处理，快速处理这些小数据块就可以实现低延迟。

如果所有的数据都在内存中并且处理速度足够快，Spark还可以支持交互式查询。

Spark的机器学习和图形计算可以看作是不同类别的RDD操作符。Spark提供了支持公共操作的库，用户或第三方也可以扩展和提供更多的操作。值得一提的是，Spark的RDD模型与机器学习模型训练过程中的迭代计算非常兼容。从一开始，它就在某些场景中带来了显著的性能改进。

基于这些特性，Spark本质上是一个基于内存的批处理程序。它比Hadoop MapReduce更快，并且能使用足够快的批处理来实现各种场景。

---

• 状态处理

Flink另一个非常独特的方面是在引擎中引入了托管状态。为了理解托管状态，我们必须先从状态处理开始。如果处理事件（或数据块）的结果只与事件本身的内容相关，则称为无状态处理; 如果结果与先前处理的事件相关，称为有状态处理。任何重要的数据处理，如基本聚合，都是有状态的处理。Flink社区一直坚信，没有良好的状态支持，就不会有有效的流，因此，在早期引入了托管状态和状态API。

通常在流的情景中考虑状态处理，但仔细观察状态处理，它也会影响批处理。以窗口聚合的常见情况为例，如果批量数据周期大于窗口，中间状态可以忽略，用户逻辑往往会忽略这个问题。但是，当批量数据周期小于窗口时，批处理的结果实际上依赖以前处理过的批。由于批处理引擎通常看不到这个需求，它们通常不提供内置的状态支持，需要用户手动维护状态。例如在窗口聚合的情况下，用户需要一个中间结果表来存储不完整窗口的结果。因此，当用户缩短批处理周期时，处理逻辑变得更加复杂。在结构化流发布之前，这是早期Spark流用户的常见问题。

---

另一方面，Flink作为一个流引擎，从一开始就必须面对这个问题，并将托管状态作为一个通用的解决方案引入。除了让用户的工作更容易之外，与用户实现的解决方案相比，内置的解决方案还可以获得更好的性能。最重要的是，它可以提供更好的一致性保证。

简单地说，数据处理逻辑本身就会存在一些问题，这些问题在批处理中可以忽略或简化，而不会影响结果，但在流处理中则会暴露，需要加以解决。流引擎中主要通过在特定的区域进行专门的处理以便进行优化，这样以有限流的形式实现批处理，可以自然而然地得到正确地结果。相反，小批量的模拟流则意味着会暴露出新的问题。当批处理计算引擎没有这个问题的通用解决方案时，它需要用户自己解决。除了状态处理问题以外，还包括维度表更改（更新用户信息）、批处理数据边界、数据延迟到达等。

---

• 编程模型

Spark的初衷之一是提供一个统一的编程模型，能够解决不同用户的各种需求，它为之付出了巨大的努力。Spark基于RDD的初始API已经能够完成各种数据处理。随后为了简化用户的开发，在Spark 2.0(dateframe=dataset[row])中引入了更高级别的数据帧（在RDD中向结构化数据添加列）和数据集（添加dateframe列类型），它也较早地引入了Spark SQL支持。随着特定场景API的持续改进，如结构化流媒体和集成机器学习、深度学习，Spark的API变得非常容易使用，现在已经成为框架最强大的方面之一。

Flink的API也遵循一套类似的目标和开发路径，因此，Flink和Spark的核心API在功能上大体能够对应上。现在，根据过去两年机器学习和深度学习的整合，Spark的API总体上更加完整，Flink则在流处理相关方面仍然领先，比如它支持水位线（watermark）、窗口和触发器。

三、总结

Spark和Flink都是通用计算引擎，支持大规模数据处理和各种类型的数据处理，每一个都有很多值得探索的地方，例如SQL优化和机器学习集成。本文比较的主要目的是回顾两个系统的基本架构和设计特点。理论上，更切实际的做法是通过相互学习来跟上场景所需的上层功能发展，但改变基础设计的成本更大，令人望而却步。