这是我参与「第四届青训营」笔记创作活动的第3天。
Flink 架构优化
流/批/OLAP 业务场景概述
特点比较
解决方案和挑战
三种场景为何可以用一套引擎来解决
对比发现：批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
OLAP 计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。
Flink 如何支持 OLAP 场景
Flink 做 OLAP 的优势
统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎；降低学习成本，仅需要学习一个引擎；提高开发效率，很多 SQL 是流批通用；提高维护效率，可以更集中维护好一个引擎；
既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛；使用流处理的内存计算、Pipeline；支持代码动态生成；也可以支持批处理数据落盘能力；
相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力无统计信息场景的优化；开发更高效的算子；使 Flink 同时兼备流、批、OLAP 处理的能力，成为更通用的框架。
面临的挑战
秒级和毫秒级的小作业；
作业频繁启停、资源碎片；
Latency + 高 APS 要求；
Flink OLAP 架构现状
Client： 提交 SQL Query；
Gateway： 接收 Client 提交的 SQL Query，对 SQL 进行语法解析和查询优化，生成 Flink 作业执行计划，提交给 Session 集群；
Session Cluster： 执行作业调度及计算，并返回结果。
Flink 在 OLAP 架构上的问题与设想
架构与功能模块：
JobManager 与 ResourceManager 在一个进程内启动，无法对JobManager 进行水平扩展； Gateway 与 Flink Session Cluster 互相独立，无法进行统一管理；
作业管理及部署模块：
JobManager 处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存；
TaskManager 部署计算任务时，任务初始化部分耗时验证，消耗大量 CPU；
资源管理及计算任务调度：
资源申请及资源释放流程链路过长； Slot 作为资源管理单元，JM 管理 slot 资源，导致 JM 无法感知到 TM 维度的资源分布，使得资源管理完全依赖于 ResourceManager；
其他：
作业心跳与 Failover 机制，并不合适 AP 这种秒级或毫秒级计算场景；AP 目前使用 Batch 算子进行计算，这些算子初始化比较耗时；
总结
本节课程围绕Flink引擎为重点，首先带我们回顾了大数据计算架构的发展背景，初步了解hadoop、spark、flink的特点和适用范围。接着重点剖析了flink的整体架构和其底层实现原理，受益匪浅。
