📚 课程目录第3章分区策略设计

3、分区策略设计：时间分区、范围分区、哈希分区、列表分区、组合分区

分区策略选对了，后面能省很多事。选错了……嗯，我见过有人因为分区策略没想好，跑了半年的数据湖，最后不得不全量重刷。今天咱们就把五种主流策略掰开揉碎讲清楚。

核心观点：没有最好的分区策略，只有最适合你查询模式的分区策略。设计前先问自己三个问题——数据怎么查？数据多大？数据怎么变？

3.1 时间分区：最常用的策略

时间分区是我个人用得最多的策略。说白了，就是把数据按时间切块。年、月、日、小时，看你业务需要。

为什么它这么流行？因为大部分分析查询都带时间范围。你想想看，哪个业务不看「上周的订单」「上个月的活跃用户」？

-- Hive 时间分区表示例
CREATE TABLE events (
    event_id STRING,
    user_id STRING,
    event_data STRING
)
PARTITIONED BY (
    year INT,
    month INT,
    day INT
);

-- 写入时指定分区
INSERT INTO events PARTITION (year=2024, month=11, day=15)
VALUES ('e001', 'u001', '{"action":"click"}');

时间粒度	适用场景	分区数/年	我踩过的坑
年	归档数据、长周期趋势	1	查询单月数据仍需全表扫描
月	月度报表、常规分析	12	日增量数据更新时分区粒度太粗
日	实时数仓、日志分析	365	小文件问题严重，需合并
小时	流式处理、实时监控	8760	元数据膨胀，NameNode 压力大

注意：我曾经在一个项目中用了小时级分区，结果一年产生了八千多个分区。Hive Metastore 查询分区列表时直接超时。后来我改成了天级分区+内部再按小时分桶，问题才解决。

3.2 范围分区：灵活但需谨慎

范围分区是按数值区间切分。比如订单金额 0-100、100-1000、1000+。它比时间分区灵活，但设计起来也更考验功力。

我建议你注意两点：

区间边界要清晰——别出现「100 块钱的订单到底归哪个区」这种问题
数据倾斜要预判——大部分订单可能都在 0-100 区间，其他区间几乎没数据

-- Spark SQL 范围分区示例
df.write
  .partitionBy("order_amount")
  .format("parquet")
  .save("/data/orders")

-- 但更好的做法是自定义分区函数
df.withColumn("amount_range",
  when(col("order_amount") < 100, "low")
  .when(col("order_amount") < 1000, "medium")
  .otherwise("high")
).write
 .partitionBy("amount_range")
 .format("parquet")
 .save("/data/orders")

技巧：范围分区最好配合数据采样。先跑个 SELECT COUNT(*) GROUP BY range，看看每个区间数据量是否均匀。不均匀的话，调整区间边界或者换哈希分区。

3.3 哈希分区：解决数据倾斜的利器

哈希分区，说白了就是把数据打散。它对某个字段算哈希值，然后模上分区数，决定数据去哪。

什么时候用哈希分区？我总结了两类场景：

没有天然的分区键——比如用户 ID，没有时间属性，也没有明显的范围
需要并行写入——哈希能保证数据均匀分布，写入性能好

-- Hive 哈希分区（通过分桶实现）
CREATE TABLE user_profiles (
    user_id STRING,
    profile_data STRING
)
CLUSTERED BY (user_id) INTO 16 BUCKETS;

-- Spark 哈希分区
df.write
  .partitionBy("user_id")
  .bucketBy(16, "user_id")
  .format("parquet")
  .save("/data/profiles")

避坑指南：我曾经用哈希分区处理用户 ID，选了 10 个分区。结果发现某些热门用户的数据量是普通用户的 100 倍，哈希根本打不散。后来我改用 user_id 的哈希值再拼接上日期，才把热点数据分散开。

3.4 列表分区：按枚举值归类

列表分区是按固定的枚举值划分。比如地区：华东、华北、华南。或者业务线：电商、金融、教育。

它的好处是直观，查询时直接定位到对应分区。但缺点也很明显——枚举值变了怎么办？

-- 列表分区示例（Hive 通过自定义方式实现）
CREATE TABLE sales_by_region (
    sale_id STRING,
    amount DOUBLE,
    region STRING
)
PARTITIONED BY (region STRING);

-- 写入时指定枚举值
INSERT INTO sales_by_region PARTITION (region='east')
VALUES ('s001', 100.0, 'east');

INSERT INTO sales_by_region PARTITION (region='west')
VALUES ('s002', 200.0, 'west');

场景	推荐分区策略	原因
地区数据	列表分区	枚举值固定，查询模式明确
业务线数据	列表分区	业务线数量少且稳定
状态字段	列表分区	如订单状态：待支付、已支付、已取消

建议：列表分区的枚举值最好控制在 20 个以内。超过这个数，元数据管理成本会急剧上升。我见过有人把城市名当列表分区，全国三百多个城市，查询计划生成都要好几秒。

3.5 组合分区：实战中的王牌

组合分区就是把上面几种策略混着用。比如时间+地区、时间+哈希、范围+列表。这是我在生产环境中最常用的方案。

为什么？因为单一策略总有短板。时间分区查某个地区的数据慢，列表分区查时间范围又不行。组合起来，各取所长。

-- 组合分区示例：时间 + 地区
CREATE TABLE orders (
    order_id STRING,
    amount DOUBLE,
    region STRING,
    order_date STRING
)
PARTITIONED BY (
    year INT,
    month INT,
    region STRING
);

-- 查询时能同时利用两个分区键
SELECT * FROM orders
WHERE year = 2024
  AND month = 11
  AND region = 'east';

我个人习惯的组合方式：

时间 + 列表：适合多业务线、多地区的日志数据
时间 + 哈希：适合用户行为数据，既能按时间裁剪，又能分散热点
范围 + 列表：适合金额+地区的分析场景

实战经验：我在做一个电商数据湖项目时，用了「年/月/日 + 业务线」的组合分区。日分区保证细粒度查询，业务线分区让不同团队只扫描自己的数据。查询性能提升了 5 倍，而且数据隔离性也好了。

3.6 策略选择决策框架

说了这么多，到底怎么选？我画了一张图，帮你快速决策。

我的建议：别追求一步到位。先选一个简单的分区策略跑起来，观察查询模式和数据分布。运行两周后，你自然知道该不该加组合分区。我在项目里经常是先用时间分区，发现某个地区的查询特别多，再加列表分区做组合。

好了，五种分区策略都讲完了。记住一句话：分区是给查询服务的，不是给存储服务的。设计时多想想查询怎么写，分区策略自然就清晰了。