flink源码阅读

Flink面试--源码篇

1、Flink Job的提交流程？

2、Flink所谓"三层图"结构是哪几个"图"？

3、JobManger在集群中扮演了什么角色？

4、JobManger在集群启动过程中起到什么作用？

5、JobManger在集群启动过程中起到什么作用？

6、JobManger在集群启动过程中起到什么作用？

7、Flink 计算资源的调度是如何实现的？

8、简述Flink的数据抽象及数据交换过程？

9、简述Flink的数据抽象及数据交换过程？

 

 

 

一、Flink Job的提交流程

 

 

• 当一个应用被提交时，Dispatcher分发器就会启动并将应用移交给一个JobManager。
• JobManager控制一个应用程序执行的主进程，每个应用程序都会被一个不同的JobManager所控制；JobManager先接收到要执行的应用程序（包括作业图JobGraph、逻辑数据流图Logical dataflow gragh、打包的所有的类、库和其他资源的jar包；JobManager会将JobGraph转换为一个物理层面的数据流图（执行图：ExecutionGragh），包含了所有可以并发执行的任务； JobManager会向资源管理器（ResourceManager）请求执行任务必要的资源，即TaskManager上的插槽（Slot），一旦获取到足够的资源，就会将执行图分发到真正运行它们的TaskManager上；在运行过程中，JobManager会负责所有需要中央协调的操作，比如检查点（checkpoints)的协调。
• ResourceManager主要负责管理任务管理器（TaskManager）的插槽（slot），Slot时Flink定义的处理资源单元；ResourceManager将有空闲插槽的TaskManager分配给JobManager。如果ResourceManager没有足够的插槽来满足JobManager的请求，它可以向资源提供平台发起会话，以提供启动TaskManager进程的容器。
• TaskManager一般在Flink的工作进程中会有多个，每个TaskManager都包含一定数量的插槽slots，插槽的数量限制了TaskManager能够执行的任务数量。
  TaskManager启动之后，TaskManager会向ResoureManger注册它的插槽，收到ResourceManger的指令后，TaskManager就会将一个或多个插槽提供个JobManager调用，JobManager就可以向插槽分配任务（tasks)来执行。
  在执行过程中，一个TaskManager可以跟其他运行同一应用程序的TaskManager交换数据。

 

 

二、Flink所谓"三层图"结构是哪几个"图"？

一个Flink任务的DAG生成计算图大致经历以下三个过程：

 

StreamGraph

 

最接近代码所表达的逻辑层面的计算拓扑结构，按照用户代码的执行顺序向StreamExecutionEnvironment添加StreamTransformation构成流式图。

JobGraph

 

从StreamGraph生成，将可以串联合并的节点进行合并，设置节点之间的边，安排资源共享slot槽位和放置相关联的节点，上传任务所需的文件，设置检查点配置等。相当于经过部分初始化和优化处理的任务图。

ExecutionGraph

 

由JobGraph转换而来，包含了任务具体执行所需的内容，是最贴近底层实现的执行图。

 

 

 

三、JobManger在集群中扮演了什么角色？

 

JobManager 负责整个 Flink 集群任务的调度以及资源的管理，从客户端中获取提交的应用，然后根据集群中 TaskManager 上 TaskSlot 的使用情况，为提交的应用分配相应的 TaskSlot 资源并命令 TaskManager 启动从客户端中获取的应用。

 

JobManager 相当于整个集群的 Master 节点，且整个集群有且只有一个活跃的 JobManager ，负责整个集群的任务管理和资源管理。

 

JobManager 和 TaskManager 之间通过 Actor System 进行通信，获取任务执行的情况并通过 Actor System 将应用的任务执行情况发送给客户端。

 

同时在任务执行的过程中，Flink JobManager 会触发 Checkpoint 操作，每个 TaskManager 节点 收到 Checkpoint 触发指令后，完成 Checkpoint 操作，所有的 Checkpoint 协调过程都是在 Fink JobManager 中完成。

 

当任务完成后，Flink 会将任务执行的信息反馈给客户端，并且释放掉 TaskManager 中的资源以供下一次提交任务使用。

 

 

四、JobManger在集群启动过程中起到什么作用？

 

JobManager的职责主要是接收Flink作业，调度Task，收集作业状态和管理TaskManager。它包含一个Actor，并且做如下操作：

 

RegisterTaskManager: 它由想要注册到JobManager的TaskManager发送。注册成功会通过AcknowledgeRegistration消息进行Ack。

SubmitJob: 由提交作业到系统的Client发送。提交的信息是JobGraph形式的作业描述信息。

CancelJob: 请求取消指定id的作业。成功会返回CancellationSuccess，否则返回CancellationFailure。

UpdateTaskExecutionState: 由TaskManager发送，用来更新执行节点(ExecutionVertex)的状态。成功则返回true，否则返回false。

RequestNextInputSplit: TaskManager上的Task请求下一个输入split，成功则返回NextInputSplit，否则返回null。

JobStatusChanged： 它意味着作业的状态(RUNNING, CANCELING, FINISHED,等)发生变化。这个消息由ExecutionGraph发送。

 

 

 

五、TaskManager在集群中扮演了什么角色？

 

