Apache Flink 中Application 与 Job

• 一个完整的Flink Application 一般组成如下：
  • Source 数据来源
  • Transformation 数据转换处理等
  • Sink 数据传输
• Flink 中一个或者多个Operator（算子）组合对数据进行转换形成一个 Transformation，一个FlinkApplication开始于一个或者多个Source，结束于一个或者多个Sink

DataFlow数据流图

• 一个Flink Job执行时候会按照Source，Transformation，Sink顺序执行，形成了一个Stream DataFlow（数据流图），数据流图是个整体展示Flink作业执行流程的高级试图。

SubTask子任务与并行度

• 集群中运行Flink代码本质上就是以为并行度方式来执行，这样可以提高处理数据的吞吐量和速度。
• 当一个Flink中有多个Operator，每个Operator有多个Subtask（子任务），不同的Operator的Subtask个数可以不一样，一个Operator有几个SubTask就代当前算子的并行度（Parallelism）是多少，Subtask在不同现场，不同物理机器或者不同容器中完全独立执行。

• 以上图是DataFlow视图，下半部分是并行度DataFlow视图，Source，Map，keyBy等操作都是 2个并行度，对应有2个subtask分布式执行，Sink操作并行度1，只有一个subtask，一共是7个subTask，
• 一个Flink Application 的并行度通常任务是所有Operator中最大的并行执行能力，以上最大2个并行度
• 并行度设置有三种方法：
  • Operator Level（算子层面）：编码的方式xxx.setparallelism(2)。当前算子有效
  • Eecution Environment Level（执行环境层面）：env.setparallelism() 全局代码有效
  • Client Level（客户端层面）：在Web UI上之间配置
  • System Level（系统层面）：通过yaml文件配置：parallenlism.default ：5

Operator Chains 算子链

• Flink作业中，可以指定Operator Chains（算子链）将相关性非常强的算子操作绑定在一起，这样能够让转换过程上下游的Task数据处理逻辑由一个Task执行，避免因为数据在网络或者线程之间传输导致的开销，减少数据处理延迟提高数据吞吐量。
• 如下案例，下图流程处理程序Source/map 就形成了一个算子链，keyBy/window/apply新城了算子链，分布式执行中原本需要多个task执行的操作由于存在算子链，我们可以用一SubTask分不少执行即可。

• Flink中哪些操作可以合并一起？这主要取决于算子之间的并行度与算子数据之间传递的模式。

• 一个数据流在算子之间传递数据可以是一对一（One-to-One）的模式传递

• 也可以是重新分区（Redistributing）的模式传递，两个有区别

  • One-to-one：一对一模式例如上图中source 和Map()算子之间，保留了原宿的分区和顺序，这样处理流程是map()算子的subTask[1]处理的数据全部都是来自source的task[1] 产生的数据，并且顺序保持一致，例如 map。fllter，flatMap这些算子操作都是One-to-One数据传递模式
  • Redistributing：重新分区模式（如上面的mao 和keyBy/window之间，以及keyBy/window和Sink之间），改变了流的分区，这种情况下数据流向的分区变化了。每个算子的subtask将数据发送到不同的目标subtask，这取决于使用了什么样的算子操作，例如keyBy()是分组操作，会根据key的hash值重新分区投递，再比如，window/apply 算子操作的并行度是2，流向了并行度1的sink操作，这个过程需要通过rebalance操作将数据均匀发送到下游Subtsk中，这些都是重新分区了。

• Flink 中 One-to-One的算子操作并行度一致，默认自动合并在一起形成一个算子链，

Fllink 执行图

• Flink 代码提交到集群执行，最终转成task分不少的在各个节点上运行，以下我们用DataFlow的形式展示Flink中Task提交执行流程。

