Dask单大文件词统计集群扩容后性能不佳问题排查

扩容后耗时上升、CPU利用率处于低位是典型的数据传输/IO开销远超多节点计算收益的表现，具体影响因素如下：

• 数据读取阶段本地性完全失效，IO开销陡增
  虽然你已经将10GB单文件同步到所有节点可访问路径，但Dask默认调度逻辑不会感知各节点的本地文件副本状态：
  • 若file_url指向某单个节点的本地文件系统路径，所有worker的读取任务都会跨网卡从该节点拉取数据。单节点运行时读取全程走本地盘，无任何网络开销；3节点场景下会产生多份跨网读取流量，很容易打满千兆网卡，所有计算任务都在等待数据传输，CPU自然处于低负载状态。
  • 若file_url指向NFS类单点共享存储，多节点会同时争抢存储带宽，相比单节点独占带宽的场景，读取效率会出现明显下降。
  • 未预切分的单个大文件在读取时，Dask需要额外做字节偏移到行首的对齐操作，也会带来额外的读取开销。
• 全局Shuffle的网络开销抵消了多节点并行收益
  代码中value_counts()是全局分组聚合操作，会触发全量数据Shuffle：split+explode产出的20亿个词（中间数据量远大于原始10GB），需要按照词的哈希值路由到指定节点做最终计数。
  单节点运行时Shuffle是进程内内存操作，额外开销极低；3节点集群下，几十GB的中间数据需要经过序列化、跨网传输、反序列化流程，普通千兆网卡传输这些数据就需要数分钟，而分词、计数本身的计算量极轻，多节点带来的并行计算收益完全覆盖不了额外的网络传输成本，最终表现为扩容后耗时更长。
• 默认配置不匹配场景，导致资源空转
  • 分区数不足：Dask读取单CSV默认块大小为64MB，10GB文件仅切分约160个分区，经过explode后单分区数据量大幅膨胀，Shuffle阶段任务粒度过粗，容易出现部分worker空等数据、部分worker卡在传输的情况，CPU无法被充分利用。
  • Shuffle落盘开销：如果worker内存不足以容纳全量中间词数据，Dask会自动将中间数据溢出到磁盘，若使用机械盘，随机IO性能极差，大部分时间会耗在磁盘等待上，CPU利用率持续走低。
  • 无位置感知调度：默认调度策略不会优先将数据块对应的计算任务分配到存储该块的节点，进一步放大了跨网传输的开销。

可通过Dask内置的诊断面板查看任务时间线，若绝大多数任务块处于等待数据传输状态、而非计算状态，即可确认是上述瓶颈导致。

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