这是我参与「第四届青训营 -大数据场」笔记创作活动的的第2篇笔记
我们主要学习以下几个内容
- Flink的架构
- Flink引擎的调度流程
- 动态表与数据流
Flink是什么？
Flink他是一个流式数据实时计算的大数据处理框架，批处理也可以作为特殊的流处理计算
下图是一些支持的能力
Flink的分层架构
- 最上面SDK层，这是flink支持的SDK，可以用sql/table、用java的DataStream、python来编写业务逻辑
- 执行引擎层(Runtime层)，是把代码业务逻辑转化成DAG，然后转化成task去执行。task之间可以通过shuffle service进行数据交换
- 状态存储层(state Backend)：把算子的状态存下来
- 资源调度层：支持Yarn、k8s多种调度
Flink调度流程是什么样的？
这个部分就是讲flink分层架构中的Runtime层是怎么工作的
最重要的两个核心跟spark没啥区别，JobManager(JM)和TaskManager(TM)。
整个流程是这样的：
- 首先client端先把代码的业务逻辑转化成一个DAG，然后发送到JM
- 然后JM把这个DAG转化成一个真正能运行的物理计划，然后把task调度到TM的slot里去
具体说说代码逻辑是怎么转化成一个DAG的
就类似spark一样，把算子的前后逻辑作为一张DAG。下图中source是数据源，然后经过一些算子，最后sink是输出
如果两个算子之间不存在shuffle这类操作，并行数相同的时候就可以作为一个operator chain，在一个线程里跑。有点像spark里窄依赖可以作为同一个stage
然后JM把task塞到TM的Slot里面去
可以理解成每个slot是一个线程，可以把task放到这个slot上。一个TM上的几个slot之间的资源没有做太多隔离，比如cpu没隔离，heap内存没隔离等
总结：
整个调度流程就是这样，client把代码转化成DAG发给JM，JM把DAG转换成执行计划，根据计划把Task发到TM里去执行。
动态表与数据流
很多时候，我们都是用sql来跑flink。那么sql是怎么在数据流上执行的呢，这就是我们要学习的内容。
首先要做一个整体把握，数据流先要变成动态表，然后对动态表做持续查询，最后把动态表转回数据流
数据流→动态表
举个例子，比如我们用下面这条sql去查每个用户的点击数，首先会把数据流转化成动态表，然后数据不断进来就会对动态表产生一个持续查询
什么叫持续查询，就是在原来的动态表不变，更新数据产生一个新的动态表，数据不断的进来就要不断更新产生动态表，就比如下图的右边因为数据不断进来，不断更新动态表产生了4张动态表
动态表→数据流
首先要引入一个Retract消息概念
什么是Retract，比如下图，第一个Mary进来insert 1，第二个Mary进来就要update前面Mary点击为1的记录，这种时候就要用到Retract消息，先把之前Mary+1的记录给回撤，也就是先-1，再直接insert 2，这种先回撤原来的记录的操作就叫Retract消息
那么我当时有一个疑问，为啥不直接+1呢，还要先-1再+2，这不多此一举吗？有一个原因是下游如果是个set，比如hashmap就不能直接覆盖数据，所以得先回撤再添加一条新的记录
动态表转化到数据流，有可能包含三种操作，insert、update、delete，也就出现了三种转化模式：append-only流、Retract流、update流
- append-only流：就是只插入数据不更新
- Retract流：就是删除原来的记录，直接retract
- update流：要先retract，然后再insert更新记录，也就是上面的-1+2的例子
