没有合适的资源?快使用搜索试试~ 我知道了~
Flink 是一个在有界数据流和无界数据流上进行有状态计算分布式处理引擎和框架。
资源推荐
资源详情
资源评论
38
Apache Flink 是一个在
有界
数据流和
无界
数据流上进行有状态计算分布式处理引擎和框架。Flink
设计旨在
所有常见的集群环境
中运行,以
任意规模
和
内存
级速度执行计算。
第 1 章 Flink 快速上手
1.1
Flink vs Spark
1.1.1
数据处理架构
从根本上说,Spark 和 Flink 采用了完全不同的数据处理方式。可以说,两者的世界观是
截然相反的。
Spark 以批处理为根本,并尝试在批处理之上支持流计算;在 Spark 的世界观中,万物皆
批次,离线数据是一个大批次,而实时数据则是由一个一个无限的小批次组成的。所以对于流处
理框架 Spark Streaming 而言,其实并不是真正意义上的“流”处理,而是“微批次”
(micro-batching)处理,如图 1-8 所示。。
图 1-8 Spark Streaming 流处理示意
而 Flink 则认为,流处理才是最基本的操作,批处理也可以统一为流处理。在 Flink 的世
界观中,万物皆流,实时数据是标准的、没有界限的流,而离线数据则是有界限的流。
1. 无界数据流(Unbounded Data Stream)
所谓无界数据流,就是有头没尾,数据的生成和传递会开始但永远不会结束,如图 1-9 所示。
我们无法等待所有数据都到达,因为输入是无界的,永无止境,数据没有“都到达”的时候。所
以对于无界数据流,必须连续处理,也就是说必须在获取数据后立即处理。在处理无界流时,为
了保证结果的正确性,我们必须能够做到按照顺序处理数据。
38
2. 有界数据流(Bounded Data Stream)
对应的,有界数据流有明确定义的开始和结束,如图 1-9 所示,所以我们可以通过获取所有
数据来处理有界流。处理有界流就不需要严格保证数据的顺序了,因为总可以对有界数据集进行排序。
有界流的处理也就是批处理。
图 1-9 有界流与无界流
正因为这种架构上的不同,Spark 和 Flink 在不同的应用领域上表现会有差别。一般来说,
Spark 基于微批处理的方式做同步总有一个“攒批”的过程,所以会有额外开销,因此无法在
流处理的低延迟上做到极致。在低延迟流处理场景,Flink 已经有明显的优势。而在海量数据
的批处理领域,Spark 能够处理的吞吐量更大,加上其完善的生态和成熟易用的 API,目前量
数据的批处理领域,Spark 能够处理的吞吐量更大,加上其完善的生态和成熟易用的 API,目
前同样优势比较明显。
1.1.2
数据模型和运行架构
Spark 和 Flink 在底层实现最主要的差别就在于数据模型不同。
Spark 底层数据模型是弹性分布式数据集(RDD),Spark Streaming 进行微批处理的底层
接口DStream,实际上处理的也是一组组小批数据 RDD 的集合。可以看出,Spark 在设计上本
身就是以批量的数据集作为基准的,更加适合批处理的场景。
而 Flink 的基本数据模型是数据流(DataFlow),以及事件(Event)序列。Flink 基本上是完
全按照 Google 的 DataFlow 模型实现的,所以从底层数据模型上看,Flink 是以处理流式数据
作为设计目标的,更加适合流处理的场景。
数据模型不同,对应在运行处理的流程上,自然也会有不同的架构。Spark 做批计算,需
要将任务对应的 DAG 划分阶段(Stage),一个完成后经过 shuffle 再进行下一阶段的计算。而 Flink
是标准的流式执行模式,一个事件在一个节点处理完后可以直接发往下一个节点进行处理。
38
1.1.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 的表达和批处理的能力上同样有了长足的进步。
第 3 章 Flink 部署
Flink 中的几个关键组件:客户端(Client)、作业管理器(JobManager)和任务管理器(
TaskManager)。我们的代码,实际上是由客户端获取并做转换,之后提交给 JobManger 的。所
以 JobManager 就是 Flink 集群里的“领导者”,对作业进行中央调度管理;而它获取到要执行的
作业后,会进一步处理转换,然后分发任务给众多的TaskManager。这里的 TaskManager,就是
真正“干活的人”,数据的处理操作都是它们来做的,如图 3-1 所示。
38
图 3-1 Flink 集群中的主要组件
3.1
部署模式
在一些应用场景中,对于集群资源分配和占用的方式,可能会有特定的需求。Flink 为各
种场景提供了不同的部署模式,主要有以下三种:
会话模式(Session Mode)
单作业模式(Per-Job Mode)
应用模式(Application Mode)
它们的区别主要在于:集群的生命周期以及资源的分配方式;以及应用的 main 方法到底在
哪里执行——客户端(Client)还是 JobManager。
3.1.1
会话模式(Session Mode)
会话模式(Session Mode)
单作业模式(Per-Job
Mode)
应用模式(Application
Mode)
38
先启动一个集群,保持一个
会话,在这个会话中通过客
户端提交作业,。集群启动时
所有资源就都已经确定,所
以所有提交的作业会竞争集
群中的资源。
会话模式因为资源共享会导
致很多问题,所以为了更好
地隔离资源,我们可以考虑
为每个提交的作业启动一个
集群,这就是所谓的单作业
(Per-Job)模式
会话模式比较适合于单个规
模小、执行时间短的大量作
业。
Flink 本身无法直接这样运
行,所以单作业模式一般需
要借助一些资源管理平台来
启动集群,比如 YARN、
Kubernetes
应用模式引入
前面提到的两种模式下,应用代码都是在客户端上执行,然后由客户端提交给 JobManager 的。
但是这种方式客户端需要占用大量网络带宽,去下载依赖和把二进制数据发送给 JobManager;加上很多
情况下我们提交作业用的是同一个客户端,就会加重客户端所在节点的资源消耗。
所以解决办法就是,我们不要客户端了,直接把应用提交到 JobManger 上运行。而这也就代表着,我们
需要为每一个提交的应用单独启动一个 JobManager,也就是创建一个集群。这个 JobManager 只为执
行这一个应用而存在,执行结束之后 JobManager 也就关闭了,这就是所谓的应用模式
单作业模式 vs 应用模式
单作业模式与应用模式,都是提交作业之后才创建集群;单作业模式是通过客户端来提交的,客
户端解析出的每一个作业对应一个集群;而应用模式下,是直接由 JobManager 执行应用程序
的,并且即使应用包含了多个作业,也只创建一个集群。
第 4 章 Flink 运行时架构
4.1
系统架构
剩余40页未读,继续阅读
资源评论
龙骨
- 粉丝: 154
- 资源: 23
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功