企业官网建设流程全解析

做Flink开发的朋友，迟早会在某个深夜盯着监控面板问同一个问题：这个并行度到底怎么设置？我调大之后CPU没上去，调小之后延迟反而暴涨，到底问题出在哪一步？今天我就结合自己做过的实时数仓和实时风控链路，把并行度这个参数从头到尾拆一遍，讲清楚它控制的到底是什么，设置过大或过小分别会触发哪些连锁反应，以及怎么估算一个相对合理的值。

这篇文章适合刚接手Flink任务、对着WebUI发懵的新手，也适合已经上线过几个任务、准备系统性调优的老开发。全文不涉及复杂源码解读，只讲实战中能直接用的判断方法和操作经验。

1. 并行度到底控制的是什么

很多人在第一次接触并行度时，容易把它简单理解成“同时跑几个线程”。这个理解方向没错，但不够完整。并行度真正控制的是：一个算子会被拆成几个可以独立执行的子任务，每个子任务占用一个 slot，负责处理一部分数据流。

1.1 算子的并行度与子任务

Flink 作业从逻辑上分成多个算子，比如 source、map、keyBy、window、sink。并行度一旦设置，算子就会被实例化成多个并行子任务。举个例子，如果一个 map 算子并行度是 4，那它就会同时存在 4 个 subtask，每个 subtask 单独消费上游分给它的数据，算出结果后再送到下游。

这里要和另一个概念区分开：slot 是 TaskManager 里划分出来的资源单元，而并行度决定的是需要几个这样的资源单元。假设一个 TaskManager 有 4 个 slot，你把某个算子的并行度设成 8，那就需要拉两个 TaskManager 来凑资源。如果并行度设成 1，那就只有一个 subtask 在轮流消化全部数据。

数据流的分配方式和并行度也有直接关系。上游算子的并行度是 2，下游算子的并行度是 2，它们之间可以走 forward 连接，数据不需要重新打散，直接一对一转发。如果下游并行度变成了 4，那数据就必须通过 rebalance 或者 rescale 重新分配，这就引入了网络 shuffle。为什么调并行度会影响性能？很大一部分原因就在这个 shuffle 上。

1.2 什么是“合理的并行度”指标

判断一个并行度合不合理，不能只看资源占用率，还要看每个 subtask 的实际处理速率。比如某个算子的并行度是 5，但其中只有 3 个 subtask 在满负荷跑，另外 2 个长期处于低利用率状态，那说明并行度分配和上游数据分布不匹配，调大并行度反而浪费资源。

反过来，如果每个 subtask 都跑到 100% CPU，但数据还是不断堆积，说明单并发处理能力到了天花板，这时的瓶颈不是并行度不够，就是算子逻辑本身太重，比如做了大批量维表关联或者复杂状态计算。

所以并行度不是“越大越好”，也不是“越小越省”，它要和数据量、单并发处理能力、上游分区数、下游存储写入能力四个因素对上。

2. 并行度的设置层级和优先级

Flink 并行度可以在多个位置设置，不同位置的生效范围不同。如果不清楚它们之间的关系，很容易出现“我明明在代码里设置了并行度，为什么线上跑的和我预期不一样”的情况。

2.1 四种常见设置方式

最常用的是以下几种：

实际操作中，优先级从高到低可以这样理解：算子单独设置最高，然后是提交参数，再然后是执行环境设置，最后才是配置文件默认值。

有一个经常踩的坑：代码里给 source 设置了并行度，但下游算子没设，那你看到的效果可能就是 source 并行度和整体并行度不一致，导致数据经过一次 shuffle 后分布不均匀。这种情况建议要么全部按算子显式设置，要么统一用全局并行度，再针对少数瓶颈算子单独调整。

2.2 全局并行度和算子级并行度怎么取舍

我个人的习惯是这样：主线流程先用全局并行度确定一个基线，然后再对 source、复杂计算算子、sink 这三个位置单独调整。

