Apache Spark Shuffle Read Blocked Time过长原因及集群瓶颈分析问询

可能的诱因 #

• 数据倾斜：优先核对对应Stage各Task的Shuffle Read数据量，若少数Task读取的数据量超出平均水平10倍及以上，倾斜Task需要拉取、处理的数据量远超负载能力，会频繁触发拉取重试、内存溢出降级，直接拉高阻塞时长。
• 网络层瓶颈：8节点集群Shuffle数据跨节点拉取依赖集群网络，若节点间存在丢包、重传，或者网卡带宽被打满（千兆网卡满负载下传输速率仅为100MB/s左右），拉取请求会长期处于等待响应状态，阻塞时长会线性上升。
• 内存配置不匹配：总内存880GB的集群若Executor堆内/堆外内存分配不足，或spark.shuffle.memoryFraction配置过低，Shuffle Read拉取的数据无法完全存入内存，会频繁触发溢写磁盘、Full GC，拉取线程会被长期阻塞。
• Shuffle服务能力不足：Standalone模式下默认spark.shuffle.io.serverThreads为节点核数的2倍，224核集群若未调整该参数，单节点处理Shuffle拉取请求的线程数不足，大量请求排队会直接导致拉取端阻塞；若spark.reducer.maxSizeInFlight设置过大，单次拉取的数据量超出接收端内存上限，也会触发强制等待。
• 磁盘IO饱和：检查Shuffle数据存储节点的磁盘IO利用率、iowait指标，若磁盘负载长期高于80%，或存在坏盘、磁盘读写速率不足的情况，Shuffle服务读取本地Shuffle文件的耗时过长，会直接传导为拉取端的Blocked Time。

该场景下的潜在瓶颈点 #

• 224核总核心的集群若Task并发数设置不合理：Task数远小于224会导致资源闲置，拉取效率不足；Task数过大会产生大量细碎Shuffle块，拉取请求的开销被指数级放大。
• 880GB总内存若未预留足够的系统内存给OS PageCache，Shuffle文件读取无法利用缓存，每次读取都需要访问磁盘，会大幅降低Shuffle服务的响应速度。
• 若未开启外部Shuffle服务，Executor退出后会导致Shuffle文件不可用，触发重复计算，变相拉长Shuffle Read的阻塞时长。

排查验证路径 #

1. 查看已完成任务的Task Metrics汇总，对比各Task的Shuffle Read字节数、GC时长、本地/远程拉取占比，优先排除数据倾斜问题
2. 查看Executor维度聚合指标，确认阻塞时长是否集中在部分节点的Executor上，定位问题节点后排查对应节点的网络、磁盘、CPU负载
3. 核对作业配置，重点校验spark.executor.memory、spark.shuffle.io.serverThreads、spark.reducer.maxSizeInFlight、spark.shuffle.file.buffer等参数是否适配集群规格
4. 查看Stage完整DAG，确认上游Shuffle Write阶段是否存在文件生成过慢、文件碎片化问题

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