1. 合理的评估 Flink 任务的并行度
Flink 任务并行度合理行一般根据峰值流量进行压测评估，并且根据集群负载情况留一定量的 buffer 资源。
如果数据源已经存在，则可以直接消费进行测试
如果数据源不存在，需要自行造压测数据进行测试
1.1 对于一个 Flink 任务来说，一般可以按照以下方式进行细粒度设置并行度：
-
source 并行度配置：以 kafka 为例，source 的并行度一般设置为 kafka 对应的 topic 的分区数
-
transform（比如 flatmap、map、filter 等算子）并行度的配置：这些算子一般不会做太重的操作，并行度可以和 source 保持一致，使得算子之间可以做到 forward 传输数据，不经过网络传输
-
keyby 之后的处理算子：建议最大并行度为此算子并行度的整数倍，这样可以使每个算子上的 keyGroup 是相同的，从而使得数据相对均匀 shuffle 到下游算子，如下图为 shuffle 策略
- sink 并行度的配置：sink 是数据流向下游的地方，可以根据 sink 的数据量及下游的服务抗压能力进行评估。如果 sink 是 kafka，可以设为 kafka 对应 topic 的分区数。注意 sink 并行度最好和 kafka partition 成倍数关系，否则可能会出现如到 kafka partition 数据不均匀的情况。但是大多数情况下 sink 算子并行度不需要特别设置，只需要和整个任务的并行度相同就行。
2.合理评估任务最大并行度
-
前提：并行度必须 <= 最大并行度
-
最大并行度的作用：合理设置最大并行度可以缓解数据倾斜的问题
-
根据具体场景的不同，最大并行度大小设置也有不同的方式：
在 key 非常多的情况下，最大并行度适合设置比较大（几千），不容易出现数据倾斜，以 Flink SQL 场景举例：row_number = 1 partition key user_id 的 Deduplicate 场景（user_id 一般都非常多） -
在 key 不是很多的情况下，最大并行度适合设置不是很大，不然会加重数据倾斜，以 Flink SQL 场景举例：group by dim1,dim2 聚合并且维度值不多的 group agg 场景（dim1，dim2 可以枚举），如果依然有数据倾斜的问题，需要自己先打散数据，缓解数据倾斜
-
最大并行度的使用限制：最大并行度一旦设置，是不能随意变更的，否则会导致检查点或保存点失效；最大并行度设置会影响 MapState 状态划分的 KeyGroup 数，并行度修改后再从保存点启动时，KeyGroup 会根据并行度的设定进行重新分布。
-
最大并行度的设置：最大并行度可以自己设置，也可以框架默认生成；默认的算法是取当前算子并行度的 1.5 倍和 2 的 7 次方比较，取两者之间的最大值，然后用上面的结果和 2 的 15 次方比较，取其中的最小值为默认的最大并行度，非常不建议自动生成，建议用户自己设置。
https://mp.weixin.qq.com/s/bl-Y_hVvIn4HPSLez9TlWQ