Azure Databricks集群存储200亿行数据集性能瓶颈排查及优化咨询

一、CPU分析中"wait"的含义 #

这里的wait指iowait（I/O等待时间占比），即CPU处于空闲状态但被I/O操作阻塞的时间占总CPU时间的比例。在你的场景中，43.4%的占比说明集群核心瓶颈是I/O：Worker节点的CPU大部分时间在等待数据读写（比如云存储传输、磁盘IO）完成，无法执行计算任务。

二、加速存储进程的具体措施 #

• 切换高效存储格式与压缩：采用Parquet/ORC列存格式替代行存格式，配合Snappy或ZSTD压缩算法，大幅降低数据体积和I/O传输量；Photon对这些格式的读写有原生优化，能进一步放大收益。
• 优化数据分区与并行度：针对200亿行数据，按业务维度（如时间、地域）合理分区，避免小文件泛滥或超大文件；调整spark.sql.shuffle.partitions（建议设置为Worker核数的2-3倍）和spark.sql.files.maxPartitionBytes，让每个Task处理的数据量匹配Worker的CPU/内存资源。
• 云存储层优化：如果使用ADLS Gen2，开启分层命名空间并选用高级性能存储层；启用Databricks存储缓存（spark.databricks.io.cache.enabled=true），减少重复读写远程存储的开销；利用Worker节点的实例存储（Ephemeral Disk）作为临时存储，降低对远程存储的依赖。
• 扩容或升级节点配置：当前4个Worker节点可适当扩容，或更换为高I/O性能的实例类型（如Azure Lsv2系列）；剩余100GB内存可调整内存缓存参数（spark.sql.inMemoryColumnarStorage.batchSize），优化内存缓存命中率，减少磁盘I/O。
• 优化写入逻辑：避免使用coalesce强制合并小文件（易导致单节点瓶颈），优先用repartition保证数据均匀分布；如果是增量场景，使用Delta Lake的Merge操作替代全量覆盖，减少不必要的I/O。

三、额外可分析的优化维度 #

• 数据倾斜排查：查看Spark UI的Task执行时间分布，确认是否存在少数Task耗时远超平均值的情况，检查分区键是否存在热点值导致数据集中在少数节点。
• 存储端监控分析：查看云存储的监控指标（如ADLS的请求延迟、吞吐量、限流次数），确认是否是存储端带宽不足或限流导致的I/O等待。
• Spark作业细节分析：在Spark UI中查看Stage的Shuffle读写耗时、Task的I/O时间占比，排查是否是Shuffle过程中的磁盘I/O瓶颈；查看GC日志，确认是否存在频繁GC导致的隐性性能损耗（即使剩余内存充足，内存分配不合理也可能引发问题）。
• Photon有效性验证：检查Spark UI中是否有Photon任务标记，确认代码中使用了Photon支持的操作和存储格式（如Parquet/Delta Lake），避免因配置或代码问题导致Photon未实际生效。

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