流/批/OLAP 一体的 Flink 引擎介绍笔记（三）｜ 青训营笔记
这是我参与「第四届青训营 -大数据场」笔记创作活动的的第3天
三、Flink 架构优化
1. 流/批/OLAP 业务场景概述
- 三种业务场景的特点
- 三种业务场景面临的挑战
2. 为什么三种场景可以用一套引擎来解决
-
场景上对比发现：
- 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
- OLAP 计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。
- Apache Flink从流式计算出发，需要想支持Batch和OLAP场景，就需要解决下面的问题:
3. Flink 如何支持 OLAP 场景
3.1 Flink 做 OLAP 的优势
-
统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎；
- 降低学习成本，仅需要学习一个引擎；
- 提高开发效率，很多 SQL 是流批通用；
- 提高维护效率，可以更集中维护好一个引擎；
-
既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛；
- 使用流处理的内存计算、Pipeline；
- 支持代码动态生成；
- 也可以支持批处理数据落盘能力；
-
相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力
- 无统计信息场景的优化；
- 开发更高效的算子；
- 使 Flink 同时兼备流、批、OLAP 处理的能力，成为更通用的框架。
3.2 Flink OLAP 场景的挑战
-
秒级和毫秒级的小作业；
-
作业频繁启停、资源碎片；
- Flink OLAP 计算相比流式和批式计算，最大的特点是 Flink OLAP 计算是一个面向秒级和毫秒级的小作业，作业在启动过程中会频繁申请内存、网络以及磁盘资源，导致 Flink 集群内产生大量的资源碎片；
-
Latency + 高 APS 要求；
- OLAP 最大的特点是查询作业对 Latency 和 QPS 有要求的，需要保证作业在 Latency 的前提下提供比较高的并发调度和执行能力，这就对 Flink 引擎提出了一个新的要求。
3.3 Flink OLAP 架构现状
-
Client：提交 SQL Query；
-
Gateway：接收 Client 提交的 SQL Query，对 SQL 进行语法解析和查询优化，生成 Flink 作业执行计划，提交给 Session 集群；
-
Session Cluster：执行作业调度及计算，并返回结果
- JobManager 管理作业的执行，在接收到 Gateway 提交过来的作业逻辑执行计划后，将逻辑执行计划转换为物理执行计划，为每个物理计算任务分配资源，将每个计算任务分发给不同的 TaskManager 执行，同时管理作业以及每个计算任务执行状态；
- TaskManager执行具体的计算任务，采用线程模型，为每个计算任务创建计算线程，根据计算任务的上下游数据依赖关系跟上游计算任务建立/复用网络连接，向上游计算任务发送数据请求，并处理上游分发给它的数据。
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.5 Apache Flink 最终演进到结果如下:
课程总结
1. Flink概述
- 1.流式计算场景及流式计算框架发展历程
- 2.业内主要流式计算框架对比、为什么Flink 能够脱颖而出
2. Flink整体架构
- 1.Flink的分层架构、Flink 当前的整体框架介绍
- 一个Flink 作业如何调度和运行起来
- Flink 如何做到流批一体;
3. Flink 架构优化
- 流/批/OLAP三种业务场景概述
- Flink 如何来支持OLAP场景需求，需要做哪些架构上的优化
