Spark与MapReduce任务卡在99%的深度排查与优化实践

1. Spark任务卡在99%的深度排查与解决方案

在大规模数据处理场景中，Spark任务卡在99%是最令人抓狂的问题之一。作为经历过数百次生产环境调优的老手，我将分享一套完整的诊断方法论和实战技巧。

1.1 现象特征与本质分析

当Spark任务卡在99%时，通常会在UI上呈现两种典型模式：

1. DAG停滞型：最后一个Stage显示部分Task（通常1-2个）长时间处于Running状态，其他Task早已完成。这种情况占我遇到的案例的70%以上。

2. 资源死锁型：整个Stage无法提交，Tasks列表显示Pending状态。这种情况往往伴随集群资源管理器（如YARN）的告警。

关键观察点：通过Spark History Server的Event Timeline视图，可以清晰看到任务卡住的时间点与前后事件序列。我习惯先看这里再深入细节。

1.2 数据倾斜的根治方案

数据倾斜是导致Task卡顿的头号杀手。不同于简单的参数调整，根治倾斜需要系统化的方法：

1.2.1 倾斜诊断三板斧

1. Shuffle流量分析：

bash复制# 通过Spark Metrics获取Shuffle数据分布
curl http://driver-node:4040/metrics | grep "shuffle.read.records"

2. Stage重放法：

scala复制// 对卡住的Stage单独提取数据验证
val skewedStage = spark.sparkContext.statusTracker.getStageInfo(stageId)
skewedStage.rdd.partitions.map(_.size).toSeq.sorted.reverse.take(5)

3. 采样分析法：

sql复制-- 对疑似倾斜的Key进行分布统计
SELECT skew_key, COUNT(*) as cnt 
FROM source_table 
GROUP BY skew_key 
ORDER BY cnt DESC LIMIT 10;

1.2.2 高级倾斜处理技巧

• 动态分桶技术：对热点Key自动进行二次哈希

scala复制val skewedKeys = Seq("hot_key1", "hot_key2") // 识别出的热点Key
df.withColumn("salt", when(col("key").isin(skewedKeys:_*), 
                  floor(rand() * 10)).otherwise(lit(0)))
  .groupBy(col("key"), col("salt"))
  .agg(sum("value").as("partial_sum"))
  .groupBy("key")
  .agg(sum("partial_sum").as("total_sum"))

• 倾斜感知Join优化（