有时候倾斜是「故意」的——什么情况下不应该消除数据倾斜？

-- 日志表按日期分区，数据量随时间增长：
-- dt=2020-01: 1亿行（早期，用户少）
-- dt=2022-01: 5亿行（增长期）
-- dt=2024-01: 20亿行（成熟期，用户多）
 
-- 这是「时间维度」的倾斜，不是「key值」的倾斜
-- 区别：时间维度的倾斜不影响同一天内的查询
-- 因为通常按日期做分区裁剪，不会跨时间做全量Shuffle
 
-- 例：查今天的用户行为，分区裁剪直接定位到最新分区
SELECT user_id, COUNT(*) AS pv
FROM user_events
WHERE dt = '2024-08-01'  -- 分区裁剪，只读今天的20亿行
GROUP BY user_id;
 
-- 如果要「消除时序倾斜」，要对所有分区重新分区，代价极高
-- 而且没有意义——查询性能主要受当天分区大小影响，和历史数据分布无关
 
-- 结论：时序数据的跨时间数据量差异不需要处理
-- 要处理的是：同一天内user_id等key的倾斜（这才是真正的倾斜）

-- 场景：用户个人主页，要查一个用户的所有行为历史
-- 如果按user_id分桶（同一用户数据在同一个桶），单用户查询极快
 
CREATE TABLE user_events_bucketed
USING PARQUET
CLUSTERED BY (user_id) INTO 500 BUCKETS;  -- 按user_id分桶
 
-- 查询单个用户（只需要读1个桶，而不是全表扫描）：
SELECT event_type, event_time, event_data
FROM user_events_bucketed
WHERE user_id = 'user_001'
ORDER BY event_time DESC
LIMIT 100;
 
-- 如果有「热门用户」（如头部UP主），他的桶数据量是普通用户的1000倍
-- 这在技术上是「倾斜」，但不影响这个查询：
-- 这个Task只处理user_001的数据，不会和其他用户的数据竞争
-- 只要user_001的数据量不超过单机内存，就不会是问题
 
-- 真正需要处理的是：GROUP BY所有用户时的热门用户倾斜
-- 个人主页查询的单用户倾斜不需要处理

-- 维度表channels（1万行），必然Broadcast
-- channels表里某个channel_type='VIDEO'有9000行，占90%
-- 其他channel_type各100行
-- 这是严重的倾斜！但……
 
SELECT /*+ BROADCAST(c) */
  o.order_id, c.channel_name, c.channel_type
FROM orders o
JOIN channels c ON o.channel_id = c.channel_id;
 
-- 因为channels被广播，每个Executor都有完整的channels副本
-- 查询时在本地做Hash Join，channels的数据分布（倾斜与否）完全不影响性能
-- 不需要对channels做任何倾斜处理
 
-- 同理：物化视图/预聚合结果、配置表、字典表
-- 这些表只要确定会被Broadcast，内部如何倾斜都无所谓

判断「倾斜是否需要处理」的核心问题：这个倾斜是否影响了业务SLA？是否让作业不稳定（OOM、偶发失败）？如果都不是，先记录观察，不急于优化。过度优化是技术债的另一种形式——代码变复杂，维护成本上升，但收益很小。

「故意倾斜」的设计原则

什么时候可以接受甚至利用倾斜？总结几个原则：

# 原则1：查询模式决定分布策略
# 如果主要查询是按某个key查单个实体（单用户、单设备）：
# → 按这个key做数据聚集（分桶），接受分布不均
# 如果主要查询是全量聚合（GROUP BY所有用户）：
# → 追求均匀分布，消除倾斜
 
# 原则2：广播表不需要关注倾斜
# 任何确定会被Broadcast的表，内部分布无关紧要
 
# 原则3：时序数据关注「时间段内」的均匀性，而非「跨时间」均匀性
# 按天分区的表，不同天数据量不同是正常的（时序倾斜）
# 真正要处理的是同一天内key值的倾斜（业务倾斜）
 
# 原则4：倾斜的代价 < 消除倾斜的成本时，接受倾斜
# 倾斜让作业慢20分钟，但消除倾斜需要引入复杂的两阶段聚合
# 增加10%的代码复杂度和维护成本，且作业还在SLA内
# → 这种情况接受倾斜，记录技术债，择机优化
 
# 原则5：写入频繁的实时流，小批次写入必然产生小文件/小分区
# Flink以10秒为单位写入，每10秒一个小文件，这是「时序倾斜」的另一种形态
# 用Compaction定期合并，而不是试图让每次写入都是大文件

面试高频追问

追问一：你说的「查询模式决定分布策略」，在实际工作中怎么做到？

在数仓设计阶段做「查询分析」：把未来6个月最高频的20个查询列出来，分析它们的JOIN key、GROUP BY key、过滤条件。高频查询的key优先考虑作为分桶key或分区key。这个分析可以从历史的SQL日志里挖掘（哪些列被频繁用在WHERE/JOIN/GROUP BY里），也可以直接和业务方对齐（他们最关心什么维度的分析）。在某出海硬件品牌，我在建表前和业务方开了一个1小时的「查询需求收集会」，收集了15个高频查询，最终的分桶key选择让这15个查询中的12个不再有倾斜问题，另外3个需要在查询时处理，比不做分析直接随便选key效果好太多。

追问二：Spark的AQE在「不需要消除倾斜」的场景里，会不会误触发，带来额外开销？

