1、Flink分布式运行架构


执行原理：

  1. Client提交作业，相当于Spark的Driver
  2. ActorSystem相当于Hadoop RPC，是用来进行节点之间通信的
  3. Client的程序DataFlow相当于是StreamGraph，而后通过优化成JobGraph
  4. 由ActorSystem把JobGraph提交到JobManager节点
  5. JobManager对JobGraph引入并行度造成ExecutionGraph
  6. 而后由TaskScheduler进行task之间的任务调度， 将task调配到TaskSlot外面运行，底层也是基于 ActorSystem进行交互
  7. TaskManager会返回task运行的状态信息给 JobManager，JobManager会将task运行的状态信息返回给客户端
  8. 在⻚面上能够看到工作的执行状况，是由 TaskManager返回给JobManager，而后 JobManager返回给客户端的

2、数据传输的策略

随机分区(shuffle)

  • 最简略的重分区形式就是间接“洗牌”。通过调用DataStream的.shuffle()办法，将数据随机地调配到上游算子的并行任务中去

    轮询分区(REBALANCE)

  • 通过调用DataStream的.rebalance()办法，就能够实现轮询重分区。rebalance应用的是Round-Robin负载平衡算法，能够将输出流数据平均分配到上游的并行任务中去

    重缩放分区(rescale)

  • 重缩放分区其实和轮询分区十分类似。不同点是轮询分区是针对所有分区进行轮询，重缩放分区只对指定分区外部进行轮询。如下图所示，source并行度为2，上游flatMap并行度为4：

    其实就是分成了小组，在组内进行REBALANCE。通过调用DataStream的.rebalance()

    播送(broadcast)

  • 简略说就是一份数据散发到上游所有的Task中。能够通过调用DataStream的broadcast()办法，将输出数据复制并发送到上游算子的所有并行任务中去

    全局分区(global)

  • 全局分区也是一种非凡的分区形式。这种做法十分极其，通过调用.global()办法，会将所有的输出流数据都发送到上游算子的第一个并行子工作中去。这就相当于强行让上游工作并行度变成了1

    自定义分区(Custom)

  • 当Flink提供的所有分区策略都不能满足用户的需要时，咱们能够通过应用partitionCustom()办法来自定义分区策略。
    在调用时，办法须要传入两个参数，
    第一个是自定义分区器（Partitioner）对象，
    第二个是利用分区器的字段，
    它的指定形式与keyBy指定key根本一样：能够通过字段名称指定，也能够通过字段地位索引来指定，还能够实现一个KeySelector

    * HASH

  • 对数据流进行keyBy/window、keyBy/reduce操作

3、Task并行度和Slot的关系

如果task的工作数量也就是并行度大于slot那么程序会无奈运行

  1. 一个TaksManager外面默认只有一个slot
  2. 在task运行的过程中会进行算子合并，会产生operatorChain的状况，比如说KeyBy->Map

Operator Chain的条件 :

  1. 数据传输策略是 forward strategy
  2. 在同一个 TaskManager 中运行
  3. TaskManager会尽量保障task在同一个JVM外面运行，有利于晋升效率

如下图，设置Source并行度为3，faltMap并行度为2，keyBy->sum->map并行度为2，Sink并行度为1，一共8个Task

如果全局并行度设置为1呢？

  • source -> flatmap 属于 operator Chain的状况，会将 souce->flatMap进行合并为一个task
  • keyby sum -> map -> sink也是属于 oprator chain的状况，会将 keyby sum -> map -> sink进行合并为一个task
  • 上游task -> 上游task 因为两头有 keyby所以数据传输的策略是 keybased strategy，也就是HASH
    所以上述2个Task

4、Flink四层图构造

  • Flink程序从提交到运行，须要经验如下4个阶段 :

    1. Stream Graph
    2. Job Graph
    3. Execution Graph
    4. Physical Execution Graph
  • Stream Graph和Job Graph是在客户端阶段实现的，而后client通过ActorSystem把JobGraph提交到JobManager
  • Execution Graph阶段会引入并行度
  • Physical Execution Graph 进一步确定了数据寄存的地位和收发的具体形式