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