flink-处理流程和执行图_flink数据的处理流程

1）所有的Flink程序都是由三部分组成的：Source、Transformation和Sink。

2）Source负责读取数据源，Transformation利用各种算子进行处理加工，Sink负责输出。

3）在运行时，Flink上运行的程序会被映射成“逻辑数据流” (dataflows),它包 含了这三部分。

4）每一个dataflow以一个或多个sources开始以一个或多个sinks结束。dataflow类 似于任意的有向无环图(DAG)。

1）Flink中的执行图可以分成四层：StreamGraph -> JobGraph -> ExecutionGraph->物理执行图。

（1）StreamGraph: 是根据用户通过StreamAPI编写的代码生成的最初的图。用来表示程序的拓扑结构。

（2）JobGraph: StreamGraph经过优化后生成了JobGraph,提交给 JobManager 的数据结构。主要的优化为，将多个符合条件的节点chain(束缚)在一起作为一个节点

（3）ExecutionGraph: JobManager根据JobGraph生成ExecutionGrapho，ExecutionGraph是JobGraph的并行化版本，是调度层最核心的数据结构。

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

2）这里的前后的算子如何合并一个整体条件是相同并行度和one to one 模式，会具体讲解。

1）Stream在算子之间传输数据的形式可以是2种：

（1）One-to-one(forwarding)类似于 spark 中的窄依赖。

（2）redistributing 的模式，类似于 spark 中的宽依赖。

具体是哪一种形式，取决于算子的种类。

2）One-to-one(forwarding)：stream(比如在 source 和 map operator 之间)维护着分区以及元素的顺序。那意味着 map 算子的子任务看到的元素的个数以及顺序跟 source 算子的子任务生产的元素的个数、顺序相同， map、fliter、flatMap 等算子都是 one-to-one 的对应关系。

3）Redistributing：stream(map()跟 keyBy/window 之间或者 keyBy/window 跟 sink之间)的分区会发生改变。 每一个算子的子任务依据所选择的 transformation 发送数据到不同的目标任务。例如，keyBy()基于 hashCode 重分区、broadcast 和 rebalance会随机重新分区，这些算子都会引起 redistribute 过程，而 redistribute 过程就类似于Spark 中的 shuffle 过程 。

1）OperatorChain(算子链(或叫组合算子)，注意它是子链，OperatorChains 表示母链);

2）合并前后算子有2个条件就是: 相同并行度和one to one 模式。

3）OperatorChain算子链就相当于spark的Stage的阶段。

4）Flink 这样相连的算子链接在一起形成一个 task，原来的算子成为里面的一部分。将算子链接成 task 是非常有效的优化：它能减少线程之间的切换和基于缓存区的数据交换，在减少时延的同时提升吞吐量。链接的行为可以在编程 API 中进行指定。

1）前言：这里我们演示的是是一台节点的flink，这里使用的solt是一个，即默认的。打好的jar包上传目的是查看执行图。而不是运行，所以不要远行，远行可能不成功。

1）如果不填的话 ，直接显示 ，那么就是默认使用配置文件的并行都为1。

2）修改成2 在显示

可以看到 关闭了 就不存在前后的算子合并 每一个算子 都是默认一个。