• 客户端会按照transformation转成StreamGraph(任务流图)
• StreamGraph按照Operator Chains 算子链和规则转换成JobGraph（作业图）在JobGraph中将并行度相同且数据流转关系位One-to-One关系的算子合并在一个task处理原来需要两个task处理的逻辑，
• JobGraph会被提交给jobManager，最终由jobManager中的JobMaster转换成ExecutionGraph）（执行图）
• ExecutionGraph中按照每个算子并行度来划分对应的SubTask，每个SubTask最终再次被转换成其他可以部署的对象发送到TaskManager上执行。
• 以上整个流程是Flink任务的底层执行转换流程，基于以上流程有如下结论：
  • 在Flink中一个Task一般对应的就是一个算子或者多个算子逻辑，多个算子逻辑经过Operator Chains优化后也是由一个Task执行
  • Flink分不少运行中，Task会按照并行度划分成多个SubTask。每个SubTask由一个Thread新城执行，多个SubTask分布在不同现场不同节点形成Fllink分布式的执行。
  • SubTask是Flink任务调度的基本单元

TaskSlot任务槽

• 提交到集群中的Flink程序最终都会换成一个一个的SubTask，SubTask是Flink任务调度的基本单元，这些task最终发送到不同taskmanager节点上分布式执行

TaskSlot任务槽

• Flink集群中每一个TaskManager是一个JVM进程，可以在TaskManager中执行一个或者多个Subtask，为了控制Taskmanager中接受的Task数量，TaskManager节点上可以提供TaskSlot（任务槽），一个TaskManger上可以划分多个TaskSlot，TaskSlot是Flink系统中资源调度的最小单元，可以对TaskManager上资源进行划分，每个taskSlot可以运行一个或者多个subtask，每个jobManager上至少有一个taskSlot。

• 以上，每个taskSlot都有固定资源，假设一个TaskManager有三个TaskSlots，那么每个TaskSlot将会平均分TaskManger的内存，那么subtask不会与其他subtask竞争内存，taskslot作用就是分离任务的托管内存，但是不会发生CPU的隔离

• 通过调整taskSlot数量，用户可以指定每一个taskManager油多少taskSlot，

  • 可以单个，这样就独占当前JobManager的JVM
  • 多个taskSlot就有多个subTask共享同一个JVM，同一个JVM中task共享TCP连接和心跳信息，共享数据集和数据结构，从而减少Taskmanager中的task开销。

• Flink 可以配置jobManager的taskSlot数量，来决定每个TaskManager上可以执行多个subTask，由于TaskSLot只会对内存进行隔离，不对CPU进行隔离，建议线上配置 taskSlot的📄设置和该Taskmanager节点CPU CORE 的数量保持一致

TaskSlot 共享 & SlotSharingGroup共享组

• 默认情况Flink允许共享taskSlot，即便他们是不同subTask，只要是同一个Flink作业即可，结果就是一个SLot可以持有整个作业的管道

• Flink中共享taskSlot 解决的问题：

• 我们在提交Flink应用程序时需 要关注我们程序中到底有多少subtask，然后再衡量Flink集群中slot个数是否足够，在一定程序上需 要的slot资源较多。另外一个方面是在Flink中运行的task对CPU资源的占用不同，有CUP密集型task 操作和CPU非密集型task操作情况，例如在Flink集群中source和map操作只是读数据后转换，对CPU占用短，但是window这种穿口计算聚合操作设计大量数据计算，占用CPU资源长，这就导致运行时候source/map，sink操作非常快，window操作时间长，source/map对应的subtask会等待window对应的subtask执行，同样sink的对应的
  subtask也会等待window对应的subtask执行，站在集群slot角度上来看就出现了一些taskslot非常" 繁忙"，一些taskslot非常"轻松"，集群的资源综合利用不高。

• taskslot共享就可以很好地解决以上问题，Flink任务所有的subtask均衡的分散到不同的taskslot上 执行，一个taskslot贯穿执行整个流程的subtask，这样每个taskslot、每个TaskManager上的资源 使用情况非常均衡。所以允许 slot 共享有两个主要优点:

  • Flink集群所需要的taskSlot和作业中使用的最大并行度恰好一样，不需要关注Flink程序总共包含多少个subTask
  • 容易获取更好的资源利用，如果没有slot共享，非密集型subtask（source/map）将会阻塞 和 密集型subtask（window）一样多的资源，通过slot共享，确保繁重的subtask在taskManager之间公平分配