Flink基础（十二）：Parallelism 和 Slot 详解

Parallelism

parallelism 是并行的意思，在 Flink 里面代表每个算子的并行度，适当的提高并行度可以大大提高 Job 的执行效率，比如你的 Job 消费 Kafka 数据过慢，适当调大可能就消费正常了。
parallelism的设置有三个地方：

flink-conf.yaml 配置文件中
parallelism.default: 1
代码中设置全局的并行度
```
 env.setParallelism(n)
```

代码中为算子设置单独的并行度

data.keyBy(new xxxKey()).flatMap(new XxxFlatMapFunction()).setParallelism(5).map(new XxxMapFunction).setParallelism(5).addSink(new XxxSink()).setParallelism(1)

三种并行度设置的级别大小为：
算子设置并行度 > env 设置并行度 > 配置文件默认并行度。

Slot

slot是槽的意思，每个slot能执行一个并行度的任务，每个taskManager上能有多个slot；假如一个TaskManager上有4个slot，那么TaskManager为每个slot分配25%的内存，可以在一个 Slot 中运行一个或多个线程，同一 Slot 中的线程共享相同的 JVM。注意 Slot 只对内存隔离，没有对 CPU 隔离。
每个 Flink TaskManager 在集群中提供 Slot，Slot 的数量通常与每个 TaskManager 的可用 CPU 内核数成比例（一般情况下 Slot 个数是每个 TaskManager 的 CPU 核数）。Flink 配置文件中设置的一个 TaskManager 默认的 Slot 是 1。

Slot 和 Parallelism 的关系

Slot 是指 TaskManager 最大能并发执行的能力
parallelism 是指 TaskManager 实际使用的并发能力
parallelism 是可配置、可指定的
假如程序设置的并行度超过了 TaskManager 可用的 Slot 数量，所以程序一直在等待资源调度并超过了一定的时间（该时间可配置），会抛出异常。

如何合理的设置并行度？

Source 端并行度的配置：
数据源端是 Kafka，作业的并行度和 Kafka 的分区数是否一致，如果小于 Kafka 的分区数，那么可以增大并行度至 Kafka 的分区数，然后再观察作业消费速度是否可以跟上数据生产速度；如果已经等于 Kafka 的分区数了，那得考虑下是否 Kafka 要扩大分区，但是这样可能会带来 Kafka 其他的问题，这个操作需要谨慎。
中间 Operator 并行度的配置：
数据从 Source 端流入后，通常会进行一定的数据转换、聚合才能够满足需求，在数据转换中可能会和第三方系统进行交互，在交互的过程中可能会因为网络原因或者第三方服务原因导致有一定的延迟，从而导致这个数据交互的算子处理数据的吞吐量会降低，可能会造成反压，从而会影响上游的算子的消费。那么在这种情况下这些与第三方系统有交互的算子得稍微提高并行度，防止出现这种反压问题。
除了这种与第三方服务做交互的外，另外可能的性能瓶颈也会出现在这类算子中，比如你 Kafka 过来的数据是 JSON 串的 String，然后需要转换成对象，在大数据量的情况下这个转换也是比较耗费性能的。
所以数据转换中间过程的算子也是非常重要的，如果哪一步算子的并行度设置的不合理，可能就会造成各种各样的问题出现。
Sink 端并行度的配置：
Sink 端是数据流向下游的地方，可以根据 Sink 端的数据量进行评估，可能有的作业是 Source 端的数据量最大，然后数据量不断的变少，最后到 Sink 端的数据就一点点了，那么在最后的这个地方就可以将并行度设置的小一些。
另外 Sink 端也是要与下游的服务进行交互，并行度还得根据下游的服务抗压能力来设置，如果在 Flink Sink 这端的数据量过大的话，然后在 Sink 处并行度也设置的很大，但是下游的服务完全撑不住这么大的并发写入，也是可能会造成下游服务直接被写挂的，下游服务可能还要对外提供一些其他的服务，如果稳定性不能保证的话，会造成很大的影响，所以最终还是要在 Sink 处的并行度做一定的权衡。
Operator Chain：
对于一般的作业（无特殊耗性能处），可以尽量让算子的并行度从 Source 端到 Sink 端都保持一致，这样可以尽可能的让 Job 中的算子进行 chain 在一起，形成链，数据在链中可以直接传输，而不需要再次进行序列化与反序列化，这样带来的性能消耗就会得到降低。