全局并行度适合大多数简单的清洗、转换任务，设置少、运维简单。但如果链路里既有纯过滤、又有窗口聚合、还有异步 IO 维表关联，它们的资源消耗差异很大，统一用一个并行度会非常浪费。纯过滤逻辑很轻，给它太多并行度会空转；窗口聚合和维表关联通常比较重，并行度小了又会积压。

所以更合理的做法是：把高消耗算子的并行度单独调大，把轻量算子的并行度保持在一个够用的水平，不要让所有算子都跟着全局并行度一起膨胀。

2.3 一个完整的并行度设置示例

用 DataStream API 举个例子：

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setParallelism(4); DataStream<String> source = env.addSource(new MySource()) .setParallelism(6); DataStream<OrderInfo> orderStream = source .map(new ParseFunction()) .setParallelism(6); DataStream<AggResult> result = orderStream .keyBy(order -> order.getUserId()) .window(TumblingEventTimeWindows.of(Time.minutes(5))) .process(new MyWindowFunction()) .setParallelism(1); result.addSink(new MySink()) .setParallelism(3);

这里 source 设成 6，是因为上游消息队列有 6 个分区；窗口聚合结果需要写存储，写入端并发受下游表分区数量限制，设成 1 或者 3 都可以接受。如果整个作业只用env.setParallelism(6)，那窗口也会被切成 6 份，最终结果分散写到多个文件或分区，反而增加下游合并成本。

SQL 任务则是另一种写法：

SET 'parallelism.default' = 4;

也可以在 flink-conf.yaml 里全局配置：

parallelism.default: 4

这里给 SQL 任务提个醒：Flink SQL 会自动把 source、维表关联、聚合算子拆成不同节点，你设定的是所有节点的默认并行度。SQL 里调整并行度，往往比 DataStream 更依赖具体版本的表现，改完后最好看一下 Plan 里每个节点实际分配到几个并行实例，别只看任务总并行度。

3. 并行度过大带来哪些连锁反应

“并行度拉满”听起来很有气势，实际上带来的问题可能比并行度不够更难排查。因为资源明明很充足，但任务性能反而下降，这个反直觉的现象经常让人误判成代码问题。

3.1 调度与网络shuffle开销上升

每个 subtask 都是一个独立的任务实体，它有自己需要初始化的资源，比如连接池、状态后端实例、定时器服务。并行度从 8 调到 32，不是简单地把处理能力放大 4 倍，而是初始化成本也放大 4 倍。

更重要的是，算子并行度发生变化后，上下游之间的数据连接方式也会变。并行度相同的算子还能尽量复用 forward 转发的优化路径，一旦并行度不同，数据就必须经过 shuffle。你调大一个算子的并行度，相当于在下游引入了一次流量再分配，跨节点的数据传输量随之增大。数据量大的时候，这个成本会直接体现在延迟上。

举个实际场景：某个实时ETL任务，上游 map 并行度是 3，下游 filter 并行度是 16，每条数据都要从 3 个分片被随机分散到 16 个分片上。网络带宽充足时问题不大，但一旦流量到了高峰，shuffle 环节就会变成瓶颈，任务延迟从秒级涨到分钟级。这类问题的排查方向往往不是某个算子处理能力不足，而是并行度配置导致的连接数暴涨。

3.2 checkpoint 与状态恢复的隐患

并行度过大对 checkpoint 的影响经常被忽视。Flink 做 checkpoint 时，需要等所有输入通道的 barrier 对齐。一个算子的并行实例越多，它需要对齐的输入通道就越多，等待时间也越长。尤其是在 fan-in 严重、多个上游算子合并到一个下游算子的场景里，并行度设置过高，barrier 对齐时间会显著拉长，直接导致 checkpoint 频繁超时。

并行度过大还会推高状态后端的内存和磁盘开销。每个 subtask 会维护自己的状态实例，比如 Ro cksDB 状态下，每个 subtask 一个 RocksDB 实例。并行度从 8 涨到 32，状态总量不会变，但实例数量变成了原来的 4 倍，本地磁盘占用、内存映射开销、线程开销都会成倍增加。

