这是我参与「第四届青训营」笔记创作活动的第2天，学习内容为《流/批/OLAP一体的Flink引擎介绍》，包括Apache Flink概述和整体架构、Flink如何做到流批一体、Flink的OLAP场景面临的问题与优化思路。
本节课重点：Flink整体架构、Flink如何做到流批一体、Flink架构优化及如何支持OLAP场景需求 思维导图如下：
Apache Flink概述和整体框架
一.Apache Flink概述
- 流数据与流式计算：流数据是一组顺序、大量、快速、连续到达的数据序列,一般情况下，流数据可被视为一个随时间延续而无限增长的动态数据集合。流式计算是对流数据进行处理，是实时计算。
- 为什么需要流计算：数据实时价值更大、数据实时性需求带来了大数据计算框架模式的改变。
- Flink处理流式计算的特点：
1.完全一致性
2.低延迟
3.强大的计算模型
4.流量控制
5.乱序数据的支持
6.完备的流式语义
7.高吞吐量
8.Google Dataflow Model的开源引擎实现
二.Apache Flink的整体框架
- Flink的分层架构：
1.SDk层：SQL/Table,DataStream,Python;
2.执行引擎层：流/批数据->DAG图->分布式环境下的Task，Task之间通过shuffle传输数据；
3.状态存储层：存储算子的状态信息;
4.资源调度层：支持部署在多种环境。
- Flink总体架构：
1.Client：输入->DAG信息，提交DAG图（逻辑的）到JM；
2.JM：DAG图（逻辑的）->物理DAG图；负责整个任务的协调工作（调度task,触发task做checkpoint,协调容错恢复）；
3.TM: 执行一个DataFlow Graph各个Task以及data streams 的buffer和数据交换。
Flink如何做到流批一体
- 传统流批一体的挑战：
1.人力成本高：流、批两套系统，相同逻辑需要开发两遍；
2.数据链路冗余：两套链路，相同逻辑需要运行两遍，产生一定的资源浪费；
3.数据口径不一致：两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。
- 流式计算相比于批式计算核心的区别：
| 维度 | 流式计算 | 批式计算 |
|---|---|---|
| 数据流 | 无限数据集 | 有限数据集 |
| 时延 | 低延迟、业务会感知运行中的情况 | 实时性要求不高，只关注最终结果产出时间 |
- Flink如何做到流批一体
1.Everything is streams,有界数据集（批式数据）也是一种特殊的数据流。对于无边界数据流，处理方法是按时间段切成一个个有边界的数据集，因此Flink天然支持两种数据集；
2.Flink主要从以下几个模块做到流批一体：1.SQL层；
2.DataStream API层统一；
3.Scheduler层架构统一：Pipeline Region Scheduler机制；
4.Failover Recovery层架构统一；
5.Shuffle Service层架构统一：实现方式是基于文件的Pull Based Shuffle和基于Pipeline的Push Based Shuffle，统一两种模式的架构——Pluggable Shuffle Service。
Flink的OLAP场景面临的问题与优化思路
OLAP
- OLAP:对实时结果数据做实时多维分析，帮助后面活动决策，要求其查询在秒级且高并发查询；
Flink如何支持OLAP场景
- Flink做OLAP的优势
- 引擎统一：降低学习成本、提高开发效率、提高维护效率；
- 既有优势：内存计算、Code-gen、Pipeline Shuffle、Session模式的MPP架构；
- 生态支持：跨数据源查询支持、TCP-DS基准测试性能强。
- Flink OLAP场景的挑战
- 秒级和毫秒级的小作业；
- 作业频繁启停，资源碎片；
- Latency+ QPS的要求。
- Flink OLAP架构现状
- Client:提交SQL Query;
- Gateway:接收SQL Query->语法解析和查询优化->生成Flink作业执行计划->提交给Session集群；
- Session Cluster:执行作业调度及计算，并返回结果。
Flink在OLAP架构的问题与设想
- 架构与功能模块
- JM与FM在一个进程内启动，无法对JM进行水平扩展；
- Gateway与Flink Session Cluster互相独立，无法进行统一管理。
- 作业管理及部署模块
- JM处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存；
- TM部署计算任务时，任务初始化部分耗时严重，消耗大量GPU。
- 资源管理及计算任务调度
- 资源申请及资源释放流程链路过长；
- Slot作为资源管理单元，JM管理Slot资源，导致JM无法感知到TM维度的资源分布，使得资源管理完全依赖于RM。
- 其他
- 作业心跳与Failover机制，并不合适AP这种秒级或毫秒级计算场景；
- AP目前使用Batch算子进行计算，这些算子初始化比较耗时。
Flink最终演进结果:
