百GB和百TB的倾斜，处理方案有什么不同？数据规模对选型的影响

-- 百GB量级的典型场景（早期短视频平台，我的第一份工作）
-- 事实表：用户行为日志，每天约50GB（5亿行）
-- 维度表：用户画像表，约800MB（800万用户）
-- 维度表：内容表，约200MB（200万内容）
 
-- 分析：800MB的用户画像表能广播吗？
-- 集群：20个Executor，每个8GB内存
-- 800MB × 20个Executor = 16GB集群内存占用
-- Executor内存8GB × 20 = 160GB总内存
-- 16GB / 160GB = 10%，安全！
 
SET spark.sql.autoBroadcastJoinThreshold = 838860800;  -- 800MB
 
SELECT /*+ BROADCAST(u), BROADCAST(c) */
  b.user_id,
  u.age_group,
  u.city,
  c.content_type,
  COUNT(*) AS play_cnt
FROM user_behavior b
JOIN user_profile u ON b.user_id = u.user_id  -- 800MB，广播
JOIN content_info c ON b.content_id = c.content_id  -- 200MB，广播
WHERE b.dt = '2018-06-01'
GROUP BY b.user_id, u.age_group, u.city, c.content_type;
-- 百GB量级，Broadcast解决JOIN倾斜，作业10分钟内完成

-- TB量级的典型场景（某出海硬件品牌，迁移后规模）
-- 事实表：设备行为日志，每天约800GB（80亿行）
-- 维度表：设备型号表，约5GB（500万型号）
-- 维度表：用户账号表，约20GB（2000万用户）
 
-- 问题：5GB的设备型号表，能广播吗？
-- 50个Executor × 5GB = 250GB集群内存占用
-- 已经超过单个Executor 8GB内存的60%！不能广播
 
-- TB量级的处理策略：
-- 1. 维度表提前聚合压缩，只保留需要的列
SELECT /*+ BROADCAST(m_slim) */
  e.device_id,
  m_slim.model_name,
  COUNT(*) AS event_cnt
FROM device_events e
JOIN (
  -- 只选需要的2列，从5GB压缩到约200MB，可以广播！
  SELECT device_model_id, model_name
  FROM device_model_info
) m_slim ON e.device_model_id = m_slim.device_model_id
WHERE e.dt = '2023-06-01'
GROUP BY e.device_id, m_slim.model_name;
 
-- 2. 用户账号表（20GB）：裁剪列后约2GB，可广播
-- 或者：两张大表改用分桶表，利用Bucket Join避免Shuffle

-- TB量级：分桶设计避免大表Shuffle Join
-- 提前建好分桶表（ETL写入时就分桶）：
CREATE TABLE device_events_bucketed
USING DELTA
CLUSTERED BY (device_id) INTO 500 BUCKETS;  -- 500桶，每桶约1.6GB
 
CREATE TABLE device_profile_bucketed
USING DELTA
CLUSTERED BY (device_id) INTO 500 BUCKETS;  -- 必须和上面桶数相同
 
-- 查询时Bucket Join，无Shuffle：
SET spark.sql.sources.bucketing.enabled = true;
SELECT e.device_id, p.country, COUNT(*) AS event_cnt
FROM device_events_bucketed e
JOIN device_profile_bucketed p ON e.device_id = p.device_id
WHERE e.dt = '2023-06-01'
GROUP BY e.device_id, p.country;
-- TB量级Bucket Join：比Shuffle Join快3-5倍

十TB量级及以上：预聚合是核心，明细表能不碰就不碰

十TB及以上量级，从架构层面就要减少对原始明细数据的直接查询。每次查询对原始明细做大规模Shuffle，哪怕倾斜处理得再好，也架不住数据量本身带来的IO和网络开销：

数据量级	典型规模	主要倾斜挑战	优先解法	架构重点
百GB	1-500GB/天	热点维度JOIN	Broadcast	Executor内存调优
TB	0.5-10TB/天	维度表过大无法广播，大表Shuffle	分桶设计，列裁剪后广播	分桶表设计
十TB	10-100TB/天	明细表查询IO开销极大，任何Shuffle代价高	DWS预聚合，减少明细查询	分层数仓，DWS设计
百TB以上	>100TB/天	单次任务规模超出集群能力	分批处理，数据分治	分区裁剪，时间切片

-- 十TB量级的正确姿势：DWS层预聚合，ADS层不碰明细
 
-- ODS/DWD层：原始明细，10TB/天，尽量少直接查询
-- dwd_ad_exposure: 100亿行/天，每行约100字节 = 1TB/天
 
-- DWS层（每天凌晨跑一次，把明细聚合到DWS）：
INSERT OVERWRITE dws_ad_daily_stats PARTITION(dt='2024-08-01')
SELECT
  ad_id,
  channel_id,
  country,
  SUM(exposure)    AS total_exposure,
  SUM(click)       AS total_click,
  SUM(revenue)     AS total_revenue,
  COUNT(DISTINCT user_id) AS uv  -- 只在DWS层做一次COUNT(DISTINCT)
FROM dwd_ad_exposure
WHERE dt = '2024-08-01'
GROUP BY ad_id, channel_id, country;
-- DWS表：从100亿行 → 约100万行（广告数×渠道数×国家数），压缩100倍
 