3.3 数据倾斜的作用反而被放大

并行度增大后，数据被切分到更多分片，如果数据本身存在热点 key，热点会只落在少数几个分片上。并行度越大，热点分片在整个并行度中的占比越低，但单个热点分片承受的流量并不会减少。

比如订单数据中某个头部商户的订单量占 30%，你用并行度 8 去 keyBy，这个热点 key 只落在 1 个分片上，那这个 subtask 需要承担 30% 的核心流量。你把并行度调到 32，热点 key 仍然落在 1 个分片上，承担比例还是 30%，并没有因为并行度变大而被分散到更多分片。唯一的变化是，那 31 个非热点分片更空闲了，热点分片还是那个热点分片，数据倾斜反而表现得更加刺眼。

3.4 小文件与下游存储压力

流式任务把数据写到文件系统或消息队列时，并行度过大还会造成一系列存储问题。一个 sink 算子并行度是 10，它同时打开 10 个文件句柄或分区写入器。如果每条数据量不大，单个并行实例产生的文件会非常小，落到数仓里就是一堆几 KB 的小文件，后面跑批任务光合并文件就要折腾很久。

写入 Kafka 时也是一样，sink 并行度大于 topic 分区数，必然有部分 subtask 空闲，或者多个 subtask 抢同一个分区的元数据，造成写入不均衡。

所以，如果你发现任务并行度已经很高，但吞吐没涨，先别急着继续加并行度，检查一下是否出现了空转 subtask、checkpoint 超时、shuffle 压力变大这类“虚胖”问题。

4. 并行度过小造成哪些瓶颈和风险

并行度过大的问题相对隐蔽，并行度过小的问题就直观多了：延迟上涨、消息积压、吞吐上不去。但除了这些表面现象，并行度过小还会带来一些更深的稳定性风险。

4.1 单点处理能力被打满

并行度小，意味着单个 subtask 要承担的数据量更大。虽然单条消息处理时间可能只有几毫秒，但当所有数据都要排到这个 subtask 上时，吞吐就会被这个单点的处理能力卡住。

我遇到过的一个真实场景：某个订单实时统计任务，source 从消息队列读数据，高峰每秒 5 万条，但整个作业被设成了并行度 1。单个 subtask 清理解析加聚合，峰值最多能扛 3 万条每秒，于是一到业务高峰，消费位点就开始落后，消息积压越攒越多。一开始还以为是消息队列的消费组出了问题，排查半天才发现就是并行度太小，source 和后续算子都挤在同一个 subtask 上。

这个问题在本地开发时尤其容易碰到。本地执行环境如果没设置并行度，很多情况下默认并行度会和开发机的 CPU 核心数一致。代码写到一半，单机运行流畅，部署到集群后因为parallelism.default默认值是 1，任务直接跑成单并发，吞吐骤降。这种本地和线上表现不一致的坑，年年都有人踩。

4.2 反压会从下游一直传导到源端

并行度不足时会触发反压。反压不是某个算子的单点问题，它会顺着执行链路往上传递。下游算子处理不过来，就会把压力传递给上游，最终 source 消费速度被迫降低，整个链路延迟变大。

更麻烦的是，反压的定位有时比调并行度本身更复杂。因为反压可能由最下游的存储写入慢引起，也可能由一个中间算子的并行度不足引起。如果只是简单地把全局并行度调大，可能会出现“最下面 sink 扛得住、中间聚合算子上游压力没变化”的局面。

所以遇到延迟飙升，不能只盯着并行度看，先顺着 WebUI 的 BackPressure 面板找到真正发生反压的节点，再决定是不是这个节点需要增加并行度。

4.3 状态和故障恢复的脆弱性

并行度越小，状态就越集中。少数几个 subtask 扛着全部 key 的状态，一旦其中一个 subtask 宕机，Flink 需要重新调度并在新节点上恢复这块状态。状态越集中，恢复时间越长，不可用时间越久。

