Flink 引擎简介 ｜ 青训营笔记
这是我参与「第四届青训营 」笔记创作活动的的第2天
参考链接：
1.第四届字节跳动青训营 前言：
从批式计算到流式计算：
Flink技术特征
从产品技术来看，Flink 具备如下流计算技术特征：
- 完全一次保证：故障后应正确恢复有状态运算符中的状态；
- 低延迟：越低越好。许多应用程序需要亚秒级延迟；
- 高吞吐量：随着数据速率的增长，通过管道推送大量数据至关重要；
- 强大的计算模型：框架应该提供一种编程模型，该模型不限制用户并允许各种各样的应用程序在没有故障的情况下，容错机制的开销很低；
- 流量控制：来自慢速算子的反压应该由系统和数据源自然吸收，以避免因消费者缓慢而导致崩溃或降低性能；
- 乱序数据的支持：支持由于其他原因导致的数据乱序达到、延迟到达后，计算出正确的结果；
- 完备的流式语义：支持窗口等现代流式处理语义抽象；
- Google Dataflow Model 的开源引擎实现。
\
\
流式计算引擎能力对比：
\
Flink 分层架构
架构图如下：
\
Flink有以下几层：
- SDK 层：Flink的SDK目前主要有三类 SQL/Table、DataStream、 Python;
api -> Flink's APIs Overview；
- 执行引擎层（Runtime 层）：执行引擎层提供了统一的 DAG，用来描述数据处理的 Pipeline，不管是流还是批，都会转化为 DAG 图，调度层再把 DAG 转化成分布式环境下的 Task，Task 之间通过 Shuffle 传输数据；
- 调度：Jobs and Scheduling；
- Task 生命周期：Task Lifecycle；
- Flink Failover 机制：Task Failure Recovery；
- Flink 反压概念及监控：Monitoring Back Pressure；
- Flink HA 机制：Flink HA Overview；
- 状态存储层：负责存储算子的状态信息
- 资源调度层:目前Flink可以支持部署在多种环境。
Flink 整体架构（Flink Architecture）
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 和数据交换。
\
Flink 作业示例
- Flink 作业示例（Flink Learn: Hands-On Training）
- ExecutionGraph 生成：DataStream API Code --> JobGraph --> ExecutionGraph（Parallelized）
- OperatorChain：
WordCount示例：
从kafka中读取一个实时数据流，每10s统计一次单词出现次数。 官方文档
1.DataStream 实现代码如下:
2.业务逻辑转换为一个Streaming DataFlow Graph
3.假设作业的sink算子的并发配置为1，其余算子并发为2，紧接着会将上面的Streaming DataFlow Graph转化Parallel Dataflow (内部叫Execution Graph) :
4.为了更高效地分布式执行，Flink 会尽可能地将不同的operator链接(chain) 在一起形成Task.这样每个Task可以在一个线程中执行， 内部叫做OperatorChain,如下图的source和map算子可以Chain在一起。
5.最后将上面的Task调度到具体的TaskManager中的slot中执行，一个Slot只能运行同一个task的subTask
Flink 如何做到流批一体
为什么需要流批一体
- 一些业务场景，除了实时的数据统计需求，为了确认运营或产品的效果，用户同时还需要和历史数据做比较，比如，抖音一些直播数据的统计；
- 这种架构有一些痛点：
- 人力成本比较高：批、流两套系统，相同逻辑需要开发两遍；
- 数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费；
- 数据口径不一致：两套系统、两套算子、两套 UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。
流批一体的挑战
- 批式计算相比于流式计算核心的区别：
- 无限数据集 --> 有限数据集；
- 低延迟 --> 实时性要求不高；
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；
流批一体的 Scheduler 层
- Scheduler 主要负责将作业的 DAG 转化为在分布式环境中可以执行的 Task；
- 1.12 之前的 Flink 版本，Flink 支持两种调度模式：
- EAGER（Streaming 场景）：申请一个作业所需要的全部资源，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信；
- LAZY（Batch 场景）：先调度上游，等待上游产生数据或结束后再调度下游，类似 Spark 的 Stage 执行模式。
- Pipeline Region Scheduler 机制：FLIP-119 Pipelined Region Scheduling - Apache Flink - Apache Software Foundation；
流批一体的 Shuffle Service 层
（FLIP-31: Pluggable Shuffle Service - Apache Flink - Apache Software Foundation）
- 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 在策略上的定制，同时还能避免在共性需求上进行重复开发
Flink 流批一体总结
- 经过相应的改造和优化之后，Flink 在架构设计上，针对 DataStream 层、调度层、Shuffle Service 层，均完成了对流和批的支持。
- 业务已经可以非常方便地使用 Flink 解决流和批场景的问题了。
