Flink中的一些概念区分

1.各个执行Graph
2.JobManager和JobMaster
3.Task？Slot？StreamTask？
4.Checkpoint？
5.BarrierBuffer和BarrierTracker?

1.图生成

StreamGraph
​
JobGraph:
StreamingJobGraphGenerator.createJobGraph()
-jobvertex
-
JobGraph的提交依赖于JobClient和JobManager之间的异步通信
JobManager的actor接收到来自client端的请求后，会执行一个submitJob方法:
-构建ExecutionGraph对象
​
​
ExectionGraph
IntermediateResult

StreamTask
​

2.Job
JobManager：
负责：
- receiving Flink jobs
- scheduling the tasks
- gathering the job status
- managing the task managers — InstanceManager通过instancemanager管理taskmanager（instance 代表 taskmanager）
作为actor接收如下消息：
- RegisterTaskManager
​
JobMaster：

3. Task
   TaskManager
   ​
   Slot。 树形结构
   ShardSlot
   ShardSlot
   SimpleSlot
   SimpleSlot
   SimpleSlot
   一个task的多个subtask一定会被分配在不同的slot中。
   ​
   ​
   //(Task是一个Taskmanager部署并执行的一个本地执行单元)
   Task:
   A task is the unit of local processing that is deployed and executed by the TaskManagers
   Each task runs one or more {@link StreamOperator}s which form the Task’s operator chain.
   ​
   //StreamTask是执行链的头
   //Task对象在执行过程中，把执行的任务交给了StreamTask这个类去执行—???那么这个对象是如何执行用户的代码的呢？
   //参考：OneInputStreamTask的Run方法。inputProcessor.processInput()
   //all the work happens in the “processInput” method
   //在processInput里面
   //streamOperator.processElement(record);
   StreamTask 继承 AbstractInvokable
   The task chain contains one “head” operator and multiple chained operators.
   The StreamTask is specialized for the type of the head operator: one-input and two-input tasks,
   as well as for sources, iteration heads and iteration tails.
   ​
   Task和StreamTask的区别和关系：
   Task对象本身就是一个Runable。
   在Task里面执行invokable.invoke(); 【StreamTask实现 invokable】————这个方法就是用户代码所真正被执行的入口
   比如我们写的什么new MapFunction()的逻辑，最终就是在这里被执行的。
   这里说一下这个invokable，这是一个抽象类，提供了可以被TaskManager执行的对象的基本抽象。
   ​
   ​
   ResultPartiton
   ​
   InputGate

2.checkpont
//生命周期
1.触发
2.状态保存 和barrier传递
​
// 谁发出(触发的)的？
​
关键类：
CheckpointCoordinator
提交这个job时候，启动CC的startCheckpointScheduler
----> PendingCheckpoint ----> CompletedCheckpoint
​
for (Execution execution: executions) {
execution.triggerCheckpoint(checkpointID, timestamp, checkpointOptions);
}

// 怎么真正做的？
​
Task层面checkpoint的准备工作
–创建了一个CheckpointMetaData的对象，并且生成了一个Runable匿名类用于执行checkpoint，然后以异步的方式触发了该Runable：
– Task类实际上是将checkpoint委托给了更具体的类去执行
– 而StreamTask也将委托给更具体的类，直到业务代码。

StreamTask是这样实现的：
task还在运行，那就可以进行checkpoint
– 先向下游所有出口广播一个Barrier，
– 然后触发本task的State保存。
详见：StreamTask的performCheckpoint
– StreamTask的executeCheckpointing
– checkpointStreamOperator(op);
​
​
// 怎么传递的？
1.先向下游所有出口广播一个Barrier1，
2.然后触发本task的State保存。
3.下游的operator接收到本barrier1，就会触发其自身的checkpoint。
// 完成标志？
​
// 锁？同步阶段？
是锁单个操作还是完整的操作？
​
​
举例：kafka的checkpont
我们当前的wordcount程序里有两个operator chain，分别是：
​
kafka source -> flatmap
keyed aggregation -> sink
1.kafka source的checkpoint过程
– 记录一下当前消费的offsets。然后做成tuple（partitiion，offset）。放进一个StateBackend里
2.FlatMap算子的checkpoint过程
没什么可说的，就是调用了snapshotState()方法而已。
3.本operator chain的state保存过程
各个算子的snapshot方法只把自己的状态保存到了StateBackend里，没有写入的持久化操作
//这部分操作被放到了AbstractStreamOperator中，由flink统一负责持久化.持久化无非就是把这些数据用一个流写到磁盘或者别的地方
​
​
​
//五、state怎么持久化？
1.把各个算子的state做了一份深拷贝；
2.以异步的方式执行了一个内部类的runnable，该内部类的run方法实现了一个模版方法，
首先打开stream，然后写入数据，然后再关闭stream。

3.数据传输

CheckpointBarrierHandler
​
实现：
BarrierBuffer 实现仅一次语义
BarrierTracker 至少一次，，可以多次
​
​
Barrier是在什么时候发出来的。
Barrier是怎么广播出来的？
Barrier是怎么生效的？