流/批/OLAP 一体的 Flink 引擎介绍笔记（二）｜ 青训营笔记
这是我参与「第四届青训营 -大数据场」笔记创作活动的的第3天
二、Flink 整体架构
1. Flink 分层架构
- SDK层：FLink的SDK目前主要有三类：SQL/Table、DataStream、Python
- 执行引擎层（Runtime层）：执行引擎层提供了统一的DAG用来描述数据处理的Pipeline,不管是流还是批，都会转化为DAG图，调度层再把DAG转化为分布式环境下的Task，Task之间通过Shuffle传输数据
- 状态存储层：负责存储算子的状态信息
- 资源调度层：目前Flink可以支持部署在多种环境
2. Flink 总体架构
Flink集群中，两个核心组件：
-
JobManager(JM)：负责整个任务的协调工作，包括：调度Task、触发协调Task做Checkpoint、协调容错恢复等
-
核心有下面三个组件：
- Dispatcher: 接收作业，拉起 JobManager 来执行作业，并在 JobMaster 挂掉之后恢复作业；
- JobMaster: 管理一个 job 的整个生命周期，会向 ResourceManager 申请 slot，并将 task 调度到对应 TM ；
- ResourceManager：负责 slot 资源的管理和调度，Task manager 拉起之后会向 RM 注册。
-
-
TaskManager(TM)：负责执行一个DataFlow Graph 的各个task以及data streams 的buffer和数据交换
3. Flink 作业示例
4. Flink 如何做到流批一体
4.1 为什么需要流批一体
传统的离线数仓和实时数仓：
上述架构的痛点：
- 人力成本比较高：批、流两套系统，相同逻辑需要开发两遍
- 数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费
- 数据口径不一致：两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰
4.2 流批一体的挑战
-
批式计算相比于流式计算核心的区别：
- 无限数据集 → 有限数据集；
- 低延迟 → 实时性要求不高；
| 流式计算 | 批式计算 |
|---|---|
| 实时计算 | 离线计算 |
| 秒级内 | 分钟 小时 |
| 0-1s | 10s-1h |
| 数据流为无限数据集 | 有限数据集 |
| 低延迟、业务会感知运行中的情况 | 实时性要求不高只关注最终结果产出时间 |
4.3 Flink如何做到流批一体
-
批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
-
站在 Flink 的角度，Everything is Streams，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流。因此，不管是有边界的数据集（批式数据）还是无边界数据集，Flink 都可以天然地支持，这是 Flink 支持流批一体的基础。并且 Flink 在流批一体上，从上面的 API 到底层的处理机制都是统一的，是真正意义上的流批一体。
-
Apache Flink 主要从以下几个模块来做流批一体：
- SQL 层；
- DataStream API 层统一，批和流都可以使用 DataStream API 来开发；
- Scheduler 层架构统一，支持流批场景；
- Failover Recovery 层 架构统一，支持流批场景；
- Shuffle Service 层架构统一，流批场景选择不同的 Shuffle Service；
4.4 流批一体的 Scheduler 层
Scheduler主要负责将作业的DAG转化为分布式环境中可执行的Task
-
EAGER模式：申请一个作业所需要的全部资源，然后同时调度这个作业的全部Task，所有Task之间采取pipeline进行通信 （Stream作业场景需求资源多，源源不断计算）
- 需要所有task所需的资源全部调度才能进行
-
LAZY模式：先调度上游，等待上游产生数据或结束后再调度下游，类似Spark的Stage （Batch作业场景 需求资源少，时间长）
- 最小调度一个task即可，集群拥有1个slot就能运行
-
Pipeline Region：
- ALL_ENDGES_BLOCKING：（批处理）所有Task之间的数据交换都是BLOCKING模式，数据非实时传输，需要落盘 （12个Pipeline Region）
- ALL_EDGES_PIPELINED：（流处理）所有Task都是pipeline模式，数据产出全部直接发给下游，不做落盘 （1个Pipeline Region）
注：①由Pipeline的数据交换方式连接的Task构成为一个Pipeline Region；
②本质上,不管是流作业还是批作业,都是按照 Pipeline Region粒度来申请资源和调度任务。
4.5 流批一体的 Shuffle Service 层
-
Shuffle：在分布式计算中，用来连接上下游数据交互的过程叫做 Shuffle。实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为 Shuffle；
-
Shuffle 分类/不同实现：
- 基于文件的 Pull Based Shuffle，比如 Spark 或 MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些；、
- 基于 Pipeline 的 Push Based Shuffle，比如 Flink、Storm、Presto 等，它的特点是低延迟和高性能，但是因为 shuffle 数据没有存储下来，如果是 batch 任务的话，就需要进行重跑恢复；
-
流和批 Shuffle 之间的差异：
- Shuffle 数据的生命周期：流作业的 Shuffle 数据与 Task 是绑定的，而批作业的 Shuffle 数据与 Task 是解耦的；
- Shuffle 数据存储介质：流作业的生命周期比较短、而且流作业为了实时性，Shuffle 通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里；
- Shuffle 的部署方式：流作业 Shuffle 服务和计算节点部署在一起，可以减少网络开销，从而减少 latency，而批作业则不同。
-
Pluggable Shuffle Service：Flink 的目标是提供一套统一的 Shuffle 架构，既可以满足不同 Shuffle 在策略上的定制，同时还能避免在共性需求上进行重复开发
4.6 Flink 流批一体总结
- 经过相应的改造和优化之后，Flink 在架构设计上，针对 DataStream 层、调度层、Shuffle Service 层，均完成了对流和批的支持。
- 业务已经可以非常方便地使用 Flink 解决流和批场景的问题了。
