这是我参与「第四届青训营 」笔记创作活动的的第2天

flink的架构

实时需求场景： 监控场景 规则风控 实时推荐

常用的有API有sqlAPI和DataStreamAPI

jobmaster和jobmanager的概念（JobManager是一个更大的概念，从图看应该是包含关系,包含JobMaster,RM,Dispacher，就是client把任务提交到一整个应用程序上就是JobManager） job manager job maager 是flink 集群中任务管理和调度的核心,控制应用执行的主进程,每个应用都应该被唯一的Job manager 所控制执行,ha 环境下可能会有多个,但是只有一个为leader,其中 job manager 有三个组件

job master JobMaster 是 JobManager 中最核心的组件，负责处理单独的作业（Job）。所以 JobMaster和具体的 Job 是一一对应的,多个 Job 可以同时运行在一个 Flink 集群中, 每个 Job 都有一个自己的 JobMaster。需要注意在早期版本的 Flink 中，没有 JobMaster 的概念；而 JobManager的概念范围较小，实际指的就是现在所说的 JobMaster。JobMaster 会先接收到要执行的应用。这里所说“应用”一般是客户端提交来的，包括：：Jar 包，数据流图（dataflow graph），和作业图（JobGraph）。 JobMaster 会把 JobGraph 转换成一个物理层面的数据流图，这个图被叫作“执行图”（ExecutionGraph），它包含了所有可以并发执行的任务。 JobMaster 会向资源管理器（ResourceManager）发出请求，申请执行任务必要的资源。一旦它获取到了足够的资源，就会 将执行图分发到真正运行它们的 TaskManager 上。 而在运行过程中，JobMaster 会负责所有需要中央协调的操作，比如说检查点（checkpoints）的协调。

资源管理器（ResourceManager） ResourceManager 主要负责资源的分配和管理，在 Flink 集群中只有一个。所谓“资源”，主要是指 TaskManager 的任务槽（task slots）。任务槽就是 Flink 集群中的资源调配单元，包含了机器用来执行计算的一组 CPU 和内存资源。每一个任务（Task）都需要分配到一个 slot 上执行。 Flink 的 ResourceManager，针对不同的环境和资源管理平台（比如 Standalone 部署，或者YARN），有不同的具体实现。在 Standalone 部署时，因为 TaskManager 是单独启动的（没有Per-Job 模式），所以 ResourceManager 只能分发可用 TaskManager 的任务槽，不能单独启动新TaskManager 与yarn 的 TaskManager是有明显的区分的有资源管理平台时，就不受此限制。当新的作业申请资源时，ResourceManager 会将 有空闲槽位的 TaskManager 分配给 JobMaster。如果 ResourceManager 没有足够的任务槽，它还可以向资源提供平台发起会话，请求提供启动 TaskManager 进程的容器。另外，ResourceManager 还负责停掉空闲的 TaskManager，释放计算资源。

分发器（Dispatcher） Dispatcher 主要负责提供一个 REST 接口，用来提交应用，并且负责为每一个新提交的作业启动一个新的 JobMaster 组件。Dispatcher 也会启动一个 Web UI，用来方便地展示和监控作业执行的信息。Dispatcher 在架构中并不是必需的，在不同的部署模式下可能会被忽略掉。

TaskManager TaskManager 是 Flink 中的工作进程，数据流的具体计算就是它来做的，所以也被称为“Worker”。Flink 集群中必须至少有一个 TaskManager；当然由于分布式计算的考虑，通常会有多个 TaskManager 运行，每一个 TaskManager 都包含了一定数量的任务槽（task slots）。Slot是资源调度的最小单位，slot 的数量限制了 TaskManager 能够并行处理的任务数量 启动之后，TaskManager 会向资源管理器注册它的 slots；收到资源管理器的指令后，TaskManager 就会将一个或者多个槽位提供给 JobMaster 调用，JobMaster 就可以分配任务来执行了。 在执行过程中，TaskManager 可以缓冲数据，还可以跟其他运行同一应用的 TaskManager 交换数据。

flink的算子链抽象：

Flink 中的执行图可以分成四层：StreamGraph -> JobGraph -> ExecutionGraph -> 物理执 行图。 StreamGraph（流图，客户端client生成）：是根据用户通过 Stream API 编写的代码生成的最初的图。用来表示程序 的拓扑结构。要选择分分区器。 操作：名词改变，出现中间结果集，算子链优化 JobGraph(作业图，客户端client生成) ：StreamGraph 经过优化后生成了 JobGraph，提交给 JobManager 的数据结构。 主要的优化为，将多个符合条件的节点 chain 在一起作为一个节点（代码中的体现为把流节点的出边分为可以串的和不可以串的，可以串的，可以穿的就生成operatorchain），在我们的项目中可以注意一下，这样可以减少数据在节优化后一个JobVertex(作业顶点)可以包含多个算子，边是数据传输通道，把中间结果数据集传到下一个算子 点之间流动所需要的序列化/反序列化/传输消耗。 操作：名词改变，并行化处理，中间结果集变成中间结果分区 最核心的是逻辑执行图（逻辑执行图，JobManager生成） ExecutionGraph：JobManager 根据 JobGraph 生成 ExecutionGraph。ExecutionGraph 是JobGraph 的并行化版本，是调度层最核心的数据结构。

物 理 执 行 图 ： JobManager 根 据 ExecutionGraph 对 Job 进 行 调 度 后 ， 在 各 个 TaskManager 上部署 Task 后形成的“图”，并不是一个具体的数据结构。

边相当于网络传输

flink的流批一体实现

为什么要流批一体：lambda架构两套api逻辑繁琐重复计算消耗资源多。

批是有界数据流

流批是不同的shuffleservice

语言处理：sql和datastreamAPI都可以用来处理流批

调度层：由算子变成物理执行图的过程，调度层支持不同的调度模式（lazy（先调度上游再调度下游，类似spark），eager（同时调度所有的task），）应对流批这两个不同的场景，新的pipelineregion调度模式可以同时处理批流场景。 批处理的pipelinerigion会进行切分和落盘，流处理则是一整个pipelineregion。

shufflerservice: flink内置的shuffleservice可以满足下面提到的流批shuffle方式： 常见的shuffle：基于文件的shuffle（eg：spark），pipelineshuffle基于内存(egf:link) 流作业和task是绑定的，task没了shuffle没了。 但是批作业是解耦的，shuffle结果可以存在文件里，task挂了可以接着拉起。

flink的OLAP场景

流批olap场景： OLAP场景对于实时要求没实时场景那么高，但要求满足高并发的查询。OLAP是特殊的批式计算，但对于实时性和并发性要求更高。

flink做olap的优势：引擎统一，内存计算（本身的性质），生态丰富（可以对接很多别的大数据框架）。

flink在olap的挑战：小作业频繁启停，资源开销大。查询的并发调度和执行能力优化。

flink的olap架构现状:Gateway解析sql提交到JobManager。flink的作业模式perjob和sessionclass。

flink的olap架构设想：JM扩展性，GateWay与flink统一管理。JM和TM(初始化耗时长)减少资源消耗。