流/批/OLAP一体的Flink引擎介绍(3) | 青训营笔记

134 阅读4分钟

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

Flink架构优化

流/批/OLAP业务场景概述

在实际生产环境中,针对不同的应用场景,我们对数据处理的要求是不同的:

1.有些场景下,只需离线处理数据,对实时性要求不高,但要求系统吞吐率高,典型的应用是搜索引擎构建索引;

2.有些场景下,需对数据进行实时分析,要求每条数据处理延迟尽可能低,典型的应用是广告推荐、金融风控场景。

三种业务场景的特点比对:

流式计算批式计算交互式计算
实时计算离线计算OLAP
延迟在秒级内处理时间为分钟到小时级别,甚至天级别处理时间秒级
0~1s10s~1h+1~10s
广告推荐、金融风控搜索引擎构建索引、批式数据分析数据分析BI报表

三种业务场景的解决方案的要求及带来的挑战

模块流式计算批式计算交互式计算
SQLYesYesYes
实时性高、处理延迟毫秒级别高、查询延迟在秒级。但要求高并发查询
容错能力中,大作业失败重跑代价高No,失败重试即可
状态YesNoNo
准确性Exactly Once,要求高,重跑需要恢复之前的状态Exactly Once,失败重跑即可Exactly Once,失败重跑即可
扩展性YesYesYes

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

通过前面的对比分析,可以发现:

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的优势

image.png

1、Flink在流批一体基础上加上OLAP(流处理、批处理、OLAP 统一使用 Flink 引擎)

2、利用 Flink 已有的很多特性,使 OLAP 使用场景更为广泛

3、支持多种存储引擎

Flink OLAP场景的挑战

1、面向秒级处理的计算,Flink是个流式计算存储引擎,会频繁的启停作业,会产生磁盘或网络上的开销,需要对AP进行优化

2、AP最大的特点是查询对Latency和QBS要求比较高

image.png

Flink OLAP架构现状

  • Client:提交 SQL Query;

提交SQL语句

  • Gateway

    • 接收Client提交的 SQL Query,对SQL进行语法解析和查询优化,生成Flink 作业执行计划,提交给Session集群;
  • Session Cluster

    • 提前创建集群,数据集过来后不需要另外创建TM去申请资源,作业提交给JM

    • 执行作业调度及计算,并返回结果。

架构与功能模块:

  1. JobManager 与 ResourceManagelr在一个进程内启动,无法对JobManager进行水平扩展;

JobManager 负责作业提交及分发工作

ResourceManagelr负责资源工作

由于并发的需求,需要对JobManager进行水平扩展

  1. Gateway 与Flink Session Cluster 互相独立,无法进行统一管理

Gateway 对SQL进行解析优化,但受Flink版本限制

作业管理及部署模块:

  1. JobManager 处理和调度作业时,负责的功能比较多,导致单作业处理时间长、并占用了过多的内存;

在高并发场景下影响性能

  1. TaskManager 部署计算任务时,任务初始化部分耗时严重,消耗大量CPU

TM需要对task作初始化操作,不管是流还是批,都能一次性初始化,但是在OLAP场景需要不断创建task

Flink在OLAP架构的问题与设想

资源管理及计算任务调度

1.资源申请及资源释放流程链路过长

解决资源申请和资源释放的链路性能加强

  1. Slot 作为资源管理单元,JM管理slot资源,导致JM无法感知到TM维度的资源分布,使得资源管理完全依赖于ResourceManager

其他

1.作业心跳与Failover机制,并不合适AP这种秒级或毫秒级计算场景;

2.AP目前使用Batch 算子进行计算,这些算子初始化比较耗时