基于Kafka的实时计算引擎：Flink能否替代Spark？

时间：2020-06-20 09:12:52 阅读：230 评论：0 收藏：0 [点我收藏+]

根据 IBM 的统计报告显示，过去两年内，当今世界上90%的数据产生源于新设备、传感器以及技术的出现，数据增长率也会为此加速。而从技术上将，这意味着大数据领域，处理这些数据将变得更加复杂和具有挑战性。例如移动应用广告、欺诈检测、出租车预订、患者监控等场景处理时，需要对实时数据进行实时处理，以便做出快速可行的决策。
目前业界有开源不少实时计算引擎，以 Apache 基金会的两款开源实时计算引擎最受欢迎，它们分别是 Apache Spark 和 Apache Flink 。接下来，我们来聊一聊它们的使用场景、优势、局限性、相似性、以及差异性。方便大家在做技术选型时，选择切合项目场景的实时计算引擎。
说起实时计算，可能会说到流式计算，那么流式和实时是否等价？严格意义上讲，它们没有必然的联系。实时计算代表的是处理数据耗时情况，而流式计算代表的是处理数据的一种方式。
流式处理
首先，它是一种数据处理引擎，其设计时考虑了无边界的数据集。其次，它与批处理不同，批处理的 Job 与数据的起点和终点有关系，并且 Job 在处理完有限数据后结束，而流式处理用于处理连续数天、数月、数年、或是永久实时的***数据。
流处理的特点
容错性：如果节点出现故障，流式处理系统应该能够恢复，并且应该从它离开的位置再次开始处理；
状态管理：在有状态处理要求的情况下，流式处理系统应该能够提供一些机制来保存和更新状态信息；
性能：延时应尽可能的小，吞吐量应尽可能的大；
高级功能：事件时间处理，窗口等功能，这些均是流式处理在处理复杂需求时所需要的功能。流式处理可以分析连续的数据流，在这种方式中，数据被视为连续流，处理引擎在很短的时间内 ( 几毫米到几分钟 ) 内取数、分析、以及响应。
流式处理的场景使用场景
异常检测：流式处理可以应用于连续的数据流并近乎实时的检测异常。例如，在金融交易数据中，欺诈性交易可以被视为异常，流式处理可以检测到这些，保护银行和客户免受财务损失。
业务流程监控：业务流程涉及特定域中的多个事件。例如，在电子商务业务中，从下单、支付、出库、送货、再到用户签收的所有事件都可以被视为一个业务流程。流处理可用于监控此类流程的异常情况，例如在时间范围内为完成、交付商品时出错等。
告警：流式处理可用于根据指定规则触发告警，满足特定条件，可以实时将告警发送到不同的目标。

Spark
Spark 已成为批处理中 Hadoop 的真正继承者，也是第一个完美支持 Lambda 架构的框架。 Spark 受欢迎度极高，成熟并且广泛使用。 Spark 免费提供 SparkStreaming，它使用微批处理进行流式传输。在 Spark2.0 之后，添加了许多优秀的功能 ( 例如对tungsten、watermarks、event time 处理的支持 ) ，同时结构化流也更加抽象，截止本篇博客 Spark 发布的可用版本为2.4.3，可以在最新版本中在微批处理和连续流模式之间进行切换。
微批处理 & 连续流处理
结构化流式传输默认采用微批处理执行，Spark 流式计算引擎会定时检查流数据。在连续流处理中，Spark 不会启动定时任务，而是启动一组长时间运行的任务，这些任务可以连续读取、处理、写入数据。
微批处理中，驱动程序通过将记录 Offset 保存到预写 Log 来检测进度，然后可以使用该 Log 重新进行查询。需要注意的是，在微批处理处理开始之前，需要在下一个微批处理中处理的范围 Offset 保存到 Log 中，以便获取确定性的重新执行和端到端语义。因此，源记录可能需要等待当前的微批处理处理完成，然后记录其 Offset 。连续流处理中，通过完善和改进算法来检测查询进度，特殊标记的记录被写入到每个任务的输入数据流中。当任务遇到标记时，任务会异步报告处理的最后一个 Offset ，一旦驱动程序收到写入接收器的所有任务的 Offset ，它就会将它们写入预写 Log 中。由于 Checkpoint 完全异步，因此任务可以不间断的继续，并提供一致的毫秒级延时。
Streaming
对于 Spark Streaming 来说，当不同的数据来源输入进来时，基于固定的时间间隔，会形成一系列固定不变的数据集或者事件集 ( 例如 Kafka、Flume 等 ) 。这正好和SparkRDD 基于固定的数据集吻合，从每一个批处理来看，空间维度的 RDD 依赖关系一致，不同的是这4个批处理输入的数据规模和数据内容不同，所以生成的 RDD 依赖关系实例不一样。
Spark的优势
支持 Lambda，且在 Spark 中免费使用
高吞吐量，适用于不需要子延时的用例
容错性，默认使用微批处理
高度抽象的 API
社区活跃度高
支持 Exactly Once
Spark的不足
不是真正意义上的实时计算，不能够满足低延时需求
需要调整的参数太多，很难做到全面
在许多高级功能中落后于Flink

Flink
Flink 是一个开源的实时计算引擎，是实时计算领域的领导者。它拥有出色的图计算和机器学习功能，其底层支持 On YARN 模式，且提供了本地 & 分布式模式，以及Docker & Kubernetes 等容器部署。像Spark一样，它也支持 Lambda ，但实现与 Spark 完全相反。Flink本质上是一个真正的实时计算引擎，将批处理作为有限数据流的特殊情况。虽然两个计算框架中的 API 相似，但它们在实现中没有任何相似之处，在 Flink 中，Map、 Filter、Reduce 等各个函数实现为长时间运行的运算符 ( 类似于 Storm 中的Bolt ) 。
如何使用 Flink 解决问题
在低延时场景，需要实时数据，以便能够更快的检测和解决关键事件。例如，在使用 Flink之前，计算的基本业务指标，实现的延时时间约为3到4小时，这意味着，如果工程师在早上 10点左右检测到业务指标变化异常，只能在下午 14 点左右开始排查。如果能够立马解决，则只能在下午18左右时来验证解决方案，这样实现起来效率不是很高。假如你的业务数据是基于时间序列的，那么我们需要使用事件时间来处理在时间窗口内对业务指标进行分组。同时，Flink 也可以很轻松的与存储在 Kafka 和 HDFS 中的业务数据进行集成。另外Flink具有良好的非功能特性，便于在生产中运行，易于与不同的监控后端集成 ( 例如 Graphite、Prometheus 等 ) ，以及提供良好的 UI 界面。此外，Flink 工作的快速开发周期以及简单的执行模型使得学习曲线平稳，开发效率高。Flink 相比较 SparkStreaming 不仅提供了更低的延时，而且 Flink 还对窗口和事件时间提供了更好的支持。

总结
SparkStreaming 通过小批量的方式保证了吞吐的情况下，同时提供了 ExactlyOnce 语义，但是不是严格意义上的实时，而且由于微批处理的方式，对窗口和事件时间的支持比较有限。Flink 采用分布式快照的方式实现了一个高吞吐、低延时，并且支持 ExactlyOnce 的实时计算引擎，同时 Flink的实时计算引擎也能更好支持窗口和事件时间。
在某些场景下Flink确实优于Spark，但完全替代是不可能的，没有最好的技术只有最合适的技术，现实中往往需要结合实际的项目需求、业务场景、以及技术储备来选取最适合的计算引擎。