而且并行度过小时，如果某个 subtask 因为异常被重启，它上面负责的那部分数据流会完全停摆，整个作业的可用性都压在这一个点上面。并行度大一些，至少能把故障爆炸半径缩小，一个 subtask 出问题，不会影响其他分片继续处理。

4.4 多算子共用并行度导致资源不均

还有一种情况是全局并行度比较小，但单个算子内部又确实存在高负载逻辑。比如一个算子既做了 JSON 解析，又做了维表关联和规则过滤，它本身是耗 CPU 的大户，但并行度只有 2。同一批流量被分成 2 份，每个 subtask 要同时承担解析、关联、过滤三件事，任何一环都不能掉链子。

对这种算子，正确地做法是把它的并行度单独拉高，让计算负载分散开。但很多人的第一反应是调整全局并行度，结果轻量的 source 也跟着翻倍，白白浪费资源，真正堵住的算子还是没有改善。这个误区也解释了为什么我一直强调算子级并行度比全局并行度更实用。

5. 怎么估算一个相对合理的并行度

并行度的计算没有精确公式，但有相对可靠的估算思路。核心是三个变量：输入速率、单并行实例的处理能力、上游数据的物理分区数。

5.1 基于速率的简单估算

假设一个实时清洗任务，上游消息队列高峰每秒进入 3000 条订单消息。你在测试环境压出单并行实例的稳定处理能力，大约是每秒 1500 条。那理论并行度就是：

理论并行度 = 输入速率 / 单实例处理能力 = 3000 / 1500 = 2

考虑到业务高峰的波动和机器性能差异，一般再留 1.5 到 2 倍的余量，也就是并行度取 3 到 4。但如果上游消息队列只有 2 个分区，source 并行度设为 3 就超过分区数了，会有 1 个并发实例拿不到分区，白白空转。

所以更完整的估算需要加一个约束：

source并行度 <= 上游分区数

如果消息队列有 12 个分区，你可以直接取 12。如果单实例处理能力大于单分区流量，也可以只取 6 或 4，让每个并行实例多消费几个分区，但前提是这个实例扛得住对应的总流量。

5.2 与分区数对齐的思路

source 并行度一般不需要超过上游分区数。超过分区数后，多出来的并发实例没有数据可消费，只会占着 slot 浪费资源。相反，如果上游分区数远大于 source 并行度，比如 12 个分区配 2 个并行度，那每个并行实例要消费 6 个分区的数据，单实例压力会明显增大。

sink 侧也类似。写入 Kafka 时，sink 并行度最好和 topic 分区数形成整数倍关系，防止写入分配不均。写入数据库时，则要考虑目标表的分区数和写入事务锁竞争，并行度太高会把数据库连接池跑满。

窗口聚合算子的并行度，不能和上游一样一味地大。窗口算子往往需要维护窗口状态，并行度太高会带来一堆中间状态文件。一般建议窗口算子的并行度控制在“数据总量除以单实例可维护状态量”这个范围内，不要盲目翻倍。

5.3 调优路线从默认值开始

我的调优路线通常是这样的：

先按上游分区数或预估吞吐设一个初始并行度，比如消息队列 12 分区就设 12。跑几个小时后，打开 WebUI 看每个算子的负载曲线，把负载长期低于 20% 的算子并行度降下来，把长期接近 100% 的算子并行度提上去。

改的时候不要全局一次性大改。先动瓶颈算子，观察半小时，看反压是否缓解、checkpoint 是否稳定，再动第二个。一次只改一个目标，这样出了问题能准确知道是哪次调整引起的。

另外，并行度的调整不是一劳永逸的事。业务高峰和低峰的数据量差距很大，有的团队会在流量高峰期临时提高并行度，低谷期再降回来。这种操作可以用在有状态任务上，但要注意，并行度变化会触发状态重分配，有状态算子调整并行度时必须预先考虑状态恢复的情况。

6. 常见问题与踩坑记录

