大数据分析中工具：Spark任务卡在99%不动，UI上只有一个task在疯狂燃烧CPU、其余task秒跑，这种数据倾斜到底该先加盐还是先过滤掉那些user_id=0的默认值key？

一、现象解剖：99%卡顿背后的执行模型真相

要回答“先加盐还是先过滤”，必须先弄清楚“卡在99%”这个现象到底在物理层面意味着什么。Spark UI上进度条停在99%，本质上是Stage内已完成Task数与总Task数的比值，而剩余那1%的Task正是承载了倾斜Key的“长尾任务”。此时其余Task早已结束，Executor资源被这一个Task独占，CPU持续满载——这不是“任务没跑完”，而是“任务在等一个不可能快速跑完的分区”。

1.1 Shuffle是倾斜的温床

数据倾斜几乎总发生在Shuffle环节。groupByKey、reduceByKey、join、distinct等算子都需要按Key将数据重新分发到不同分区。Spark默认使用HashPartitioner，即partitionId = hash(key) % numPartitions。当某个Key的记录数远超其他Key时，哈希取模后它仍会整体落入某一个分区，形成“一个分区扛下半个数据集”的局面。本文评述：HashPartitioner的设计前提是“Key分布近似均匀”，而真实业务数据几乎从不满足这一前提，因此倾斜不是异常，而是默认配置下的必然结果。

1.2 为什么“只有一个task在烧CPU”

从调度视角看，Spark的Task是Stage内最小并行单位。一个Stage有N个Task，对应N个分区。倾斜Key所在分区数据量可能是其他分区的几十上百倍，处理时间也成比例拉长。其余N-1个Task完成后，调度器仍要等待最后一个Task，整个Stage无法提交，下游Stage无法启动，作业进度条自然卡在接近100%的位置。此时如果观察Executor线程栈，会发现该Task正深陷在ExternalSorter的溢写或UnsafeExternalSorter的排序中，甚至触发频繁GC。

典型误判：很多同学看到“99%”第一反应是“网络慢”或“磁盘慢”，于是去调spark.shuffle.io.maxRetries、加大内存。这些操作往往无效，因为瓶颈不在IO重试，而在单分区数据量本身。

1.3 一个直观的量化模型

设总记录数为M，分区数为P，倾斜Key记录数为M_skew。理想情况下每分区处理M/P条；倾斜分区处理M_skew条。倾斜放大倍数约为(Mskew × P) / M。举例（模拟数据，用于说明量级）：M=10亿，P=200，M_skew=3亿，则放大倍数≈60倍。这意味着原本1分钟的分区要跑1小时，其余199个分区1分钟跑完——进度条自然停在99.5%。

表1：倾斜Stage与正常Stage的观测特征对比（基于Spark UI与事件日志的通用判据整理）

二、诊断先行：如何科学判定“是不是真倾斜”

在动手加盐或过滤之前，必须先完成诊断。笔者反复强调一个观点：没有诊断的调优都是赌博。诊断要回答三个问题：倾斜发生在哪个Stage？倾斜Key是谁？这个Key的业务语义是什么？

2.1 从Spark UI定位Stage

打开Spark UI的Stages页，按“Duration”排序，找到耗时最长的Stage；进入该Stage的“Summary Metrics”，看Shuffle Read Size的Max与Median比值。经验阈值：Max/Median > 3 即可怀疑倾斜，> 10 基本确诊（该阈值来自社区实践总结，非官方标准）。再点进Task列表，按Shuffle Read Size降序，排第一的Task所在分区就是倾斜分区。

2.2 用代码量化Key分布

UI只能看到分区级，要定位到具体Key，需要采样统计。下面这段代码是笔者常用的“倾斜Key探针”：

// 采样1%数据，统计Top-N Key的占比（Scala）
val sample = df.sample(false, 0.01)
val total  = sample.count()
val topKeys = sample
  .groupBy("user_id")
  .count()
  .orderBy(desc("count"))
  .limit(20)
  .collect()

topKeys.foreach { r =>
  val ratio = r.getLong(1).toDouble / total
  println(s"key=${r.get(0)}  count=${r.getLong(1)}  ratio=${"%.4f".format(ratio)}")
}

如果Top1 Key占比超过5%～10%，且分区数较多，就足以造成明显长尾。本文评述：采样比例需结合数据量调整，数据量小时可全量统计；采样虽快，但对超低频但绝对量大的Key可能低估，建议采样与UI分区指标交叉验证。

2.3 语义诊断：Key的“合法性”判断

这是全文主线的关键一步。定位到倾斜Key后，不要急着加盐，先问：这个Key在业务上是否应该存在？常见情形有三类：

