基于Kafka的实时计算引擎如何选择？Spark or Flink

1. 前言

目前实时计算的业务场景越来越多，实时计算引擎技术及生态也越来越成熟。以 Spark 和 Flink 为首的实时计算引擎，成为实时计算场景的重点考虑对象。那么，今天就来聊一聊基于 Kafka 的实时计算引擎如何选择? Spark or Flink?

2. 为何需要实时计算?

根据 IBM 的统计报告显示，过去两年内，当今世界上 90% 的数据产生源于新设备、传感器以及技术的出现，数据增长率也会为此加速。而从技术上将，这意味着大数据领域，处理这些数据将变得更加复杂和具有挑战性。例如移动应用广告、欺诈检测、出租车预订、患者监控等场景处理时，需要对实时数据进行实时处理，以便做出快速可行的决策。

目前业界有开源不少实时计算引擎，以 Apache 基金会的两款开源实时计算引擎最受欢迎，它们分别是 Apache Spark 和 Apache Flink 。接下来，我们来聊一聊它们的使用场景、优势、局限性、相似性、以及差异性。方便大家在做技术选型时，选择切合项目场景的实时计算引擎。

2.1 如何理解流式与实时?

说起实时计算，可能会说到流式计算，那么流式和实时是否是等价的呢?严格意义上讲，它们没有必然的联系。实时计算代表的是处理数据耗时情况，而流式计算代表的是处理数据的一种方式。

2.2 什么是流式处理?

首先，它是一种数据处理引擎，其设计时考虑了无边界的数据集。其次，它与批处理不同，批处理的 Job 与数据的起点和终点有关系，并且 Job 在处理完有限数据后结束，而流式处理用于处理连续数天、数月、数年、或是永久实时的无界数据。

流处理的特点：

容错性：如果节点出现故障，流式处理系统应该能够恢复，并且应该从它离开的位置再次开始处理;

状态管理：在有状态处理要求的情况下，流式处理系统应该能够提供一些机制来保存和更新状态信息;

性能：延时应尽可能的小，吞吐量应尽可能的大;

高级功能：事件时间处理，窗口等功能，这些均是流式处理在处理复杂需求时所需要的功能;

2.3 什么时候适合流式处理?

流式处理可以分析连续的数据流，在这种方式中，数据被视为连续流，处理引擎在很短的时间内 ( 几毫米到几分钟 ) 内取数、分析、以及响应。下面让我们来看看流式处理的场景使用场景：

异常检测：流式处理可以应用于连续的数据流并近乎实时的检测异常。例如，在金融交易数据中，欺诈性交易可以被视为异常，流式处理可以检测到这些，保护银行和客户免受财务损失。

业务流程监控：业务流程涉及特定域中的多个事件。例如，在电子商务业务中，从下单、支付、出库、送货、再到用户签收的所有事件都可以被视为一个业务流程。流处理可用于监控此类流程的异常情况，例如在时间范围内为完成、交付商品时出错等。

告警：流式处理可用于根据指定规则触发告警，满足特定条件，可以实时将告警发送到不同的目标。

3. Spark

Spark 已成为批处理中 Hadoop 的真正继承者，也是第一个完美支持 Lambda 架构的框架。Spark 受欢迎度极高，成熟并且广泛使用。Spark 免费提供 Spark Streaming，它使用微批处理进行流式传输。在 Spark2.0 之后，添加了许多优秀的功能 ( 例如对 tungsten、watermarks、event time 处理的支持 ) ，同时结构化流也更加抽象，截止本篇博客 Spark 发布的可用版本为 2.4.3，可以在最新版本中在微批处理和连续流模式之间进行切换。

3.1 微批处理 & 连续流处理

结构化流式传输默认采用微批处理执行，Spark 流式计算引擎会定时检查流数据。在连续流处理中，Spark 不会启动定时任务，而是启动一组长时间运行的任务，这些任务可以连续读取、处理、写入数据。

微批处理中，驱动程序通过将记录 Offset 保存到预写 Log 来检测进度，然后可以使用该 Log 重新进行查询。需要注意的是，在微批处理处理开始之前，需要在下一个微批处理中处理的范围 Offset 保存到 Log 中，以便获取确定性的重新执行和端到端语义。因此，源记录可能需要等待当前的微批处理处理完成，然后记录其 Offset 。

连续流处理中，通过完善和改进算法来检测查询进度，特殊标记的记录被写入到每个任务的输入数据流中。当任务遇到标记时，任务会异步报告处理的最后一个 Offset ，一旦驱动程序收到写入接收器的所有任务的 Offset ，它就会将它们写入预写 Log 中。由于 Checkpoint 完全异步，因此任务可以不间断的继续，并提供一致的毫秒级延时。

3.2 Streaming

对于 Spark Streaming 来说，当不同的数据来源输入进来时，基于固定的时间间隔，会形成一系列固定不变的数据集或者事件集 ( 例如 Kafka、Flume 等 ) 。这正好和 Spark RDD 基于固定的数据集吻合，从每一个批处理来看，空间维度的 RDD 依赖关系一致，不同的是这 4 个批处理输入的数据规模和数据内容不同，所以生成的 RDD 依赖关系实例不一样。

3.3 优势

列举了 Spark 常见优势，如下所示：

支持 Lambda，且在 Spark 中免费使用
高吞吐量，适用于不需要子延时的用例
容错性，默认使用微批处理
高度抽象的 API
社区活跃度高
支持 Exactly Once

3.4 限制

另外，Spark 也有它不足的地方，如下所示：

不是真正意义上的实时计算，不能够满足低延时需求
需要调整的参数太多，很难做到全面
在许多高级功能中落后于 Flink

4. Flink