AQE的倾斜处理有两个阈值条件（最大分区 > 中位数 × factor 且 > 最小字节数），两个条件都满足才触发。如果倾斜不严重（比值<5倍），AQE不会触发，没有额外开销。如果是「故意倾斜」（如按user_id聚集的分桶查询），单用户查询的Task只读一个桶，数据量可能是其他Task的100倍，触发AQE的倾斜处理。但AQE的处理（拆分大分区）对于单用户查询其实没有意义——因为拆分后需要复制对应侧数据，反而增加了网络开销。这种场景可以局部禁用AQE的倾斜处理：SET spark.sql.adaptive.skewJoin.enabled=false（只禁用倾斜Join，保留其他AQE功能）。这是个细节，知道的候选人非常少。

追问三：「过度优化」在实际工程里有哪些表现？怎么避免？

过度优化的典型表现：1）把没有性能问题的作业加了两阶段聚合，代码变复杂，维护成本上升；2）把所有表都广播（即使不需要），导致内存压力增大，反而触发GC；3）把分区设计得过于细粒度（按小时+渠道+国家），产生大量小文件，meta服务压力大；4）为了「优雅」而过度工程化，比如用广播流动态维护热点key列表，但热点key其实很少变化，写一个固定过滤条件更简单。避免过度优化的方法：先测量（Profile before optimize）——没有Profiling数据就不要优化；以SLA为目标，满足SLA即可，不追求极致最快；优化方案选「最简单可以解决问题的」，而不是「最技术高深的」。

实战：我用「故意倾斜」解决了一个性能问题

我在某短剧出海公司处理广告归因数据时，有一个按广告素材（creative_id）聚合的查询，统计每个素材的各项指标。这个查询有一个特点：业务方只关心TOP 100的素材，长尾的几万个素材基本没人看。

-- 业务需求：统计每个广告素材的曝光、点击、转化
-- 按performance降序，只取TOP 100
SELECT
  creative_id,
  SUM(exposure) AS total_exposure,
  SUM(click) AS total_click,
  SUM(conversion) AS total_conversion
FROM ad_events
WHERE dt = '2024-08-01'
GROUP BY creative_id
ORDER BY total_exposure DESC
LIMIT 100;
 
-- 原始问题：某几个爆款素材曝光量极大，GROUP BY倾斜，作业20分钟
-- 我的做法（故意倾斜 + 提前过滤）：
 
-- 先对TOP素材做单独统计（不打散，让它们自然倾斜在单个Task里）
-- 因为TOP 100素材虽然数据多，但我只需要它们的汇总结果
-- 单个Task处理单个素材的所有数据，用内存做聚合，完全可以承受
 
-- 关键洞察：如果只要TOP 100，可以先过滤出TOP素材的ID，
-- 再对这些ID的数据做精确聚合，避免扫描和聚合全量数据
WITH top_creatives AS (
  -- 先快速估算TOP 100（TABLESAMPLE采样，速度极快）
  SELECT creative_id
  FROM ad_events TABLESAMPLE(1 PERCENT)  -- 只采样1%
  WHERE dt = '2024-08-01'
  GROUP BY creative_id
  ORDER BY COUNT(*) DESC
  LIMIT 200  -- 多取一些，避免采样误差导致漏掉真实TOP
)
-- 再对候选TOP素材做精确统计
SELECT
  e.creative_id,
  SUM(e.exposure) AS total_exposure,
  SUM(e.click) AS total_click,
  SUM(e.conversion) AS total_conversion
FROM ad_events e
JOIN top_creatives t ON e.creative_id = t.creative_id  -- 只处理TOP 200素材
WHERE e.dt = '2024-08-01'
GROUP BY e.creative_id
ORDER BY total_exposure DESC
LIMIT 100;
-- 优化后：从全量2亿行聚合 → 只聚合TOP 200素材的数据（约200万行）
-- 查询时间从20分钟降到45秒，数据量减少了100倍

关键洞察：当业务只关心TOP N时，不需要对全量数据做精确聚合。先采样快速找到候选TOP，再对候选做精确计算，这是「故意倾斜+业务简化」的组合——让TOP素材的数据「倾斜」集中到几个Task，每个Task单独做聚合，反而是最优方案。这个思路来自业务理解，不是纯技术优化。

总结

倾斜不等于问题，问题在于倾斜是否导致了性能瓶颈或业务影响。「故意倾斜」在三类场景里是最优设计：按主体聚集存储（提升局部查询性能）、广播表内部分布无关紧要、时序数据的跨时间数据量差异。优化决策要以SLA为目标，选「最简单解决问题的方案」，而不是追求极致均匀。面试时能说出「什么情况下不需要消除倾斜」，展示了比普通候选人更全面的工程思维，这是区分3年和5年经验的分水岭。

数据倾斜通关手册第11-15篇完结！下一步是总结篇：20道题快速查阅表 + 面试备战指南，帮你在面试前30分钟快速刷完核心要点。

这15篇里，你觉得哪道题最有用？哪道题最难说清楚？评论区告诉我，我来针对性地出更多内容～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长

数据倾斜

面试通关手册

第16-20篇（完结篇）：手写SQL · 数据规模 · 实时链路 · 数据类型 · 架构设计

Wood聊大数据

9年大数据老兵，聊技术、聊职场、聊成长

面试杀手题🔥🔥 | 完结篇 | 架构级思维