这是我参与「第四届青训营 」笔记创作活动的第1天
流/批/OLAP一体的Flink引擎介绍
Flink特点：
1.支持SQL
2.流批一体
3.毫秒级，低延迟
4.状态容错
5.自己支持状态管理（operator），不依赖外部系统
6.Dataflow编程模型 window等高阶需求支持友好
6.exactly-once
Flink架构
分层架构
SDK层：Flink的SDK（软件开发包）主要三类，SQL/Table、DataStream、Python
执行引擎（runtime）层：提供了统一的DAG，用来描述数据处理的pipeline（业务逻辑）。将数据转化为DAG图，再把DAG调度、转化成分布式环境下的Task，各节点的Task之间通过Shuffle传输数据。
状态存储层：负责存储算子的状态信息。
资源管理层：Flink可以支持部署在多个环境。Yarn/K8s等。
总体架构
用户代码抽象成逻辑图(DAG图)———————————————如何转成DAG图
将此逻辑图交给JM，形成物理执行图。
将物理执行图的逻辑和Task调度到不同TM节点—————————如何调度
Flink的两个核心组件
1. JobManager(JM):负责整个任务的协调工作【调度task，协调容错恢复】。
2. TaskManager(TM):负责执行一个Dataflow Graph的各个Task以及data streams的buffer和数据交换。
JobManager(JM)可细分三个部分：
1.Dispatcher:接收作业，唤醒或者恢复JM的作业
2.JobMaster:管理job生命周期，向ResourceManager申请slot(资源)，并将task调度给TM
3.ResourceManager:负责slot资源的管理调度，接受管理TM的注册
Flink会尽可能将不同的operator链接（chain）成一个Task，放入一个slot中，会更高效。
Flink的流批一体
目前的业务数据处理形式，分成实时数仓和离线数仓，存在以下缺陷：
1.批、流两套系统，逻辑需要开发两遍，人力成本高。
2.数据链路冗余，计算内容一致但要两个链路运行，产生浪费
3.数据口径不同，两套系统、算子、UDF，会产生误差，难以解释、利用。
而批式数据（有限数据集）可以视为一种特殊的数据流（流式数据、无线数据集）。因此理论上可实现流批一体。
Apache Flink从以下几个模块实现流批一体：
1. SQL层
2. Datastream API层统一（功能）
3. Scheduler层（调度）
4. Failover Recovery层（容错）
5. Shuffle Service层
Scheduler层
负责将作业的DAG转化为Task。两种调度模式：EAGER/LAZY
LAZY需要的空间资源少一些，但是耗时更长。
Pipeline的数据交换方式连接的task构成Pipeline Region。
本质上，流作业和批作业都是按照pipeline region粒度来申请资源和调度任务。
（批作业中的task数据交换靠blocking，因此分成了若干task个数的pipeline region）
（流作业中的task数据交换如果全靠pipeline，因此分成了1个数的pipeline region）
Shuffle service层
基本概念：分布式计算中，所有涉及到上下游衔接的过程都可理解为shuffle。
Shuffle的实现通常分两种：
1.基于文件的Pull Based Shuffle.(比如spark、MR，高容错批处理)
2.基于Pipeline的Push Based Shuffle(比如Flink、Storm，低延迟 高性能，流处理)
流/批的shuffle差异
Shuffle数据的生命周期：流作业的Shuffle和task是绑定的，批作业的Shuffle和task解耦。
Shuffle数据存储介质：流作业生命周期短、实时性，通常存储在内存中，批处理的shuffle 存储在磁盘内。
Shuffle的部署方式：流作业Shuffle服务和计算节点部署在一起，网络开销少。
流/批一体的Shuffle Service层
在streaming、OLAP场景用基于pipeline的Shuffle；
在batch场景用Blocking的shuffle。
开源社区支持的Shuffle Service
1. Netty Shuffle Service:基础支持pipeline又支持blocking，Flink默认的Shuffle Service策略
2. Remote Shuffle Service:基础支持pipeline又支持blocking，对于pipeline模式，走remote（多一层网络传输）反而会性能下降，主要是有用在batch的blocking场景。
流/批/OLAP
批式计算是流式计算的特例。
而OLAP计算是一种特殊的批式计算。但对并发和实时性要求高。
因此理论上可以用一套引擎架构解决流/批/OLAP三种场景。
OLAP存在的需求和问题：
OLAP对latency和QPS要求较高，需要有高并发
作业频繁启停，资源碎片多。
Flink OLAP架构现状
问题：
1.OLAP希望作业能有高并发，但是jobmanager和resourcemanager是在一个进程内启动的，无法对jm水平拓展
2.Gateway与Flink Session Cluster互相独立，无法进行统一管理
3.jm处理和调度作业负责的功能比较多，导致耗时长、内存占用多
4.tm部署计算任务时，初始化的耗时严重
5.资源申请和资源释放流程链路过长
6.jm管理slot资源导致无法感知到TM维度的资源分布，资源管理完全依靠rm
