这是我参与「第四届青训营 」笔记创作活动的的第6天
Flink架构优化
流/批/OLAP业务场景概述
在实际生产环境中,针对不同的应用场景,我们对数据处理的要求是不同的:
1.有些场景下,只需离线处理数据,对实时性要求不高,但要求系统吞吐率高,典型的应用是搜索引擎构建索引;
2.有些场景下,需对数据进行实时分析,要求每条数据处理延迟尽可能低,典型的应用是广告推荐、金融风控场景。
三种业务场景的特点比对:
| 流式计算 | 批式计算 | 交互式计算 |
|---|---|---|
| 实时计算 | 离线计算 | OLAP |
| 延迟在秒级内 | 处理时间为分钟到小时级别,甚至天级别 | 处理时间秒级 |
| 0~1s | 10s~1h+ | 1~10s |
| 广告推荐、金融风控 | 搜索引擎构建索引、批式数据分析 | 数据分析BI报表 |
三种业务场景的解决方案的要求及带来的挑战
| 模块 | 流式计算 | 批式计算 | 交互式计算 |
|---|---|---|---|
| SQL | Yes | Yes | Yes |
| 实时性 | 高、处理延迟毫秒级别 | 低 | 高、查询延迟在秒级。但要求高并发查询 |
| 容错能力 | 高 | 中,大作业失败重跑代价高 | No,失败重试即可 |
| 状态 | Yes | No | No |
| 准确性 | Exactly Once,要求高,重跑需要恢复之前的状态 | Exactly Once,失败重跑即可 | Exactly Once,失败重跑即可 |
| 扩展性 | Yes | Yes | Yes |
为什么三种场景可以用一套引擎来解决
通过前面的对比分析,可以发现:
1.批式计算是流式计算的特例,Everything is Streams,有界数据集(批式数据)也是一种数据流、一种特殊的数据流;
2.而OLAP计算是一种特殊的批式计算,它对并发和实时性要求更高,其他情况与普通批式作业没有特别大区别。
因此,理论上,我们是可以用一套引擎架构来解决上述三种场景,只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。
OLAP可以看作短查询
Apache Flink从流式计算出发,需要想支持Batch和 OLAP场景,就需要解决下面的问题:
Batch场景需求
- 流批一体支持
- Unify DataStream API
- Scheduler
- Shuffle Service
- Failover Recovery
OLAP场景需求
- 短查询作业场景
- 高并发支持
- 极致处理性能
Flink如何支持OLAP场景
Flink做OLAP的优势
1、Flink在流批一体基础上加上OLAP(流处理、批处理、OLAP 统一使用 Flink 引擎)
2、利用 Flink 已有的很多特性,使 OLAP 使用场景更为广泛
3、支持多种存储引擎
Flink OLAP场景的挑战
1、面向秒级处理的计算,Flink是个流式计算存储引擎,会频繁的启停作业,会产生磁盘或网络上的开销,需要对AP进行优化
2、AP最大的特点是查询对Latency和QBS要求比较高
Flink OLAP架构现状
- Client:提交 SQL Query;
提交SQL语句
-
Gateway
- 接收Client提交的 SQL Query,对SQL进行语法解析和查询优化,生成Flink 作业执行计划,提交给Session集群;
-
Session Cluster
-
提前创建集群,数据集过来后不需要另外创建TM去申请资源,作业提交给JM
- 执行作业调度及计算,并返回结果。
-
架构与功能模块:
- JobManager 与 ResourceManagelr在一个进程内启动,无法对JobManager进行水平扩展;
JobManager 负责作业提交及分发工作
ResourceManagelr负责资源工作
由于并发的需求,需要对JobManager进行水平扩展
- Gateway 与Flink Session Cluster 互相独立,无法进行统一管理
Gateway 对SQL进行解析优化,但受Flink版本限制
作业管理及部署模块:
- JobManager 处理和调度作业时,负责的功能比较多,导致单作业处理时间长、并占用了过多的内存;
在高并发场景下影响性能
- TaskManager 部署计算任务时,任务初始化部分耗时严重,消耗大量CPU
TM需要对task作初始化操作,不管是流还是批,都能一次性初始化,但是在OLAP场景需要不断创建task
Flink在OLAP架构的问题与设想
资源管理及计算任务调度
1.资源申请及资源释放流程链路过长
解决资源申请和资源释放的链路性能加强
- Slot 作为资源管理单元,JM管理slot资源,导致JM无法感知到TM维度的资源分布,使得资源管理完全依赖于ResourceManager
其他
1.作业心跳与Failover机制,并不合适AP这种秒级或毫秒级计算场景;
2.AP目前使用Batch 算子进行计算,这些算子初始化比较耗时