Spark UI中拖后腿的Task是Input Size异常高且伴随GC overhead或Disk spill的Task；需结合Stages页Task详情、Top N JOIN键统计及小表真实体积交叉验证。
怎么看Spark UI里哪个Task在拖后腿
直接打开Spark UI的Stages页，找那个卡在99%、Input Size比其他Task高几倍甚至百倍的Task——它大概率就是倾斜点。注意别被“平均耗时”骗了：如果90%的Task在2分钟内完成，剩下两个跑了40分钟，那问题就出在这俩上。
关键指标看三个：Input Size（不是Records数）、Shuffle Read/Write、GC Time。其中Input Size异常高是第一信号；如果还伴随频繁GC overhead limit exceeded或Disk spill日志，基本坐实是倾斜而非单纯慢。
- 别只看Stage总耗时，要钻进每个Task详情页对比数值
- 如果所有Task耗时都长且接近，可能是分区数太少，不是倾斜
- 推测执行（Speculative Execution）启动的新Task也慢？那基本排除机器故障，是数据本身问题
用SQL快速揪出高频JOIN键
倾斜从来不是凭空发生的，一定是某些key被反复匹配。最直接的办法就是对JOIN字段做Top N频次统计，两表都要查。
查大表（事实表）：SELECT join_key, COUNT(*) AS cnt FROM big_table GROUP BY join_key ORDER BY cnt DESC LIMIT 20
查小表（维度表）：SELECT join_key, COUNT(*) AS cnt FROM dim_table GROUP BY join_key ORDER BY cnt DESC LIMIT 20
- 重点盯
NULL、0、-1、'unknown'这类兜底值——它们常被当成默认ID，但事实表里可能有上亿条匹配 - 如果小表里某
join_key只有一条记录，而大表里有几千万条对应它，这就是典型一对多倾斜 - 别信
COUNT(*)行数，用DESCRIBE FORMATTED table_name看TotalSize字段——STRING列多的小表可能序列化后超2GB，根本播不了
为什么EXPLAIN和PROFILE不能直接告诉你倾斜
EXPLAIN只展示逻辑计划和预估行数，不反映真实数据分布；PROFILE（如Doris或Trino）能看ProbeRows.max / avg比值，但前提是查询真跑起来了——而倾斜查询往往卡在Shuffle阶段根本出不来Profile。
真正有用的线索藏在执行中：Spark UI的Task Input Size、Fuxi Instance的Latency偏离、日志里的Disk spill。这些才是“发生了什么”，而EXPLAIN只是“本该发生什么”。
- 优化器基于统计信息估算，但如果没
ANALYZE过表，估算可能差几个数量级 -
EXPLAIN里看到BROADCAST不代表真广播成功——小表实际大小超阈值（如Spark的spark.sql.autoBroadcastJoinThreshold）就会fallback到Shuffle - Doris里
PROFILE中HASH_JOIN_OPERATOR的ProbeRows.max比avg高10倍以上，才是硬证据
别跳过验证小表真实体积这一步
很多人一上来就加盐或改SQL，结果发现还是倾斜——回头一看，小表TotalSize是1.8GB，远超Spark默认的10MB广播阈值，broadcast()根本没生效，还是走的Shuffle。
必须用DESCRIBE FORMATTED table_name（Hive/Spark）或SHOW TABLE STATUS LIKE 'table_name'（MySQL）确认物理大小，而不是依赖SELECT COUNT(*)。
- STRING列多、重复少的表，序列化膨胀很厉害；二进制或压缩列反而小
- 分区表要注意是否只查了单个分区——
DESCRIBE FORMATTED默认显示全表，得加PARTITION (dt='20261001')才准 - MaxCompute里看
size字段，Doris看DataSize，不同引擎字段名不同，别看串了
GROUP BY join_key没扫出明显高频key——那可能是NULL值没被GROUP BY聚合（需GROUPING SETS或COALESCE显式处理），也可能是小表太大导致广播失败后退化成Shuffle倾斜。这些细节漏掉一个，优化就白忙。 