Flink 也是来自 Spark 类似的学术背景，Spark 来自加州大学伯克利分校，Flink 来自柏林大学。像 Spark 一样，它也支持 Lambda ，但实现与 Spark 完全相反。Flink 本质上是一个真正的实时计算引擎，将批处理作为有限数据流的特殊情况。虽然两个计算框架中的 API 相似，但它们在实现中没有任何相似之处，在 Flink 中，Map、Filter、Reduce 等各个函数实现为长时间运行的运算符 ( 类似于 Storm 中的 Bolt ) 。

4.1 什么是 Apache Flink?

Flink 是一个开源的实时计算引擎，是实时计算领域的领导者。它拥有出色的图计算和机器学习功能，其底层支持 On YARN 模式，且提供了本地 & 分布式模式，以及 Docker & Kubernetes 等容器部署。

4.2 如何使用 Flink 解决问题?

在低延时场景，需要实时数据，以便能够更快的检测和解决关键事件。例如，在使用 Flink 之前，计算的基本业务指标，实现的延时时间约为 3 到 4 小时，这意味着，如果工程师在早上 10 点左右检测到业务指标变化异常，只能在下午 14 点左右开始排查。如果能够立马解决，则只能在下午 18 左右时来验证解决方案，这样实现起来效率不是很高。

假如你的业务数据是基于时间序列的，那么我们需要使用事件时间来处理在时间窗口内对业务指标进行分组。同时，Flink 也可以很轻松的与存储在 Kafka 和 HDFS 中的业务数据进行集成。另外，Flink 具有良好的非功能特性，便于在生产中运行，易于与不同的监控后端集成 ( 例如 Graphite、Prometheus 等 ) ，以及提供良好的 UI 界面。此外，Flink 工作的快速开发周期以及简单的执行模型使得学习曲线平稳，开发效率高。

4.3 什么是窗口和事件时间?

Flink 相比较 Spark Streaming 不仅提供了更低的延时，而且 Flink 还对窗口和事件时间提供了更好的支持。

4.3.1 窗口

现实场景中，大部分的数据来源都是无界的，很多情况下，我们会对固定时间间隔的数据进行统计，比如每隔 10 秒统计一下集群服务的 QPS ，此时，窗口机制能够很好的帮助我们实现这类需求。

1. 情况一：假设数据源分别在时间 14 秒，第 14 秒和第 16 秒产生消息类型 K 的消息 ( 窗口大小为 10 秒 ) 。这些消息将落入窗口中，如上图所示，在第 14 秒产生的前两个消息将落入窗口 1 ( 5 秒~15 秒 ) 和窗口 2 ( 10 秒~20 秒 ) ，第 16 秒产生的第三个消息将落入窗口 2 ( 10 秒~20 秒 ) 和窗口 3 ( 15 秒~25 秒 ) 。每个窗口发出的最终计数分别为 ( F , 2 )、( F , 3 )、( F , 1 )，这是一种理想的状态。

2. 情况二：假设其中一条消息 ( 第 14 秒生产的 ) 由于网络原因到达时延时了 5 秒 ( 第 19 秒到达 ) ，那么此时消息在窗口的分布如何呢?延时的消息落入到窗口 2 和窗口 3，因为第 19 秒在 10 秒~20 秒和 15 秒~25 秒这两个窗口。对于窗口 2 来说，计算没有什么问题 ( 因为消息应该落入该窗口 ) ，但是它影响了窗口 1 和窗口 3 的结果。

4.3.2 事件时间

现在我们尝试使用事件时间来解决情况二的延时问题。要启用事件时间处理，需要一个时间戳提取器，从消息中提取事件时间信息。流式计算按照数据的事件时间来将数据分配到对应的窗口，而不是按照处理数据的时间，处理结果如下图。

引入事件时间后的结果看起来更好了，窗口 2 和窗口 3 发出了正确的结果，但是窗口 1 仍然是错误的。Flink 没有将延迟的消息分配给窗口 3，因为它现在检查的是消息的事件时间了，并且理解它不在窗口中。但是为什么没有将消息分配给窗口 1 呢?原因在于延迟的消息到达系统时 ( 第 19 秒 ) ，窗口 1 的评估已经完成了 ( 15 秒 ) 。

4.3.3 水印

为了达到解决情况二的问题，达到情况一的预期结果。引入水印机制，水印机制可以看作是一种告诉 Flink 一个消息延迟多少的方式。现在将水印设置为当前时间负 5 秒，告诉 Flink 希望消息最多有 5 秒的延迟，这是因为每个窗口在水印通过时被评估。由于设置的水印时间为当前时间负 5 秒，所以窗口 1 ( 5 秒~15 秒 ) 将在第 20 秒时被评估，以此类推，窗口 2 ( 10 秒~20 秒 ) 将在第 25 秒时进行评估。优化后的结果如下：

最后调整引入水印机制后，得到正确的结果，这 3 个窗口均按照预期的方式发出计数，即 ( F , 2 ) 、( F , 3 ) 、( F , 1 ) 。

5. 总结 ( Spark vs Flink )

了解了 Spark 和 Flink 各自的特点后，知道了 Spark Streaming 通过小批量的方式保证了吞吐的情况下，同时提供了 Exactly Once 语义，但是不是严格意义上的实时，而且由于微批处理的方式，对窗口和事件时间的支持比较有限。Flink 采用分布式快照的方式实现了一个高吞吐、低延时，并且支持 Exactly Once 的实时计算引擎，同时 Flink 的实时计算引擎也能更好支持窗口和事件时间。

通过对 Spark 和 Flink 特点的掌握，再结合实际的项目需求、业务场景、以及技术储备，来选取最适合的计算引擎。

6. 结束语

这篇文章就和大家分享到这里，如果大家在研究学习的过程当中有什么问题，可以发送邮件给我，我会尽我所能为您解答，与君共勉!