flink（六）：框架和原理

说明

• 本博客每周五更新一次，上周五有事，推迟到今天更新。
• 本博文主要分享flink的系统架构和执行原理，介绍flink的角色分工和任务执行的具体步骤和过程。

角色分工

• 主要分为：client、管理节点、工作节点
  

flink on yarn执行流程

• flink提交任务到yarn
  

DataFlow执行过程

独立Operator

1. DataFlow:flink程序在执行的时候回被映射成一个数据流模型
2. Operator：数据流模型中的每一个操作被称为Operator，Operator分为：Source/Transform/Sink
3. Partition:数据流模型是分布式和并行的，执行中会形成1~n个分区
4. Subtask：多个分区任务可以并行，每个都是独立运行在一个线程中，也就是一个Subtask子任务。
5. Parallelism：并行度，就是可以同时真正执行的子任务数/分区数
   

Operator合并OperatorChain

• 客户端在提交任务的时候，会对Operator进行优化操作，能进行合并的Operator会被合并为一个Operator，合并后的Operator称为OperatorChain，即一个执行链。
• 每个执行链会在TaskManager上独立的线程上运行
  

Operator算子间传递模式

One TO One模式

• 两个Operator用此模式传递的时候，会保持数据的分区数和数据的排序，如上图中Source1到Map1，它就是保留Source的分区特性，以及分区元素处理的有序性。

Redistributing模式

• 这种模式会改变数据的分区数，每一个Subtask会根据Transformation把数据发送到不同的目标Subtasks，比如keyBy()会通过hashcode重新分区，broadcast()和rebalance()方法会随机重新分区

执行原理

• flink执行分为四步：StreamGraph、GobGraph、ExecutionGraph、物理执行图
  

StreamGraph

• 最初程序执行逻辑图，即算子间执行顺序，client上生成。
• 流程化

JobGraph

• 将OneToOne的Operator合并为OperatorChain，Client上生成
• 流程优化合并

ExecutionGrap

• 将jobGraph根据代码中设置的并行度和请求的资源进行并行化规划，JobManager上生成。
• 并行化

物理执行图

• 经ExecutionGraph的并行执行，落实到具体的TaskManager上，将具体的SubTask落实到具体的TaskSlot内进行运行。
• 落实执行线程化
• TaskManager相当于进程，TaskSlot相当于线程。

总结

• 个人认为大型程序的设计理念坚持模块化为中心，分许需求确认功能，再将功能定义为不同模块，独立设计并实现各个模块的功能，最终连接各个模块形成整体，所谓大道至简。
• 这种方式设计的软件，结构清晰且易于调整优化，单个模块功能异常，不会引发整个系统雪崩，利于调试和维护，值得借鉴和学习，设计软件时，功能拆分模块化，功能尽量只有连接，没有交集。