• ① 默认值/脏值Key：如user_id=0、user_id=-1、null、空字符串。它们代表“未登录”“埋点缺失”“ETL默认填充”，业务上通常不参与用户维度分析。
• ② 真实热点Key：如头部主播、爆款商品、系统账号。业务上合法，不能删，只能打散。
• ③ 分布性长尾：没有单一超大Key，但整体分布极度不均。此时加盐和过滤都不是首选，应考虑分区策略或AQE。

三、核心辨析：加盐与过滤的语义分野

3.1 加盐（Salting）的本质

加盐是在Key上拼接随机前缀（或后缀），把一个逻辑Key人为拆成N个物理Key，使原本落入同一分区的数据分散到多个分区并行处理，聚合后再“去盐”合并。经典两阶段聚合模式：

// 阶段一：加盐局部聚合
val saltN = 10
val salted = df.withColumn("salt", (rand() * saltN).cast("int"))
               .withColumn("salted_key", concat(col("user_id"), lit("_"), col("salt")))
val partial = salted.groupBy("salted_key").agg(sum("amount").as("partial_sum"))

// 阶段二：去盐全局聚合
val result = partial
  .withColumn("user_id", split(col("salted_key"), "_")(0))
  .groupBy("user_id").agg(sum("partial_sum").as("total"))

加盐的代价是：多一次Shuffle、代码侵入性强、对join场景需要两侧配合（大表加盐、小表膨胀）。本文评述：加盐是“用计算换均衡”的暴力美学，它不减少数据量，只是把长尾摊平，因此当倾斜Key本身是无效数据时，加盐等于“花大力气处理垃圾”，这是不经济的。

3.2 过滤的本质

过滤是在Shuffle之前用filter或where剔除无效Key，直接减少参与Shuffle的数据量。它是最廉价、最彻底的治理手段——数据不进入Shuffle，倾斜自然消失。但过滤有严格前提：被过滤的数据对下游结果无贡献，或可被单独旁路处理。

3.3 两者对比

表2：加盐与过滤的工程特性对比（笔者根据实践归纳）

四、决策主线：先过滤还是先加盐的判定树

把前面的分析收敛成一条可执行的决策主线。笔者将其概括为“一判语义、二看占比、三选手段”三步法。

4.1 三步判定流程

1. 第一步·判语义：倾斜Key是否为默认值/脏值？是→优先过滤或旁路；否→进入第二步。
2. 第二步·看占比与场景：若为真实热点，评估其占比与算子类型。聚合类→两阶段聚合/加盐；join类→优先AQE Skew Join，其次加盐+小表膨胀。
3. 第三步·选手段并验证：优先使用Spark 3.x内置AQE（零代码侵入），无效再手工加盐；过滤必须做数据对账，确保下游指标不偏差。

4.2 判定树（文字版）

本文评述：这条决策树的价值在于把“技术选择题”还原为“业务语义题”。很多团队争论加盐还是过滤，本质是没人去确认user_id=0到底该不该进报表。先对齐语义，技术方案自然收敛。

五、加盐工程化：从手工到AQE Skew Join

5.1 手工加盐的适用边界

手工加盐适合：Spark版本较低（<3.0）、倾斜Key明确且数量少、聚合逻辑可拆两阶段。它的坑在于：盐粒度过小无效、过大导致小文件与调度开销；join场景需两侧同步处理，容易写错导致结果膨胀。笔者建议盐粒度N取“倾斜分区数据量 / 平均分区数据量”向上取整，并做压测验证。

5.2 AQE Skew Join：零侵入首选

Spark 3.0引入AQE（Adaptive Query Execution），3.2起对Skew Join的支持趋于成熟。核心参数：

spark.sql.adaptive.enabled=true
spark.sql.adaptive.skewJoin.enabled=true
spark.sql.adaptive.skewJoin.skewedPartitionFactor=5
spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes=256MB
spark.sql.adaptive.coalescePartitions.enabled=true

其原理是：Shuffle Write阶段统计各分区大小，运行期发现某分区超过“中位数×factor”且超过阈值，就把该分区再拆分给多个Task处理。本文评述：AQE把“运行期统计+动态拆分”做进了引擎，是对手工加盐的一次工程化收编。但它对“Map端聚合已把数据压扁”的场景效果有限，且阈值需按集群规格调优，不能开箱即用。

5.3 加盐的正确性校验

加盐后必须做对账：对比加盐前后总记录数、聚合总值、去重计数。任何一项不一致，说明去盐逻辑或盐字段处理有误。建议把对账SQL固化为回归用例。

六、过滤工程化：默认值Key的治理范式

