小白学习Flink系列--第四篇(架构)

	如图所示，为Flink计算框架架构，在这里的架构指的就是Runtime  部分，也就是Flink core

​ 观察上图，我们不妨猜一下Runtime的作用有哪些？

• 提出疑问

  • Runtime夹在资源调度和上层计算处理之间，必定存在交互，核心逻辑就是为上层Task分配底层的资源
  • 既然这样，就牵扯到任务的调度，资源的分配，以及首先得提交任务
  • 似乎就是这样，但我们需要考虑到容错性，也就是Task挂掉或者fail了怎么办？显然Runtime层需要实现此逻辑

• Runtime层组件介绍

  • JobManager，也叫master,负责任务调度，协调故障恢复(使用checkpoint) ，可部署多个实现HA

  • TaskManager ，也叫worker，执行数据流中的task，缓存和交换数据

  • client：严格意义上，clientb不属于Runtime组件，他的作用是用来准备和发送dataflow(注意：这里并不是数据，而是流，也就代表过client对数据进行处理，详细流程在任务提交中会提到)，发送过去，然后等待结果，就是这样枯燥

  • 什么是DataFlow呢？

    • 先从Flink流式计算引擎讲起，我们都知道，计算引擎一般由三部分组成，source transform sink，如下图所示，source是数据源，transform对数据进行转换，Sink负责输出，组件之间转换的数据就是流

Flink基础实际上就是流和转换，Transform来源于一个或者多个stream作为输入的operator，通过transform计算又产生N个result stream

以一段代码为例进行说明，如下图所示，Flink程序会被映射为DataFlow，包含了流以及operator，每一个dataflow由N个source开始，又流向N个sink，类似于有向无环图

Task

​ 什么是Task? Task真正干活的单位，上文说到，Flink基础是流和transform,那么按照最简单的逻辑，每个operator都作为一个Task就好了，这样可以吗？

​ 可以，但是消耗太大，我们知道，每个Task都需要起一个线程，对每一个operator都作为一个Task的话，缺点显而易见，线程之间的切换需要消耗大量资源，以上图为例，假设source并行度为100，map也是100，keyby为100，sink为50的话，就要起350个线程，是否有优化的空间呢？

​ Flink将代码中可以优化的算子优化成一个算子链，如下图所示，简单来说就是在可以优化的算子包装起来，放到一个Task中，下面这个需要多少个线程呢？100+100+500=250,减少了150个线程，大大提高了吞吐量，同时也降低了延迟。那么问题又来了？合并成算子链条件是啥？我把所有算子都合并成一个算子链不就行了？

​ 显然是不行的，是由以下条件的

• 上下游算子并行度一致，这点很好理解，source并行度为100，map是50，如何合并？
• 下游节点的入度为1
• 上下游节点都在同一个slot group中
• 下游节点的chain策略为always，map flatmap filter默认是always
• 两个节点间的分区方式是forward
• 用户没有禁用chain

​

那么问题又来了，你说的倒是很清楚，slot又是什么鬼？莫慌，知识都是环环相扣的，继续为大家讲slot是什么

Task slot和resource

​ 接上文，先捋以下关系，operator放在算子链中，一个算子链就是一个Task，Task呢实际上放在Task slot中，Task slot可以放很多个Task 而TaskManager又包含多个Task slot,一环套一环的关系。不理解？看下图就明白了

​

一个TaskManager也就是一个节点，一个节点代表一个进程。

搞清楚了层级关系之后，我们再来讲slot

• slot是干嘛用的？
  • slot的特点就是共享CPU,但是内存隔离，这样做的好处有以下几个方面
    • 举个简单例子，Flink计算真正耗资源的在于shuffle算子，牵扯到数据的重分区，使用slot以后，由于slot CPU是共享的，所以耗资源的task就可以和耗资源较少的Task放在一起，提高了资源的利用率。
  • slot是一个静态概念，代表的是执行并发的能力