关于flink:Flink的运行架构

5次阅读

共计 2200 个字符,预计需要花费 6 分钟才能阅读完成。

工作提交流程

  1. Flink 提交工作,Client 向 HDFS 上传 Flink 的 Jar 包和配置
  2. 之后向 Yarn ResourceManager 提交工作
  3. ResourceManager 调配 Container 资源并告诉对应的 NodeManager 启动 ApplicationMaster,ApplicationMaster 启动后加载 Flink 的 Jar 包和配置来构建环境,而后启动 JoManager。
  4. 之后 ApplicationMaster 向 ResourceManager 申请资源启动 TaskManager
  5. ResourceManager 调配 Container 资源后,由 ApplicationMaster 告诉资源所在节点的 NodeManager 启动 TaskManager,NodeManager 加载 Jar 和配置构建环境并启动 TaskManager
  6. TaskManager 启动后向 JobManager 发送心跳包,并期待 JobManager 向其分配任务。
任务调度原理

  1. Client:提交 Job 的客户端。
  2. JobManager: 从 Client 处接到 Job 和 Jar 包后,以 Task 的单元调度到各个 TaskManager 去执行。即次要负责调度 Job 并协调 Task 做 checkpoint。
  3. TaskManager:从 JobManager 接管须要部署的 Task,与自已的上游建设 Netty 连贯。在启动是设置好槽位数 Slot,每个 Slot 能启动一个 Task 线程。

当 Flink 集群启动后,首先会启动一个 JobManager 和一或多个 TaskManager。JobManager 再调度各个 Task 到 TaskManager 执行,TaskManager 将心跳和统计信息汇报给 JobManager。

Graph


Flink 中的执行图能够分成四层:StreamGraph -> JobGraph -> ExecutionGraph -> 物理执行图

  • StreamGraph:依据用户通过 Stream API 编写的代码生成最后的图,示意程序的拓扑构造。
  • JobGraph:StreamGraph 通过优化后生成了 JobGraph,是提交给 JobManager 的数据结构。次要优化位,将多个符合条件的节点 chain 在一起作为一个节点,这样能够缩小数据在节点之间流动所须要的序列化 / 反序列化 / 传输耗费。
  • ExecutionGraph:JobManager 依据 JobGraph 生成 ExecutionGraph,ExecutionGraph 是 JobGraph 的并行化版本,是调度层最外围的数据结构。
  • 物理执行图:JobManager 依据 ExecutionGraph 对 Job 进行调度后,在各个 TaskManager 上部署 Task 后造成的“图”
Stream 和 Transformation


Flink 是由 Stream 和 Transformation 这两个根本构建块组成,其中 Stream 是一个两头后果数据,Transformation 是一个操作,,它对一个或多个输出 Stream 进行计算解决,输入一个或多个后果 Stream。


Flink 程序被执行的时候,会被映射为 Streaming Dataflow。一个 Streaming Dataflow 是由一组 Stream 和 Transformation Opearator 组成。

并行数据流


一个 Stream 能够被分成多个 Stream Partition,一个 Operator 能够被分成多个 Operator Subtask,每一个 Operator Subtask 是在不同的线程中独立执行的。一个 Operator 的并行度,等于 Operator Subtask 的个数,一个 Stream 的并行度总是等于生成它的 Operator 的并行度。

One-to-one 模式 : 比如说从 Source[1] 到 map[1],他放弃了 Source 的分区个性和分区内元素解决的有序性,也就是说 map()[1]的 Subtask 看到的数据流中记录的数据,与 Source[1]看到的记录程序是一样的。
Redistribution 模式 :这种模式扭转了输出数据流的分区,比方从 map()[1]、map()[2] 到 keyBy()/window()/apply()[1]、keyBy()/window()/apply()[2],上游的 Subtask 向上游的多个不同的 Subtask 发送数据,扭转了数据流的分区,这与理论利用所抉择的 Operator 有关系。

工作链


Fink 分布式执行环境中,会将多个 Operator Subtask 串起来组成一个 Operator Chain,实际上就是一个执行链,每个执行链会在 TaskManager 上一个独立的线程中执行。

Checkpoint 机制

  1. CheckpointCoordinator 周期性的向该数据流,所有的 source 算子发送 barrier。
  2. Source 算子接管到一个 barrier 后,便暂停解决数据,将以后的状态制作成快照,并保留到指定的长久化存储中,最初它再向 CheckpointCoordinator 报告本人的快照制作状况。同时向本身上游所有算子播送该 barrier。而后复原该算子的数据处理工作。
  3. 上游的算子接管到 barrier 后,也会暂停自的数据处理过程,同 2 过程。
  4. 最初 CheckpointCoordinator 会确认它接管到的报告,如果收到本周期的所有算子的快照就认为快照制作胜利,否则失败。
正文完
 0