0 前言

省流：小孩子才做选择。

谈到大数据处理引擎，不能不提 Spark。Apache Spark 是一个通用大规模数据分析引擎。它提出的内存计算概念让大家耳目一新，得以从 Hadoop 繁重的 MapReduce 程序中解脱出来，可以说是划时代的大数据处理框架。除了计算速度快、可扩展性强，Spark 还为批处理（SparkSQL）、流处理（Spark Streaming）、机器学习（Spark MLlib）、图计算（Spark GraphX）提供了统一的分布式数据处理平台，整个生态经过多年的蓬勃发展已经非常完善。

然而正在大家认为 Spark 已经如日中天、即将一统天下之际，Flink 如一颗新星异军突起，使得大数据处理的江湖再起风云。很多读者在最初接触都会有这样的疑问：想学习一个大数据 处理框架，到底选择 Spark，还是 Flink 呢？

这就需要我们了解两者的主要区别，理解它们在不同领域的优势。

1 数据处理架构

对于数据处理的基本方式，可以分为批处理和流处理两种。

批处理针对的是有界数据集，非常适合需要访问海量的全部数据才能完成的计算工作，一般用于离线统计。

流处理主要针对的是数据流，特点是无界、实时, 对系统传输的每个数据依次执行操作，一般用于实时统计。

从根本上说，Spark 和 Flink 采用了完全不同的数据处理方式。可以说，两者的世界观是截然相反的。

Spark 以批处理为根本，并尝试在批处理之上支持流计算；在 Spark 的世界观中，万物皆批次，离线数据是一个大批次，而实时数据则是由一个一个无限的小批次组成的。所以对于流处理框架 Spark Streaming 而言，其实并不是真正意义上的“流”处理，而是“微批次”（micro-batching）处理，如图1 所示。

而 Flink 则认为，流处理才是最基本的操作，批处理也可以统一为流处理。在 Flink 的世界观中，万物皆流，实时数据是标准的、没有界限的流，而离线数据则是有界限的流。如图2 所示，就是所谓的无界流和有界流。

1. 无界数据流（Unbounded Data Stream）

   所谓无界数据流，就是有头没尾，数据的生成和传递会开始但永远不会结束，如图2 所示。我们无法等待所有数据都到达，因为输入是无界的，永无止境，数据没有“都到达”的时候。所以对于无界数据流，必须连续处理，也就是说必须在获取数据后立即处理。在处理无界流时，为了保证结果的正确性，我们必须能够做到按照顺序处理数据。

2. 有界数据流（Bounded Data Stream）

   对应的，有界数据流有明确定义的开始和结束，如图2 所示，所以我们可以通过获取所有数据来处理有界流。处理有界流就不需要严格保证数据的顺序了，因为总可以对有界数据集进行排序。有界流的处理也就是批处理。

正因为这种架构上的不同，Spark 和 Flink 在不同的应用领域上表现会有差别。一般来说，Spark 基于微批处理的方式做同步总有一个“攒批”的过程，所以会有额外开销，因此无法在流处理的低延迟上做到极致。在低延迟流处理场景，Flink 已经有明显的优势。而在海量数据的批处理领域，Spark 能够处理的吞吐量更大，加上其完善的生态和成熟易用的 API，目前同样优势比较明显。

2 数据模型和运行架构

除了三观不合，Spark 和 Flink 在底层实现最主要的差别就在于数据模型不同。

Spark 底层数据模型是弹性分布式数据集（RDD），Spark Streaming 进行微批处理的底层接口 DStream，实际上处理的也是一组组小批数据 RDD 的集合。可以看出，Spark 在设计上本身就是以批量的数据集作为基准的，更加适合批处理的场景。

而 Flink 的基本数据模型是数据流（DataFlow），以及事件（Event）序列。Flink 基本上是完全按照 Google 的 DataFlow 模型实现的，所以从底层数据模型上看，Flink 是以处理流式数据作为设计目标的，更加适合流处理的场景。

数据模型不同，对应在运行处理的流程上，自然也会有不同的架构。Spark 做批计算，需要将任务对应的 DAG 划分阶段（Stage），一个完成后经过 shuffle 再进行下一阶段的计算。而Flink 是标准的流式执行模式，一个事件在一个节点处理完后可以直接发往下一个节点进行处理。

3 选择Spark 还是 Flink？

通过前文的分析，我们已经可以看出，Spark 和 Flink 可以说目前是各擅胜场，批处理领域 Spark 称王，而在流处理方面 Flink 当仁不让。具体到项目应用中，不仅要看是流处理还是批处理，还需要在延迟、吞吐量、可靠性，以及开发容易度等多个方面进行权衡。

如果在工作中需要从 Spark 和 Flink 这两个主流框架中选择一个来进行实时流处理，仍然更加推荐使用 Flink，主要的原因有：

• Flink 的延迟是毫秒级别，而 Spark Streaming 的延迟是秒级延迟。
• Flink 提供了严格的精确一次性语义保证。
• Flink 的窗口 API 更加灵活、语义更丰富。
• Flink 提供事件时间语义，可以正确处理延迟数据。
• Flink 提供了更加灵活的对状态编程的 API。

基于以上特点，使用 Flink 可以解放程序员, 加快编程效率, 把本来需要程序员花大力气手动完成的工作交给框架完成。

当然，在海量数据的批处理方面，Spark 还是具有明显的优势。而且 Spark 的生态更加成熟，也会使其在应用中更为方便。相信随着 Flink 的快速发展和完善，这方面的差距会越来越小。

另外，Spark 2.0 之后新增的 Structured Streaming 流处理引擎借鉴 DataFlow 进行了大量优化，同样做到了低延迟、时间正确性以及精确一次性语义保证；Spark 2.3 以后引入的连续处理（Continuous Processing）模式，更是可以在至少一次语义保证下做到 1 毫秒的延迟。而 Flink自 1.9 版本合并 Blink 以来，在 SQL 的表达和批处理的能力上同样有了长足的进步。

那如果现在要学习一门框架的话，优先选 Spark 还是 Flink 呢？其实我们可以看到，不同的框架各有利弊，同时它们也在互相借鉴、取长补短、不断发展，至于未来是 Spark 还是 Flink、甚至是其他新崛起的处理引擎一统江湖，都是有可能的。作为技术人员，我们应该对不同的架构和思想都有所了解，跳出某个框架的限制，才能看到更广阔的世界。