Flink/Kinesis Analytics：子任务间均匀数据读取与键组分配问询

解决方案 #

1. 实现Kinesis Source的分片均匀分配 #

Flink的Kinesis Consumer默认分片分配逻辑在并行度不匹配时易出现负载不均，可通过以下方式调整：

• 优先调整作业并行度为32：当前并行度为1是核心问题——所有分片的读取逻辑都运行在单个任务中，32个KPU的并行能力完全没被利用。将并行度设为32后，每个子任务可独立处理分片，Flink会自动将60个分片尽可能均匀分配到32个子任务（每个子任务分配1-2个分片）。
• 自定义分片分配器：若必须保持并行度为1，可实现自定义KinesisShardAssigner，编写逻辑确保32个子任务都能分配到分片（例如给空闲子任务额外分配分片），但此方案不推荐，因为无法发挥并行计算能力。
• 优化Consumer配置：确保flink.streaming.kinesis.shard.check.interval（默认10秒）配置合理，让Flink及时检测分片状态并重新分配；同时避免将flink.streaming.kinesis.consumer.max.poll.records设置过大，防止单个子任务一次性拉取过多数据导致负载集中。

2. 实现键组的均匀分配 #

KeyBy后负载不均的核心是并行度不匹配与哈希分布倾斜，可通过以下方案解决：

• 将作业并行度设为32：键组数量默认与作业并行度一致，并行度为32时，Flink会将键组均匀分配到32个子任务，从根源上保证负载均衡。
• 替换KeyBy为Rebalance算子：若随机数的哈希分布存在天然倾斜，可改用rebalance()算子——它会通过轮询方式将数据均匀分发到所有子任务，比随机Key的哈希分配更稳定可靠。
• 优化哈希策略：若必须使用KeyBy，可对随机数字进行二次哈希（如用MurmurHash）后再做KeyBy，减少哈希分布倾斜的概率，让键组分配更均匀。

内容的提问来源于stack exchange，提问作者kellanburket