流处理作业的并行子任务数受限于分区数量，想提升并行度先看数据源分区够不够，这是实时计算调优的第一道闸门。
为什么流处理作业的并行子任务数为什么受限于分区数量
流处理作业的并行子任务数，本质上就是同一个算子被复制成几份同时跑，每份子任务要拿到属于自己的输入数据，数据从哪来？多数来自 Kafka、Pulsar、RocketMQ 这类分区消息队列，消息队列靠分区实现水平扩展，一个分区只能被同一个消费组里的一个消费者消费，流处理引擎的算子子任务在消费数据源时,角色等同于消费者。
当一共只有 8 个分区，却把算子并行度设成 16，8 个子任务根本分不到任何一个分区，它们不会处理任何数据，只在那里空转，这不是引擎 bug，也不是配置写错，而是分区数量给并行度划了硬上限。
用一个简单公式理解：
- 有效并行度 = min(算子并行度,数据源分区数)
- 分区数充足时，提升并行度可以直接扩大吞吐
- 分区数不足时，提升并行度只会增加空转实例
很多第一次接触实时计算的开发者会把并行度当成 CPU 核心数来调，结果作业越调越慢,原因就在这里。
Flink 并行度和分区数关系：先理解三个基本对象
要彻底搞清楚“并行子任务数受限于分区数量”这句话，需要先分清 Flink 里三个容易混在一起的数值。
Flink 并行度
指某个算子的实例数量。flatMap 算子的并行度设为 12，作业运行时这个算子就有 12 个 subtask 同时处理数据。
数据源分区数
指上游 Kafka topic 或者 Pulsar topic 被分成多少个分区，通常由消息中间件管理员控制,不能随意调大调小。
最大并行度
Flink 用来做状态扩容的上限值，默认与版本有关，常见是 128 或 512，作业上线后通常不建议随意改动,否则影响状态恢复。
这三个值的关系很像水管的粗细：数据源分区数是上游来水的支管数量，并行度是下游接水的龙头数量，最大并行度是墙里预留的总管道口径，支管只有 6 根，龙头装 20 个也是干等。
Flink 并行度和分区数不一致会怎样
并行度和分区数不一致,实际效果分三种：
- 并行度小于分区数：每个子任务消费多个分区，作业能跑，但单个子任务压力可能不均
- 并行度等于分区数：每个子任务刚好消费一个分区，调度最干净
- 并行度大于分区数：多出的子任务拿不到分区，空转浪费资源，还可能导致反压判断失真
实际生产中，第三种情况最常见，尤其是集群资源充足、开发随手把并行度调大时。
Kafka 消费者并发数受分区数限制的典型故障场景
说一个常见的线上故障，某电商大促前夕，实时订单宽表作业消费延迟越来越大，值班同事第一反应是加并行度，把数据源算子的并行度从 4 提到 12，重启作业后，延迟没有下降，CPU 使用率反而升高，排查发现，上游 Kafka topic 只有 6 个分区，也就是说，这个作业的 12 个并行子任务里，有 6 个永远收不到数据，6 个仍然超载。
具体排查步骤如下：
- 先看 Kafka 分区数：
kafka-topics --describe --topic order_wide_topic，重点看PartitionCount一列 - 再看 Flink 作业数据源算子的并行度：检查
env.setParallelism(12)或者source.parallelism - 打开 Flink Web UI，进入数据源算子，查看
SubTasks页面，观察每个 subtask 的Records Received - 如果发现有多个 subtask 的接收记录数长期为 0，而其他 subtask 数值很高，基本可以判定分区数不足
这个案例里，正确的处理不是继续加并行度，而是先找 Kafka 管理员把 topic 分区扩到 12，或者改成 6 的倍数，扩完分区后，再重启作业,延迟很快恢复正常。
实时计算作业并行度调优，先扩分区还是先提并行度
很多团队在遇到消费延迟时，第一反应都是“并行度不够”，但在流处理体系里，分区是上游，并行度是下游，上游不扩,下游加再多也没有意义。
正确顺序
- 确认数据源分区数
- 确认当前数据源算子并行度
- 对比两者大小，找出真正的瓶颈
- 如果并行度已经接近甚至超过分区数，优先扩分区
- 扩完分区后，再同步调整作业并行度
- 观察每个 subtask 的输入记录分布，确认没有空转
Kafka 扩分区命令示例
kafka-topics --alter --topic order_wide_topic --partitions 12 --bootstrap-server kafka-broker:9092
需要注意，Kafka 分区只能增加不能减少，扩分区后，旧数据不会重新打散到新分区，只有新产生的数据才会进入新分区，如果作业依赖数据顺序，扩分区前要评估 key 的哈希分布是否会受影响。
不用扩分区也能增加并行度的办法
在某些场景下，不能马上扩分区，topic 被多个下游共用，或者 Kafka 集群磁盘压力大,这时可以在流处理作业内部做一次数据重分布：
- Flink 里使用
rebalance()或rescale()，让数据在算子间重新打散 - Spark Streaming 里使用
repartition(n)增加分区数 - 重分布会增加一次网络传输，带来 shuffle 开销，但能绕过数据源分区数的限制
行业共识认为，数据源处的并行度上限无法通过作业内部重分布直接突破，因为接收数据的那个算子仍然受分区数约束，真正要突破整体吞吐,仍然需要扩大源头分区。
Flink 最大并行度设置多少合适：调优实操建议
“Flink 最大并行度设置多少合适”是很多开发者在面试和实际调优中都会碰到的问题，先说结论：最大并行度不是越大越好，它直接影响状态恢复和扩容粒度。
设置原则
- 最大并行度必须大于等于作业运行时的最大并行度
- 建议将最大并行度设为分区数或并行度的整数倍，便于后续扩容
- 如果没有强需求，不要随便调大默认值，否则 checkpoint 恢复时可能要处理更多 key group
- 一旦作业上线，最大并行度不建议修改，修改等于换了一套状态切分方案
常见操作
Flink 中设置最大并行度：
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setMaxParallelism(256);
也可以在算子级别单独设置：
dataStream.map(x -> x).setParallelism(12).setMaxParallelism(128);
和分区数的配合
假设当前 Kafka topic 分区数是 24，作业并行度准备从 24 扩到 48，如果最大并行度之前设为 24，就没法扩到 48，必须修改最大并行度并做状态恢复，所以一开始评估分区增长空间时,就要把最大并行度留出余地。
不同流处理框架下并行子任务与分区数量的对比
不同框架对分区的依赖程度不同,但底层逻辑基本一致。
| 框架 | 并行单位 | 与分区数的关系 | 典型限制 |
|---|---|---|---|
| Apache Flink | 算子 subtask | 数据源算子并行度受分区数限制 | 多余 subtask 空转 |
| Spark Streaming | 接收器 + 处理线程 | 直连模式下每个分区对应一个 RDD 分区 | 并发数超过分区数时部分 executor 空闲 |
| Kafka Streams | 流线程 | 每个线程可消费多个分区 | 分区数不足时无法充分利用线程 |
| Structured Streaming | 查询线程 | 与 Kafka 分区一一对应 | 分区数决定最大并行度 |
可以看到，不管是 Flink 还是 Spark Streaming，流处理作业的并行子任务数受限于分区数量这一规则都没有例外，差别只在于具体 API 和绕过方式。
Q&A：流处理作业并行子任务数与分区数量的高频问题
Q1：流处理作业并行子任务数受限于分区数量，那把并行度调得比分区数大会发生什么？
多余的并行子任务会处于空转状态，不消费任何数据，它们在 Flink UI 里显示为 Running，但 Records Received 始终为 0，空转子任务不会报错，也不会拉高业务吞吐，只会占用 slot 和内存，更麻烦的是，如果这些子任务位于状态算子下游，可能还会让 watermark 推进和状态清理出现不一致。
Q2：Flink 并行度可以大于 Kafka 分区数吗？
可以设置，甚至作业也不会报错，但数据源算子的有效并行度不会超过分区数，只有在数据源算子之后引入 rebalance 或 shuffle 类算子，后续算子的并行度才能真正大于分区数，因为重分布会把数据重新打散到更多批次,突破源头一对一消费的限制。
Q3：怎么判断当前作业是否被分区数卡住？
打开 Flink Web UI，找到数据源算子，查看各 subtask 的输入记录数，如果一部分 subtask 接收量很高，另一部分长期为零，且上游 topic 分区数小于算子并行度，就可以判断被分区数卡住，也可以通过命令 kafka-topics --describe --topic 你的topic名 查看分区数，再和 Flink 作业配置里的并行度做比较。
流处理分区数限制不是一个需要绕过去的 bug，而是分布式流计算的底层契约，想让并行子任务真正跑满，先把数据源分区扩到位,再谈算子并行度才有意义。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/638076.html
