流/批/OLAP一体的Flink引擎介绍 | 青训营笔记
这是我参与「第四届青训营 - 大数据专场」笔记创作活动的的第2天。
一、本堂课重点内容：
01.产生流式计算的需求、Flink能够脱颖而出的原因，Flink当前的开源生态
02.Flink当前的整体架构，Flink作业的调度和运行，Flink如何做到流批一体
03.流/批/OLAP三种业务场景概述，Flink如何来支持OLAP场景需求，以及有哪些架构上的优化
04.由两个字节内部真实的案例场景，介绍Flink在流批一体以及OLAP上的实践
二、详细知识点介绍：
1. Flink概述
1.1 Apache Flink 的诞生背景
1.1.1 什么是大数据
大数据（Big Data）：指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合。
特点：Value（价值化）、Volumes（海量化）、Velocity（快速化）、Variety（多样化）
1.1.2 大数据计算架构发展历史
1.1.3 为什么需要流式计算
大数据的实时性带来价值更大，比如：
-
监控场景：如果能实时发现业务系统的健康状态，就能提前避免业务故障； -
金融风控：如果实时监测出异常交易的行为，就能及时阻断风险的发生； -
实时推荐：比如在抖音，如果可以根据用户的行为数据发掘用户的兴趣、偏好，就能向用户推荐更感兴趣的内容； -
...
大数据实时性的需求，带来了大数据计算架构模式的变化：
1.2 为什么 Apache Flink 会脱颖而出
1.2.1 流式计算引擎发展历程
大数据如果从 Google 对外发布 MapReduce 论文算起，已经前后跨越将近二十年，业内常用计算框架演化历史（红框是流式计算框架）
图源：教学PPT
1.2.2 流式计算引擎对比
| Storm | Spark Streaming | Flink | |
|---|---|---|---|
| Streaming Model | Native | mini-batch | Native |
| 一致性保证 | At Least/Most Once | Exactly-Once | Exactly-Once |
| 延迟 | 低延迟（毫秒级） | 延迟较高（秒级） | 低延迟（毫秒级） |
| 吞吐 | Low | High | High |
| 容错 | ACK | RDD Based Checkpoint | Checkpoint(Chandy-Lamport) |
| StateFul | No | Yes（DStream） | Yes（Operator） |
| SQL 支持 | No | Yes | Yes |
1.2.3 Why Flink
Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams.Flink has been designed to run in all common cluster environments,perform computations at in-memory speed and at any scale. ——来自 Apache Flink 社区官方介绍
1.3 Apache Flink 开源生态
Flink 社区的开源生态
图源：教学PPT
2. Flink 整体架构
2.1 Flink 分层架构
-
SDK层：Flink 的 SDK 目前主要有三类，
SQL/Table、DataStream、Python； -
执行引擎层（Runtime 层）：执行引擎层提供了统一的 DAG ，用来描述数据处理的 Pipeline ，不管是流还是批，都会转化为 DAG图，调度层再把 DAG 转化成分布式环境下的 Task，Task 之间通过 shuffle 传输数据；
-
状态存储层：负责存储算子的状态信息；
-
资源调度层：目前 Flink 可以支持部署在多种环境。
2.2 Flink 整体架构
一个 Flink 集群，主要包含以下两个核心组件：
-
JobManager(JM)：负责整个任务的协调工作，包括：调度 task、触发协调 Task 做 Checkpoint、协调容错恢复等； -
TaskManager(TM)：负责执行一个 DataFlow Graph 的各个 task 以及 data streams 的buffer 和数据交换。
图源：Apache Flink Documentation-Anatomy of a Flink Cluster
—— JobManager 职责
图源：教学PPT
-
Dispatcher:接受作业，拉起 JobManager 来执行作业，并在JobMaster 挂掉之后恢复作业；
-
JobMaster:管理一个 job 的整个生命周期，会向 ResourceManager 申请 slot，并将 task调度到对应 TM 上；
-
ResourceManager:负责 slot 资源的管理和调度，Task manager 拉起之后会向 RM 注册；
2.3 Flink 作业示例
流式的 WordCount 示例，从 kafka 中读取一个实时数据流，每10s统计一次单词出现次数，DataStream 实现代码如下：
DataStream<String> lines = env.addSource(new FlinkKafkaConsumer<>(...));
DataStream<Event> events = lines.map((line) -> parse(line));
DataStream<Statistics> stats = events
.keyBy(event -> event.id)
.timeWindow(Time.seconds(10))
.apply(new MyWindowAggregationFunction());
stats.addSink(new BucketingSink(path));
业务逻辑转换为一个 Streaming DataFlow Graph
假设作业的 sink 算子的并发配置为 1，其余算子并发为 2
紧接着会将上面的 Streaming DataFlow Graph 转化为 Parallel Dataflow（内部叫 Execution Graph）：
图源：Learn Flink: Hands-On Training
为了更高效地分布式执行，Flink 会尽可能地将不同的 operator 链接（chain）在一起形成 Task。 这样每个 Task 可以在一个线程中执行，内部叫做 OperatorChain，如下图的 source 和 map 算子可以和 chain 在一起。
最后将上面的 Task 调度到具体的 TaskManager 中的 slot 中执行，一个 slot 只能运行同一个 task 的 subTask
图源：Apache Flink Documentation-Anatomy of a Flink Cluster
2.4 Flink 如何做到流批一体
2.4.1 为什么需要流批一体
举个例子：
-
在抖音中，实时统计一个短视频的播放量、点赞数，也包括抖音直播间的实时观看人数等；
-
在抖音中，按天统计创造者的一些数据信息，比如昨天的播放量有多少、评论量多少、广告收入多少；
上述架构有一些痛点：
-
人力成本比较高：批、流两套系统，相同逻辑需要开发两遍；
-
数据链路冗余：本身计算内容是一致的，由于是两套链路，相同的逻辑需要运行两遍，产生一定的资源浪费；
-
数据口径不一致：两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。
2.4.2 流批一体的挑战
流和批业务场景的特点：
| 流式计算 | 批式计算 |
|---|---|
| 实时计算 | 离线计算 |
| 延迟在秒级以内 | 处理时间为分钟到小时级别，甚至天级别 |
| 0 ~ 1s | 10s ~ 1h+ |
| 广告推荐、金融风控 | 搜索引擎构建索引、批式数据分析 |
批式计算相比于流式计算核心的区别：
| 维度 | 流式计算 | 批式计算 |
|---|---|---|
| 数据流 | 无线数据集 | 有限数据集 |
| 时延 | 低延迟、业务会感知运行中的情况 | 实时性要求不高，只关注最终结果产出时间 |
2.4.3 Flink 如何做到流批一体
为什么可以做到流批一体？
- 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
因此，理论上我们是可以用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。
图源：教学PPT
站在 Flink 的角度，Everything is Streams，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流。
因此，不管是有边界的数据集（批式数据）还是无边界数据集，Flink 都可以天然地支持，这是 Flink 支持流批一体的基础。并且 Flink 在流批一体上，从上面的 API 到底层的处理机制都是统一的，是真正意义上的流批一体。
Apache Flink 主要从以下几个模块来做流批一体：
- SQL层；
- DataStream API 层统一，批和流都可以使用 DataStream API 来开发；
- Scheduler 层架构统一，支持流批场景；
- Failover Recovery 层架构统一，支持流批场景；
- Shuffle Service 层架构统一，流批场景选择不同的Shuffle Service。
2.4.4 流批一体的 Scheduler 层
Scheduler 主要负责讲作业的 DAG 转化为在分布式环境中可以执行的 Task
在1.12之前的 Flink 版本中，Flink 支持以下两种调度模式：
| 模式 | 特点 | 场景 |
|---|---|---|
| EAGER | 申请一个作业所需要的全部资源，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信 | Stream 作业场景 |
| LAZY | 先调度上游，等待上游产生数据或结束后再调度下游，类似 Spark 的 Stage 执行模式 | Batch 作业场景 |
-
由 Pipeline 的数据交换方式连接的 Task 构成一个 Pipeline Region ；
-
本质上，不管是流作业还是批作业，都是按照 Pipeline Region 粒度来申请资源和调度任务。
-
ALL_EDGES_BLOCKING：
-
- 所有 Task 之间的数据交换都是 BLOCKING 模式；
-
- 分为12个 pipeline region ;
-
ALL_EDGES_PIPELINED：
-
- 所有 Task 之间的数据交换都是 PIPELINE 模式；
-
- 分为1个 pipeline region ;
2.4.5 流批一体的 Shuffle Service 层
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，而批作业则不同。
Flink 对于流和批提供的两种类型的 Shuffle，虽然 Streaming 和 Batch Shuffle 在具体的策略上存在一定的差异，但本质上都是为了对数据进行 Re-Partition，因此不同的 Shuffle 之间是存在一定的共性的。
所以 Flink 的目标是提供一套统一的 Shuffle 架构，既可以满足不同 Shuffle 在策略上的定制，同时还能避免在共性需求上进行重复开发。
在 Streaming 和 OLAP 场景- 为了性能的需求，通常会使用基于 Pipeline 的 Shuffle 模式
在 Batch 场景- 一般会选取 Blocking 的 Shuffle 模式
图源：FLIP-31：Pluggable Shuffle Service
为了统一 Flink 在 Streaming 和 Batch 模式下的 Shuffle 架构，Flink 实现了一个 Pluggable 的 Shuffle Service 框架，抽象出一些公共模块。
对于 Shuffle Service，Flink 开源社区已经支持：
-
Netty Shuffle Service：既支持 pipeline 又支持 blocking，Flink 默认的 Shuffle Service 策略；
-
Remote Shuffle Service：既支持 pipeline 又支持 blocking，不过对于 pipeline 模式，走 remote 反而会性能下降，主要是有用在 batch 的 blocking 场景，字节内部是基于 CSS 来实现的 RSS。
经过相应的改造和优化之后，Flink 在架构设计上，针对 DataStream 层、调度层、Shuffle Service 层，均完成了对流和批的支持。
至此，业务已经可以非常方便地使用 Flink 解决流和批场景的问题了。
3. Flink 架构优化
3.1 流/批/OLAP 业务场景概述
在实际生产环境中，针对不同应用场景，对数据处理的要求时不同的。
举个例子：
- 在抖音的一些推广活动中，运营同学需要对一些实时产出的结果数据做一些实时多维分析，来帮助后面活动的决策。
三种业务场景的特点比对：
| 流式计算 | 批式计算 | 交互式分析 |
|---|---|---|
| 实时计算 | 离线计算 | OLAP |
| 延迟在秒级以内 | 处理时间为分钟到小时级别，甚至天级别 | 处理时间秒级 |
| 0 ~ 1s | 10s ~ 1h+ | 1 ~ 10s |
| 广告推荐、金融风控 | 搜索引擎构建索引、批式数据分析 | 数据分析 BI 报表 |
三种业务场景的解决方案的要求以及带来的挑战是：
| 模块 | 流式计算 | 批式计算 | 交互式分析（OLAP） |
|---|---|---|---|
| SQL | Yes | Yes | Yes |
| 实时性 | 高、处理延迟毫秒级别 | 低 | 高、查询延迟在秒级，但要求高并发查询 |
| 容错能力 | 高 | 中，大作业失败重跑代价高 | No，失败重试即可 |
| 状态 | Yes | No | No |
| 准确性 | Excatly Once，要求高，重跑需要恢复之前的状态 | Excatly Once，失败重跑即可 | Excatly Once，失败重跑即可 |
| 扩展性 | Yes | Yes | Yes |
通过前面的对比分析，可以发现：
-
批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
-
而 OLAP 计算是一种特殊的批式计算，它对并发和实时性要求高，其他情况与普通批式作业没有特别大区别。
因此，理论上，我们是可以用一套引擎架构来解决上述三种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。
3.2 三种业务场景为什么可以用一套引擎来解决
Apache Flink 从流式计算出发，需要想支持 Batch 和 OLAP 场景，就需要解决下面的问题：
3.3 Flink 的 OLAP 的优化之路
3.3.1 Flink 做 OLAP 的优势
3.3.2 Flink OLAP 场景的挑战
3.3.3 Flink OLAP 架构现状
-
Client：提交 SQL Query；
-
Gateway
- 接收 Client 提交的 SQL Query，对 SQL 进行语法解析和查询优化，生成 Flink 作业执行计划，提交给 Session 集群；
-
Session Cluster
- 执行作业调度及计算，并返回结果
图源：教学PPT
3.3.4 Flink 在 OLAP 架构的问题与设想
架构与功能模块：
-
JobManager 与 ResourceManager 在一个进程内启动，无法对 JobManager 进行水平扩展；
-
Gateway 与 Flink Session Cluster 互相独立，无法进行统一管理。
作业管理及部署模块：
-
JobManager 处理和调度作业时，负责的功能比较多，导致但作业处理时间长、并占用了过多的内存；
-
TaskManager 部署计算任务时，任务初始化部分耗时严重，消耗大量 CPU。
资源管理及计算任务调度：
-
资源申请及资源释放流程链路过长；
-
Slot 作为资源管理单元，JM 管理 Slot 资源，导致 JM 无法感知到 TM 维度的资源分布，使得资源管理完全依赖于 ResourceManager
其他：
-
作业心跳与 Failover 机制，并不适合 AP 这种秒级或毫秒级计算场景；
-
AP 目前使用 Batch 算子进行计算，这些算子初始化比较耗时。
3.3.5 总结
Apache Flink 最终演进到结果如下：
图源：Apache Flink —— Stateful Computations over Data Streams
4. Flink 使用案例
4.1 电商流批一体实践
4.2 字节 Flink OLAP 实践
三、课堂内容总结：
- Flink 概述
-
流式计算场景及流式计算框架发展历史
-
业内主要流式计算框架对比、为什么 Flink 能够脱颖而出；
- Flink 整体架构
-
Flink的分层架构、Flink 当前的整体架构介绍；
-
一个 Flink 作业如何调度和运行起来；
-
Flink 如何做到流批一体；
- Flink 架构优化
-
流/批/OLAP 三种业务场景概述；
-
Flink 如何来支持 OLAP 场景需求，需要做哪些架构上的优化；
- 精选案例讲解