TaskManager 相当于整个集群的 Slave 节点，负责具体的任务执行和对应任务在每个节点上的资源申请和管理。

 

客户端通过将编写好的 Flink 应用编译打包，提交到 JobManager，然后 JobManager 会根据已注册在 JobManager 中 TaskManager 的资源情况，将任务分配给有资源的 TaskManager节点，然后启动并运行任务。

 

TaskManager 从 JobManager 接收需要部署的任务，然后使用 Slot 资源启动 Task，建立数据接入的网络连接，接收数据并开始数据处理。同时 TaskManager 之间的数据交互都是通过数据流的方式进行的。

 

可以看出，Flink 的任务运行其实是采用多线程的方式，这和 MapReduce 多 JVM 进行的方式有很大的区别，Flink 能够极大提高 CPU 使用效率，在多个任务和 Task 之间通过 TaskSlot 方式共享系统资源，每个 TaskManager 中通过管理多个 TaskSlot 资源池进行对资源进行有效管理。

 

六、TaskManager在集群启动过程中起到什么作用？

 

TaskManager的启动流程较为简单：启动类：org.apache.flink.runtime.taskmanager.TaskManager核心启动方法 ： selectNetworkInterfaceAndRunTaskManager启动后直接向JobManager注册自己，注册完成后，进行部分模块的初始化。

 

 

七、Flink 计算资源的调度是如何实现的？

 

TaskManager中最细粒度的资源是Task slot，代表了一个固定大小的资源子集，每个TaskManager会将其所占有的资源平分给它的slot。

 

通过调整 task slot 的数量，用户可以定义task之间是如何相互隔离的。每个 TaskManager 有一个slot，也就意味着每个task运行在独立的 JVM 中。每个 TaskManager 有多个slot的话，也就是说多个task运行在同一个JVM中。

 

而在同一个JVM进程中的task，可以共享TCP连接（基于多路复用）和心跳消息，可以减少数据的网络传输，也能共享一些数据结构，一定程度上减少了每个task的消耗。每个slot可以接受单个task，也可以接受多个连续task组成的pipeline，如下图所示，FlatMap函数占用一个taskslot，而key Agg函数和sink函数共用一个taskslot：

 

 

 

 

 

八、简述Flink的数据抽象及数据交换过程？

 

Flink 为了避免JVM的固有缺陷例如java对象存储密度低，FGC影响吞吐和响应等，实现了自主管理内存。MemorySegment就是Flink的内存抽象。默认情况下，一个MemorySegment可以被看做是一个32kb大的内存块的抽象。这块内存既可以是JVM里的一个byte[]，也可以是堆外内存（DirectByteBuffer）。

 

在MemorySegment这个抽象之上，Flink在数据从operator内的数据对象在向TaskManager上转移，预备被发给下个节点的过程中，使用的抽象或者说内存对象是Buffer。

 

对接从Java对象转为Buffer的中间对象是另一个抽象StreamRecord。

 

九、Flink 中的分布式快照机制是如何实现的？

 

Flink的容错机制的核心部分是制作分布式数据流和操作算子状态的一致性快照。 这些快照充当一致性checkpoint，系统可以在发生故障时回滚。 Flink用于制作这些快照的机制在“分布式数据流的轻量级异步快照”中进行了描述。 它受到分布式快照的标准Chandy-Lamport算法的启发，专门针对Flink的执行模型而定制。

 

 

 

barriers在数据流源处被注入并行数据流中。快照n的barriers被插入的位置（我们称之为Sn）是快照所包含的数据在数据源中最大位置。例如，在Apache Kafka中，此位置将是分区中最后一条记录的偏移量。 将该位置Sn报告给checkpoint协调器（Flink的JobManager）。

 

然后barriers向下游流动。当一个中间操作算子从其所有输入流中收到快照n的barriers时，它会为快照n发出barriers进入其所有输出流中。 一旦sink操作算子（流式DAG的末端）从其所有输入流接收到barriers n，它就向checkpoint协调器确认快照n完成。在所有sink确认快照后，意味快照着已完成。

 

一旦完成快照n，job将永远不再向数据源请求Sn之前的记录，因为此时这些记录（及其后续记录）将已经通过整个数据流拓扑，也即是已经被处理结束。

 

 

十、简单说说FlinkSQL的是如何实现的？

 

Flink 将 SQL 校验、SQL 解析以及 SQL 优化交给了Apache Calcite。Calcite 在其他很多开源项目里也都应用到了，譬如 Apache Hive, Apache Drill, Apache Kylin, Cascading。Calcite 在新的架构中处于核心的地位，如下图所示。

 

 

 

构建抽象语法树的事情交给了 Calcite 去做。SQL query 会经过 Calcite 解析器转变成 SQL 节点树，通过验证后构建成 Calcite 的抽象语法树（也就是图中的 Logical Plan）。另一边，Table API 上的调用会构建成 Table API 的抽象语法树，并通过 Calcite 提供的 RelBuilder 转变成 Calcite 的抽象语法树。然后依次被转换成逻辑执行计划和物理执行计划。

 

在提交任务后会分发到各个 TaskManager 中运行，在运行时会使用 Janino 编译器编译代码后运行。