SQL数据倾斜本质是某些key数据量远超其他key，导致任务负载不均；分桶侧重查询优化，分片侧重存储计算水平拆分；二者可协同用于离线数仓ETL与DWD/DWS层。
SQL数据倾斜问题常出现在大表关联、聚合或窗口函数场景中，本质是某些key的数据量远超其他key，导致部分任务节点负载过高、执行缓慢甚至OOM。分桶（Bucketing）与分片（Sharding）是两种从数据组织层面缓解倾斜的常用手段，但二者作用层级和适用场景不同：分桶侧重于查询优化时的局部有序与快速定位，分片则更偏向存储与计算的水平拆分。
分桶设计：让相同key尽量落在同一文件/分区中
分桶通过哈希函数将某列（通常是join key或group by key）映射到固定数量的桶（bucket）中，每个桶对应一个独立文件。它不改变数据总量，但能提升等值join和count distinct等操作的效率，并为后续采样、局部聚合提供基础。
- 建表时指定CLUSTERED BY (col) INTO N BUCKETS，N建议取2的幂次（如64、128），避免小文件过多或桶数不足
- 必须配合SORTED BY (col)才能启用桶剪枝；若只分桶不排序，Spark SQL或Hive可能无法自动识别桶结构
- 对倾斜key，可在分桶前做预处理：例如把null值映射为随机前缀（coalesce(col, concat('skew_', rand()))），再分桶，使原null分散到多个桶
- 注意：分桶列需高频参与过滤或关联，否则收益有限；且写入时必须用INSERT OVERWRITE TABLE ... SELECT ... DISTRIBUTE BY col保证物理分布一致
分片设计：按业务逻辑或key特征横向切分数据
分片不是SQL语法特性，而是数据架构层面的策略，常见于分库分表或ETL流程中。它通过显式规则将大表按范围（range）、哈希（hash）或列表（list）方式拆分为多个逻辑子集，从根本上降低单点压力。
- 对明显长尾的key（如用户ID=0、地区='未知'、状态='待处理'），可单独切出一张“倾斜表”，与其他正常数据分别处理，最后union结果
- 采用“两阶段聚合”：第一阶段加盐（salt）打散倾斜key（如concat(user_id, '_', floor(rand()*10))），按新key聚合；第二阶段去掉盐值，再次聚合汇总
- 时间类分片较稳定：按天/月分区+按业务主键哈希二级分片，既能利用分区裁剪，又能均衡各分片数据量
- 避免过度分片：分片数应与集群核心数、IO吞吐匹配，一般单分片大小控制在1–5GB较合理
分桶与分片协同使用的典型模式
在离线数仓中，常将分片作为ETL层的物理组织方式，分桶作为DWD/DWS层的查询加速手段。例如：用户行为表按dt（日期）分片，每日一个分区；每个分区内再按user_id分桶（128桶），便于后续与用户维表高效join。
- ETL任务写入时，先按dt路由到对应分区目录，再按user_id哈希写入对应桶文件
- 下游任务开启set hive.optimize.bucketmapjoin=true等参数，使MapJoin自动识别桶结构
- 对跨多日分析场景，可结合动态分桶（如Spark的repartitionByRange）替代静态分桶，适应数据分布变化
验证与调优要点
是否真正缓解倾斜，不能只看执行时间，要查shuffle write量、task耗时分布、GC频率等指标。
- 用EXPLAIN EXTENDED观察执行计划中是否有BucketMapJoin或SkewJoin提示
- 检查各bucket文件大小是否均衡（HDFS命令hdfs dfs -du -s /path/to/table/*）；若某桶明显偏大，说明分桶列存在隐式倾斜
- 在Spark UI中查看Stage的Task Duration分布图，理想情况应呈窄带状；若出现个别task耗时超均值3倍以上，仍需进一步干预
- 对实时性要求高的场景，可引入局部预聚合（如Flink的LocalGlobal优化）或状态TTL控制，减少倾斜累积效应
