Flink运行时架构

一、运行时组件
JobManager：控制应用程序运行的主进程Master，将jobGraph转换成可执行的数据流图（Execution Graph），包含可并发的task；
向ResourceManager申请资源(slot)，将executionGraph分发到TaskManager上。
同时作为中央协调器，如checkpoints操作。
应用程序：作业图JobGraph、逻辑数据流图（logical dataflow graph）、打包的类库及其他jar包；

TaskManager：工作进程，包含一定数量slot，slot限制了taskManager可并行执行的任务数量；向jobmanager申请并关联slot；

Dispatcher：分发job的，一个Rest接口（跨平台）。

二、job运行过程

jobManager是需求方，做工作设计图，分解作业图；
ResourceManager是作业方，根据需要提供资源slot，提供taskManager(工人)，根据需要将slot与taskManager关联，一个工人同时干多少活。
taskManager根据作业图执行任务。

精细版：
JobManager本身启动也需要资源，需要先向RM申请资源启动。
Dispatcher被RM给包含了，job直接提交到RM上，申请启动JM。
JM启动，设计作业图，分解任务图，向RM申请slot和TM，
RM根据申请，启动slog和TM，
JM将task分发给TM运行，TM任务运行失败、取消、重启，都由JM决定。

怎样实现并行计算？
一个job的同一代码，通过多个task执行。
一个流处理程序，任务是怎么划分的？

推荐最大slot个数为cpu cores个数。
TaskManager有独立的JVM进程，在上面运行多个子任务，子任务通过slot进行控制。
job：TM = 1：n
TM：JVM = 1:1
TM ： slot = 1：m
job：slot = 1： n*m

可将slot分组，代码里将不同的代码运行在指定的slot分组内
.sum(1).slotSharingGroup(“red”) 要求sum运行在“red”分组内。
这将引起slot共享程度降低。

以下图为例：
A有四个parallelism，C为2，B为4，D为4，E为2并行度。在不分组的情况下
那么仅需要4个slot可完成任务。

推荐conf.yaml内的slot设置为cpu cores。以下图为例，cpu为3，整个集群slot为9；
在这种情况下，如果代码里面设置的并行度过低，将引起资源浪费。
因此建议提高并行度。
对于特定代码，比如数据写入文件，再讲并行度设置为1.

flink划分task分spark类型，同样有划分job，stage的过程，只是叫法不一样；
一个job总体分为source(读数据)，transformation，sink（触发job）
transformation内也有类似spark shuffle dependency的划分，用于决定一个task可以执行一个pipeline的语句。

flink共分为四层图：StreamGraph、JobGraph、ExecutionGraph、物理执行图