6.1 过滤不是“删了就行”

直接filter("user_id != 0")看似简单，但会带来两个隐患：一是下游口径变化无人知晓，报表数字突然下降；二是默认值数据本身可能含有效信息（如未登录用户的浏览行为对推荐仍有价值）。笔者推荐“隔离而非删除”的范式：把默认值Key数据分流到旁路表，主链路只处理有效Key，旁路表供审计与特定分析使用。

// 隔离范式：一次读取，双路输出
val base = spark.read.parquet("/warehouse/access_log")
val (valid, invalid) = (base.filter(col("user_id") =!= 0),
                        base.filter(col("user_id") === 0))
valid.write.mode("overwrite").parquet("/warehouse/access_log_valid")
invalid.write.mode("overwrite").parquet("/warehouse/access_log_default_key")

6.2 上游治理才是根治

默认值Key大量出现，往往源于埋点SDK未登录时填0、ETL关联失败填默认值。在下游反复过滤是治标，推动上游用null或独立字段表达“未知”，并在数仓分层中明确“默认值Key不进入用户维表”，才是治本。本文评述：倾斜治理的最高境界是让倾斜Key根本不产生，这需要数据治理与计算引擎协同，而非DBA单打独斗。

七、组合拳：两阶段聚合与动态方案

真实生产很少只用一招。笔者总结的“组合拳”顺序是：先过滤无效Key → 再开AQE → 仍倾斜则两阶段聚合/加盐 → 最后考虑拆分热点单独处理。这个顺序遵循“成本从低到高、侵入从浅到深”的原则。

7.1 两阶段聚合模板

两阶段聚合是加盐的“温和版”：先按(Key, 随机前缀)局部聚合，再按Key全局聚合。它比纯加盐少一次全量Shuffle，适合reduceByKey类场景。注意局部聚合的聚合函数必须可结合（如sum、max），不可结合的函数（如collect_list）需改用其他策略。

7.2 动态方案：让引擎自己选

Spark 3.2+的AQE已能在运行期根据统计信息选择join策略（广播/排序合并/skew拆分）。工程上应优先把spark.sql.adaptive.*系列参数调好，把手工加盐作为兜底。本文评述：未来倾斜治理的趋势是“声明式”——用户只描述业务意图，引擎自适应选择物理计划，手工加盐会逐渐退居为教学与极端场景手段。

八、实战复盘：一个电商日志倾斜案例

以下为笔者参与过的一个脱敏案例（数据为模拟整合，仅用于说明方法）。某电商用户行为日志日增约8亿条，按user_id聚合计算人均浏览时长，作业长期卡在99%。

8.1 诊断结果

• Spark UI：Stage 7 的 Shuffle Read Max/Median ≈ 42；
• 采样统计：user_id=0 占全量约 18%，为未登录埋点；
• 业务确认：人均时长报表只统计登录用户，默认值Key不应进入。

8.2 处置步骤

1. 上游埋点改造：未登录写null，并新增is_login字段（长期治本）；
2. 过渡期：主链路过滤user_id=0并写入旁路表（治标且可审计）；
3. 开启AQE Skew Join兜底，防止其他热点Key复发；
4. 对账：过滤前后登录用户总数一致，报表指标无偏差。

结果（模拟数据）：Stage耗时从约52分钟降至约6分钟，长尾Task消失。本文评述：这个案例的关键转折不在技术，而在“业务确认默认值Key不该进报表”这一步——它直接让“加盐还是过滤”的争论失去意义。

九、前沿预判：倾斜治理的学术演进方向

从学术与工业界动态看，数据倾斜治理正沿三条线演进：一是运行期自适应，以AQE为代表，用统计信息驱动物理计划重优化；二是学习型优化器，利用历史执行计划与代价模型预测倾斜并预分配资源；三是存算协同，在数据写入时即做分桶/分区设计，从源头规避倾斜。本文评述：无论技术如何演进，“先判语义再选手段”的分析主线不会过时——引擎再智能，也无法替业务判断一个Key该不该存在。

对工程团队而言，当下最务实的动作是：升级到Spark 3.3+、打开AQE全套参数、建立倾斜监控看板（Max/Median比值告警）、把默认值Key治理纳入数据质量规则。这些动作的投入产出比远高于手写加盐。

十、结论与操作清单

拓展阅读（教程与视频，供动手练习）：

• Apache Spark 官方 SQL Performance Tuning（AQE 与 Skew Join 参数说明）
• Spark Web UI 官方指南（Stages/Task 指标解读）
• Databricks 博客：Adaptive Query Execution 原理
• B站：Spark 数据倾斜实战讲解（社区教程，供参考）