二、【计算】流|批|OLAP一体的Flink引擎（下） | 青训营笔记字节跳动青训营大数据专场流|批|OLAP一体

这是我参与「第四届青训营」笔记创作活动的第3天

一、Flink 架构优化

1 流/批/OLAP 业务场景概述

三种业务场景的特点

三种业务场景面临的挑战

2 为什么三种场景可以用一套引擎来解决

场景上对比发现：
- 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
- OLAP 计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。

3 Flink 如何支持 OLAP 场景

Flink 做 OLAP 的优势
- 统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎；
  - 降低学习成本，仅需要学习一个引擎；
  - 提高开发效率，很多 SQL 是流批通用；
  - 提高维护效率，可以更集中维护好一个引擎；
- 既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛；
  - 使用流处理的内存计算、Pipeline；
  - 支持代码动态生成；
  - 也可以支持批处理数据落盘能力；
- 相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力
  - 无统计信息场景的优化；
  - 开发更高效的算子；
  - 使 Flink 同时兼备流、批、OLAP 处理的能力，成为更通用的框架。
Flink OLAP 场景的挑战
- 秒级和毫秒级的小作业；
- 作业频繁启停、资源碎片；
  - Flink OLAP 计算相比流式和批式计算，最大的特点是 Flink OLAP 计算是一个面向秒级和毫秒级的小作业，作业在启动过程中会频繁申请内存、网络以及磁盘资源，导致 Flink 集群内产生大量的资源碎片；
- Latency + 高 APS 要求；
  - OLAP 最大的特点是查询作业对 Latency 和 QPS 有要求的，需要保证作业在 Latency 的前提下提供比较高的并发调度和执行能力，这就对 Flink 引擎提出了一个新的要求。
Flink OLAP 架构现状
- Client：提交 SQL Query；
- Gateway：接收 Client 提交的 SQL Query，对 SQL 进行语法解析和查询优化，生成 Flink 作业执行计划，提交给 Session 集群；
- Session Cluster：执行作业调度及计算，并返回结果。
  - JobManager 管理作业的执行，在接收到 Gateway 提交过来的作业逻辑执行计划后，将逻辑执行计划转换为物理执行计划，为每个物理计算任务分配资源，将每个计算任务分发给不同的 TaskManager 执行，同时管理作业以及每个计算任务执行状态；
  - TaskManager执行具体的计算任务，采用线程模型，为每个计算任务创建计算线程，根据计算任务的上下游数据依赖关系跟上游计算任务建立/复用网络连接，向上游计算任务发送数据请求，并处理上游分发给它的数据。

Flink 在 OLAP 架构上的问题与设想
- 架构与功能模块：
  - JobManager 与 ResourceManager 在一个进程内启动，无法对JobManager 进行水平扩展；
  - Gateway 与 Flink Session Cluster 互相独立，无法进行统一管理；
- 作业管理及部署模块：
  - JobManager 处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存；
  - TaskManager 部署计算任务时，任务初始化部分耗时验证，消耗大量 CPU；
- 资源管理及计算任务调度：
  - 资源申请及资源释放流程链路过长；
  - Slot 作为资源管理单元，JM 管理 slot 资源，导致 JM 无法感知到 TM 维度的资源分布，使得资源管理完全依赖于 ResourceManager；
- 其他：
  - 作业心跳与 Failover 机制，并不合适 AP 这种秒级或毫秒级计算场景；
  - AP 目前使用 Batch 算子进行计算，这些算子初始化比较耗时；
设想如下：

总结

批式数据处理场景以及OLAP交互式业务场景，都可以转化成对流式数据的处理，根据这一共同点，Flink内部实现了将以上三种场景处理模块的相同部分提取出来，加以优化，就形成了流批OLAP一体的Flink引擎；但对于OLAP场景来说，由于其对数据实时性查询（流式数据处理）要求较高，且需要高并发，目前的Flink内部架构以及作业能力还无法满足（在架构与功能模块，作业管理及部署模块，资源管理及计算任务调度模块），尚有较大的提升空间。