-- ADS层查询直接读DWS（无倾斜风险，数据量小）：
SELECT channel_id, SUM(total_revenue) AS channel_revenue
FROM dws_ad_daily_stats
WHERE dt = '2024-08-01'
GROUP BY channel_id;
-- ADS查询：从100万行聚合，秒级完成，完全没有倾斜问题

面试高频追问

追问一：你说TB量级用分桶，分桶数怎么决定？500桶的依据是什么？

分桶数的计算公式：目标是每个桶的数据量在128MB-1GB之间（和HDFS Block大小和Spark Task处理能力匹配）。计算方法：数据总量 ÷ 目标每桶大小 = 桶数。上面的例子：800GB ÷ 1.6GB/桶 ≈ 500桶。更精确的方法：先跑一次全表扫描统计总行数和平均行大小，再计算桶数。分桶数通常选2的幂次（128、256、512）或者质数（499、503），避免哈希冲突导致数据不均匀。另外桶数一旦确定，很难修改（需要重建表），所以宁可多选一点（比如800桶），后续合并桶比分裂桶容易得多。

追问二：十TB量级的DWS预聚合，如果COUNT(DISTINCT)的UV需要精确计算，DWS里能存吗？

精确UV在DWS层有两个方案：1）用Bitmap存储：把user_id写入Bitmap（RoaringBitmap），DWS里存Bitmap对象，查询时用bitmap_count()取精确UV，支持跨时间段的UNION操作（Bitmap OR），非常高效。Doris/StarRocks原生支持BITMAP类型；2）用HyperLogLog（HLL）：误差1-5%，但存储极省，查询极快，适合大盘趋势分析（不需要精确到个位数）。实际上精确UV和近似UV两种都存：精确结算场景用Bitmap，趋势分析用HLL。我在某短剧出海公司用Hologres，就是两种都存的方案，按场景选用。

追问三：数据量从TB增长到十TB，除了倾斜问题，还有哪些架构层面要升级？

数据量级跃升时，倾斜只是冰山一角，整个架构要系统性升级：1）存储：HDFS扩容或上云（S3/OSS），单机NameNode升级为HA，Block大小从128MB调到256MB减少NameNode压力；2）计算：Executor内存和CPU配比调整，并行度从数百到数千，shuffle.partitions对应增大；3）调度：任务依赖图变复杂，需要引入精细的优先级控制，防止资源争抢；4）数据质量：数据量大后数据质量问题被放大，需要更完善的校验和监控；5）成本：十TB量级的存储和计算成本显著上升，需要引入存储分层（热温冷）和计算资源弹性伸缩。把这些配套的架构升级说出来，面试官会觉得你有系统性的大规模数据平台建设经验。

实战：数据量从百GB到TB的切身体感

我从早期的短视频平台（百GB级）跳到某出海硬件品牌（TB级），最直接的体感就是：原来能广播的表，突然广播不了了。

# 百GB时代（早期短视频平台）：
# 用户画像表 800MB，直接广播，JOIN 5分钟
# 参数：autoBroadcastJoinThreshold = 800MB，完美
 
# TB时代（某出海硬件品牌）：
# 设备型号表从500MB增长到5GB（SKU增加了10倍）
# 5GB × 50个Executor = 250GB，Executor内存只有8GB，直接OOM！
 
# 我的处理过程：
# 第一步：降低广播阈值（临时方案）
# 但这样设备型号表就不能广播，退化到Shuffle Join，倾斜问题重新出现
 
# 第二步：分析设备型号表的查询需求
# 发现：查询里只用到 device_model_id, model_name, category 3列（共200列）
# 3列 × 500万行 ≈ 200MB，可以广播！
 
# 第三步：建立精简视图（Slim View），只暴露必要列
# 所有下游作业都JOIN精简视图而不是原始大表
# CREATE VIEW device_model_slim AS
# SELECT device_model_id, model_name, category FROM device_model_info;
 
# 效果：广播表从5GB → 200MB，重新可以广播
# 额外收益：查询计划更干净，后续维护也更清晰
 
# 教训：数据量增长时，要定期审查「维度表的使用方式」
# 随着业务发展，维度表的列数会膨胀，但查询实际用到的列很少变化
# 建立精简视图是一个低成本高收益的优化手段

总结

数据规模决定倾斜处理策略：百GB优先Broadcast；TB量级Broadcast受限，转向分桶设计+列裁剪广播；十TB及以上，从架构层面建立DWS预聚合减少明细查询，让倾斜问题在汇总层自然消失。面试时说清楚「我在某个量级的项目里遇到了什么问题、为什么百GB的方案在TB量级不适用」，比泛泛说「可以用加盐打散」更有说服力。数据量级经验是面试中重要的差异化因素，不同公司的数据规模差异很大，展示自己处理过的最大规模，是加分项。

下一篇聊一个跨系统的综合场景：从Kafka消费到Flink处理再到Doris写入，整条实时链路上哪些环节可能有倾斜？怎么端到端排查？

你们现在的数据量级是多少？最大单表有多大？倾斜在哪个环节最难处理？评论区聊聊～

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