1.前言
目前实时计算的业务场景越来越多，实时计算引擎技术及生态也越来越成熟。以Flink和Spark为首的实时计算引擎，成为实时计算场景的重点考虑对象。那么，今天就来聊一聊基于Kafka的实时计算引擎如何选择？Flink or Spark？
2.为何需要实时计算？
根据IBM的统计报告显示，过去两年内，当今世界上90%的数据产生源于新设备、传感器以及技术的出现，数据增长率也会为此加速。而从技术上将，这意味着大数据领域，处理这些数据将变得更加复杂和具有挑战性。例如移动应用广告、欺诈检测、出租车预订、患者监控等场景处理时，需要对实时数据进行实时处理，以便做出快速可行的决策。
目前业界有开源不少实时计算引擎，以Apache基金会的两款开源实时计算引擎最受欢迎，它们分别是Apache Flink和Apache Spark。接下来，我们来聊一聊它们的使用场景、优势、局限性、相似性、以及差异性。方便大家在做技术选型时，选择切合项目场景的实时计算引擎。
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，此时，窗口机制能够很好的帮助我们实现这类需求。
- 情况一：假设数据源分别在时间14秒，第14秒和第16秒产生消息类型K的消息（窗口大小为10秒）。这些消息将落入窗口中，如上图所示，在第14秒产生的前两个消息将落入窗口1（5秒~15秒）和窗口2（10秒~20秒），第16秒产生的第三个消息将落入窗口2（10秒~10秒）和窗口3（15秒~25秒）。每个窗口发出的最终计数分别为（F,2）、(F,3)、(F,1)，这是一种理想的状态。
- 情况二：假设其中一条消息（第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.总结（Flink VS Spark）
了解了Flink和Spark各自的特点后，知道了Spark Streaming通过小批量的方式保证了吞吐的情况下，同时提供了Exactly Once语义，但是不是严格意义上的实时，而且由于微批处理的方式，对窗口和事件时间的支持比较有限。Flink采用分布式快照的方式实现了一个高吞吐、低延时，并且支持Exactly Once的实时计算引擎，同时Flink的实时计算引擎也能更好支持窗口和事件时间。
通过对Flink和Spark特点的掌握，再结合实际的项目需求、业务场景、以及技术储备，来选取最适合的计算引擎。
6.结束语
这篇博客就和大家分享到这里，如果大家在研究学习的过程当中有什么问题，可以加群进行讨论或发送邮件给我，我会尽我所能为您解答，与君共勉！
另外，博主出书了《Kafka并不难学》和《Hadoop大数据挖掘从入门到进阶实战》，喜欢的朋友或同学， 可以在公告栏那里点击购买链接购买博主的书进行学习，在此感谢大家的支持。关注下面公众号，根据提示，可免费获取书籍的教学视频。