Flink 数据传输及反压详解

 

 

 

IntermediateDataset

IntermediateDataset 是在 JobGraph 中对中间结果的抽象。我们知道，JobGraph 是对 StreamGraph 进一步进行优化后得到的逻辑图，它尽量把可以 chain 到一起 operator 合并为一个 JobVertex，而 IntermediateDataset 就表示一个 JobVertex 的输出结果。JobVertex 的输入是 JobEdge，而 JobEdge 可以看作是 IntermediateDataset 的消费者。一个 JobVertex 也可能产生多个 IntermediateDataset。需要说明的一点是，目前一个 IntermediateDataset 实际上只会有一个 JobEdge 作为消费者，也就是说，一个 JobVertex 的下游有多少 JobVertex 需要依赖当前节点的数据，那么当前节点就有对应数量的 IntermediateDataset。

19-幻灯片26-1568x882.png

 

这时候还没有向集群去提交任务，在 Client 端会将 StreamGraph 生成 JobGraph，JobGraph 就是做为向集群提交的最基本的单元。在生成 JobGrap 的时候会做一些优化，将一些没有 Shuffle 机制的节点进行合并。有了 JobGraph 后就会向集群进行提交，进入运行阶段。

Jobvertex->Intermedia Dateset->JobEage

20-幻灯片27-1-1568x882.png

 

然后我们概念化这样一张物理执行图，可以看到每个 Task 在接收数据时都会通过这样一个InputGate 可以认为是负责接收数据的，再往前有这样一个 ResultPartition 负责发送数据，在 ResultPartition 又会去做分区跟下游的 Task 保持一致，就形成了 ResultSubPartition 和 InputChannel 的对应关系。这就是从逻辑层上来看的网络传输的通道，基于这么一个概念我们可以将反压的问题进行拆解。
ExecutionGraph -> Intermedia ATA
task ->ResultPartion->InputGate
ResultSubParition-->InputChannel 一一对应

问题拆解：反压传播两个阶段

image.png

假设最下游的 Task （Sink）出现了问题，处理速度降了下来这时候是如何将这个压力反向传播回去呢？这时候就分为两种情况：

跨 TaskManager ，反压如何从 InputGate 传播到 ResultPartition

TaskManager 内，反压如何从 ResultPartition 传播到 InputGate

TaskManager 只有一个 Network BufferPool 被所有的 Task 共享,初始化时会从 Off-heap Memory 中申请内存，申请后内存管理通过 Network BufferPool 来进行，不需要依赖 JVM GC 的机制去释放。有了 Network BufferPool 之后可以为每一个 ResultSubPartition 创建 Local BufferPool

反压过程：

1. 首先InputChannel 的 Buffer 被用尽于
2. 会向 Local BufferPool 申请新的 Buffer
3. 如果 Local BufferPool没有可用的,或是 Local BufferPool 的最大可用 Buffer 到了上限 无法向 Network BufferPool 申请，没有办法去读取新的数据
4. 这时 Netty AutoRead