以下这些都是我在排查并行度问题时遇到过、也帮别人处理过的典型场景，整理成速查表供参考。

6.1 修改并行度后状态恢复的问题

有状态任务最怕的就是盲目调整并行度后重启。状态在并行度变化时会被重新分组，旧状态映射到新子任务的过程对版本和状态后端比较敏感。我踩过的坑是：没做任何预处理，直接调大并行度后从 checkpoint 恢复，结果作业一直处于初始化状态，状态加载耗时成倍上涨，最后只能停掉任务、重新从最近 savepoint 恢复。

这里我的建议是：对于有状态任务，调整并行度之前，先梳理这个算子有没有 keyed state 或者 operator state。如果有，尽量带着 savepoint 做一次全量停止，再启动新并行度的任务去加载 savepoint。不要在作业运行中临时通过某些管理平台改并行度，除非你对内部的状态重分布机制非常熟悉。

6.2 提高并行度能不能解决数据倾斜

不能。这个答案很明确。

数据倾斜是 key 分布不均导致的，并行度只影响分片数量，不影响 key 的归属。热点 key 在 hash 之后始终会落到特定分片上，并行度再大，它也只落在其中一两个分片上。想解决问题，要么改造 key，要么做两阶段聚合，要么把热点 key 单独拆出来走独立逻辑。

有一种情况例外：没有 keyBy 的纯并发处理场景，比如 map、filter 这些算子，它们本身不打散 key，并行度提高后流量会重新平衡，这时调并行度的确有效。所以判断能不能靠提高并行度解决积压，先看算子类型。

6.3 并行度与背压的排查顺序

遇到背压时，我的排查顺序是：

先看 WebUI 的 BackPressure 面板，找出是哪个算子打出了背压。然后看这个算子的处理速率和上游输入速率。如果处理速率明显低于输入，再看这个算子内部逻辑，是计算量大、状态操作慢，还是外部 IO 慢。最后才决定是不是要调整并行度。

很多人一看到背压就加并行度，但如果瓶颈是某个算子在做大量同步维表查询，加并行度只能让更多线程同时去查外部存储，数据库反而先扛不住。这时应该先做异步化改造，或引入缓存，再考虑水平扩展。

6.4 高并行度下如何避免 checkpoint 超时

并行度设置高时，checkpoint 超时是一个高发问题。除了降低整体并行度之外，还有一个办法是减少上游到聚合算子的扇入。比如让部分轻量过滤逻辑在上游先做完成，减少进入聚合算子的数据量，这样 barrier 对齐需要等待的通道数会少一些。

也可以检查是否开启了 unaligned checkpoint。如果任务里对精确一次语义的要求没那么苛刻，可以考虑用非对齐 checkpoint 来缩短 barrier 对齐等待时间。但要注意，非对齐 checkpoint 对状态大小和存储吞吐的要求会变高，需要实际测试后再上生产。

另外一个容易被忽略的点是：并行度过高时，单个 TaskManager 里运行的 subtask 数量也会增加，它们共享进程内的网络缓冲和内存资源，内存不足时反而会拖慢整体处理速度。这种情况下，调整并行度的同时还需要检查 TaskManager 的可用内存和 slot 数是否匹配。

最后再分享一个小技巧

我在实际项目里调并行度时，习惯把每次调整记录下来：调整时间、并行度前后数值、观察窗口期、延迟和吞吐变化。看起来麻烦，但在多团队共用集群的环境里非常有用。经常会出现一个人调了全局并行度，另一个人随后又改了某个算子的并行度，结果问题反而变严重，最后谁也说不清是哪个参数导致的。

记录调整历史之后，每次回滚都能很快定位到之前稳定运行的配置组合。别小看这份记录，它在排查疑难问题时的作用，比很多监控图表都直接。并行度本身没有绝对标准，一个任务合理的并行度，是在流量、资源、成本三者之间反复测试出来的。所以别急着追求一个“标准答案”，用挑参数的态度去对待它，多观察、小步调，你会很快找到和自己任务最匹配的那组配置。