写点什么

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

2019 年 6 月 13 日

基于 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 秒 ) 。


s


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. 结束语

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


作者介绍

哥不是小萝莉,知名博主,著有《 Kafka 并不难学 》和《 Hadoop 大数据挖掘从入门到进阶实战 》。


作者博客:


https://www.cnblogs.com/smartloli/


邮箱:smartloli.org@gmail.com


本文来自 DataFun 社区


原文链接


https://mp.weixin.qq.com/s/YtC6mHVin7DWR1qtwF5GyA


2019 年 6 月 13 日 08:0011302

评论 3 条评论

发布
用户头像
这图全乱了
2020 年 06 月 16 日 17:28
回复
用户头像
写这文章对组件的了解有点落后了吧
2019 年 06 月 13 日 18:05
回复
用户头像
和Flink对标的应该是SparkStructuredStreaming而不是SparkStreaming。Spark最大的优势还是生态圈和AI,目前Streaming确实不如Flink。
2019 年 06 月 13 日 09:32
回复
没有更多了
发现更多内容

有一说一,大型信息化企业的软件系统,还是用自研的好

Marilyn

敏捷开发 快速开发 开发工具 软件设计

Redis Sharding集群跟一致性哈希有什么瓜葛?

Man

一致性哈希 Jedis redis cluster

JVM-技术专题-深入理解内存结构

李浩宇/Alex

Java JVM

五年Java开发经验,4面阿里成功拿下offer,分享一下个人面经!

Java架构之路

Java 程序员 面试 算法 编程语言

快速开发平台,高集成易扩展,进入软件疾速开发新世代

Marilyn

敏捷开发 快速开发 开发工具

标本兼治,程序员用它整体提升公司效率

Marilyn

敏捷开发 快速开发

区块链钱包软件开发费用,区块链多币种钱包

135深圳3055源中瑞8032

spring-boot-route(十三)整合RabbitMQ

Java旅途

Java Spring Boot RabbitMQ

为什么巨头都在布局SaaS生态?

ToB行业头条

SASS

用友政务表格技术应用开发实践:预算一体化产品核心功能搭建

Geek_Willie

SpreadJS 用友

TensorFlow 篇 | TensorFlow 2.x 基于 Keras 的模型保存及重建

Alex

tensorflow keras model save model restore tensorflow hub

架构师训练营 1 期第 4 周:系统架构 - 作业

piercebn

极客大学架构师训练营

Go语言内存管理三部曲(一)内存分配原理

网管

go 内存管理 内存布局

微前端之如何拆解React巨石应用 qiankun

SugarTurboS

项目管理 架构 React 微前端 前端性能优化

快速开发平台,程序员“老师傅”必备

Marilyn

敏捷开发 快速开发 开发工具

MySQL-技术专题-性能优化—索引篇

李浩宇/Alex

区块链USDT支付系统开发需要多少费用?USDT跨境支付

135深圳3055源中瑞8032

百度人工智能OCR调用调试过程

tuuezzy

GitHub 上开源了一个很邪恶的项目!女生勿近,18香警告...

程序员生活志

大企内部软件系统反复故障难以解决,业内人士:唯有彻底更换

Marilyn

敏捷开发 快速开发 开发工具

数字货币交易所开发,币币交易源码

135深圳3055源中瑞8032

合约跟单交易系统开发,一键智能跟单软件

135深圳3055源中瑞8032

企业开发遇到瓶颈,何不换个新思路?快速开发了解一下

Marilyn

敏捷开发 快速开发

一线城市年轻人生活工作录(业务员篇)

Marilyn

敏捷开发 快速开发

阿里面试官纯手打:金九银十跳槽必会Java核心知识点笔记整理

Java架构追梦

Java 数据库 架构 面试 微服务

医疗AI系统构建(1)one-hot编码

刘旭东

人工智能 学习 医疗AI one-hot

一线城市年轻人生活工作实录(程序员篇)

Marilyn

敏捷开发 开发者工具 快速开发

WSDM Cup 2020大赛金牌参赛方案全解析

华为云开发者社区

大数据 搜索 信息

阿里内部《Java架构进阶宝典》,总结了基础、进阶、架构三个阶段的知识点

Java架构之路

Java 程序员 面试 算法 编程语言

医院HIS故障,险引发人命关天大危机,竟被程序员轻松解决!

Marilyn

JAVA代码生成器,快速开发平台之魂

Marilyn

Java 敏捷开发 快速开发 开发工具

2021年全国大学生计算机系统能力大赛操作系统设计赛 技术报告会

2021年全国大学生计算机系统能力大赛操作系统设计赛 技术报告会

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