Flink中subTask，并行度，slot你分得清吗？

Apache Flink是一个开源的流处理框架，应用于分布式、高性能、高可用的数据流应用程序。可以处理有限数据流和无限数据，即能够处理有边界和无边界的数据流。无边界的数据流就是真正意义上的流数据，所以Flink是支持流计算的。有边界的数据流就是批数据，所以也支持批处理，目前flink在各大互联网公司应用广泛，是最为流行的大数据实时计算引擎之一。

flink可以高性能的完成对数据的实时计算，一个主要原因在于，在flink中一个作业计算逻辑是有多个Task配合完成的，多个Task串联在一起形成一个DAG，在这个DAG，通过配置Task的并行度，可以实现各个Task的并行处理，在大数据的场景下，通过优化各个Task的并行度，来充分利用分布式计算能力，来提升整个作业的吞吐量。

为了更好的说明flink中的Task并行度，我们需要先了解一下，下面的几个概念。

算子

在flink中，一个复杂业务逻辑的实现，是由多个小的基本计算单元组成，这些小的基本计算单元，被称为算子。

一个作业通常有三部分组成：输入，计算和输出。而这三部分是有三种算子组成，分别对应：source，transform和sink。

source：对应作业的数据源，在实际应用场景中如kafkasource，从kafka中消费数据作为作业的输入。

transform：表示对输入的数据进行转化，比如map操作，表示对输入的数据进行遍历并进行转换。

sink：表示对transform转化后的数据，进行输出，比如输出到关系型数据库中等。

public static void main(String[] args) throws Exception {

        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

        DataStreamSource<Long> source = env.addSource(new ExampleCountSource()); // source

        SingleOutputStreamOperator<String> map = source.map(ele -> ele.toString()); // transform

        map.addSink(new MySink()); // sink


        env.execute("stream  process");
    }

任务

Task是flink中的一个逻辑概念，一个任务由一个或者多个算子组合而成(多个算子构成一个任务是需要满足一定的条件才可以，有兴趣的老铁可以来了解一下 Operator Chain),为了提升任务执行的效率，可以对任务配置并行度，使任务在实际运行过程中并行执行，此时该任务的多个并行任务被称为子任务(subTask)。如下图：每个虚线框是一个任务，框里的圆是子任务。

总结来说：Task是逻辑概念，subTask是实际运行的实例，一个Task的subTask个数就是上面说的并行度。在上图中Task有3个，subTask有6个。

Slot

Slot是flink集群中资源分配的基本单位，slot主要分布在TaskManager中，了解flink架构的老铁都知道，TaskManager是一个jvm进程，是subTask运行的地方。

当TaskManager启动的时候会将自己的资源以Slot的方式注册到ResourceManager，然后JobManager从ResourceManager处申请到Slot资源之后，会将subTask调度到这些Slot上面去运行，在整个过程中sub task是调度的基本单元，Slot则是资源分配的基本单元。
这里需要说明一下：slot之间内存隔离，cpu不隔离，也就是内存是独立的，但是cpu是共享的。

Task并行度和slot个数之间的关系是怎样的？

一个Task的并行度，要求该任务有指定个数个subTask并行执行，所以要求每个subTask运行在不同的solt中，因此slot的个数不能小于任务的并行度。

slot sharing是什么鬼

slot sharing所表达的意思是 slot共享，但是这里需要注意的是，共享slot的subTask需要满足一下条件：

1.subTask必须来自同一个job，以为不同job之间资源是隔离的，TaskManager都是隔离，更不用说TaskManager上的slot了。

2.subTask必须来自不同Task，同一个Task的subTask不用共享一个slot，否自就失去了并行度的意义了。

为什么要进行slot sharing？

要回答这个问题，我们不妨采用反证法，如果slot不共享，每个sub task都运行在独立的slot上会发生什么？

我们知道一个job的DAG中，不同Task对资源的消耗是不同的，如果都均分slot，那必然有些资源利用率高，有些低。限制不同Task的sub task共享可以尽量让资源占用高的和资源占用低的放一起，这样可以是资源得到重复利用，否则占用资源少的sub task运行完后，给其分配的slot就闲置了。

除此之外，slot sharing也降低了一个job运行对资源依赖的门槛，如果每个slot sharing，那么一个job运行需要的slot个数和job中所有的sub task个数相同，而有了slot sharing，需要的slot个数，取决于DAG中所有Task中最大的并行度个数。

在有slot sharing的场景下，上文中的应用程序只需要2个slot即可：

没有slot sharing的场景下，则需要6个slot：