Apache Beam Python Dataflow批处理解析多zip CPU利用率低问题

你观测到的CPU利用率偏低、工作负载未有效分发的现象，是两个容易产生认知偏差的运行机制叠加导致的，和使用FlatMap算子没有冲突：

• 任务并行度的上限由上游PCollection的初始分片粒度决定，和FlatMap的输出元素数量无关
  当前通过Create算子生成的PCollection仅包含50个元素——对应50个zip文件路径。Dataflow执行批任务调度时，对Create生成的集合采用静态分片逻辑，总共仅50个可调度分片。哪怕你在后续FlatMap逻辑中要为每个分片输出100万个文本文件内容，整个任务最多也只能同时调度50个并行执行单元。哪怕集群扩容到100个worker，也只会有50个worker领到任务，其余节点全程空闲。
• Python SDK的单分片执行模型无法复用单节点多核能力
  Dataflow运行Python pipeline时，每个分片对应独立的Python进程，受GIL约束，单个分片上的CPU密集型计算仅能跑满1个CPU核。如果单个分片承载的逻辑是“打开1个zip，串行遍历100万个文件、解压、读取内容”，哪怕worker配置了8核，也只有承接该分片的1个核在运行，剩余7个核完全闲置，最终就会出现整体CPU利用率仅为个位数的情况。

常见认知误区：很多开发者以为接了FlatMap把单个输入映射成多个输出，就会自动提升并行度。实际上FlatMap只是在已经被分配完成的单个分片内部做映射转换，既不会把单个分片的负载拆分给其他节点、其他CPU核，也不会主动触发动态重分片。

• 从源头将分片粒度降到最小可处理单元
  不要在FlatMap逻辑中打开zip后遍历全部100万文件、串行输出内容。正确的实现逻辑为：
  1. 先用Create生成50个zip路径构成的粗粒度集合
  2. 接入轻量FlatMap逻辑，仅执行打开zip中央目录、提取所有文件条目的操作，输出(zip存储路径, zip内单个文件名)的二元组——这一步不读取文件实际内容，仅做目录遍历
  3. 对上述步骤的输出显式添加Reshuffle()转换，强制Dataflow将所有条目打散到全局分片，最终分片总数会自动匹配集群所有worker的总CPU核数，从根本上避免负载扎堆的问题
     调整后原来的50个粗粒度分片，会拆分为50*100万 = 5000万个细粒度分片，每个分片仅负责读取zip内的单个文本文件、解析内容，Dataflow会自动将这些分片均匀分配到所有CPU核上。
• 解除不必要的静态分片调度约束
  Python版Dataflow批任务默认会对简单转换做静态分片优化，将分片粒度降到单文件级别后，需要确保动态分片调度不被关闭，避免调度器将细粒度分片重新合并回zip级别的粗粒度分片。
• 不要依赖单节点多线程提升利用率
  受GIL机制限制，在单个分片的处理逻辑中开启多线程，对解压、文本解析这类CPU密集型任务没有实际收益。只要保证总分片数大于等于集群所有worker的总核数，整体CPU利用率自然会达到接近满负载的水平。

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