分区表设计得好，查询快100倍不是梦

/warehouse/user_event/
  ├── dt=2025-01-01/
  │   ├── part-00000
  │   ├── part-00001
  │   └── ...
  ├── dt=2025-01-02/
  │   └── ...
  └── dt=2025-01-03/
      └── ...

-- 建表语句（Hive）
CREATE TABLE user_event (
  user_id     STRING,
  event_name  STRING,
  event_time  TIMESTAMP,
  properties  MAP<STRING, STRING>
)
PARTITIONED BY (dt STRING)
STORED AS ORC;

-- ❌ 按小时分区，一天24个分区，一年8760个分区
PARTITIONED BY (dt STRING, hour STRING)
 
-- ❌ 按用户ID分区，百万级分区
PARTITIONED BY (user_id STRING)

-- 按天+按渠道的二级分区
PARTITIONED BY (dt STRING, channel STRING)
 
/warehouse/user_event/
  ├── dt=2025-01-01/
  │   ├── channel=Facebook/
  │   ├── channel=TikTok/
  │   └── channel=Google/
  └── dt=2025-01-02/
      └── ...

我在做广告数据的时候，表按dt + channel双分区，因为日常查询90%都带这两个条件。但用户行为日志我只用dt单分区，因为行为类型有上百种，做二级分区会产生太多小文件。

原则四：分区键不要参与计算

-- ❌ 分区裁剪失效
SELECT * FROM user_event
WHERE SUBSTR(dt, 1, 7) = '2025-01'
 
-- ✅ 分区裁剪生效
SELECT * FROM user_event
WHERE dt >= '2025-01-01' AND dt <= '2025-01-31'
 
-- ✅ 更简洁
SELECT * FROM user_event
WHERE dt BETWEEN '2025-01-01' AND '2025-01-31'

如果WHERE条件中对分区键做了函数运算（SUBSTR、YEAR、DATE_FORMAT等），优化器无法识别出分区范围，会退化为全表扫描。这是最常见的分区裁剪失效场景。

分区裁剪失效的5种常见情况

面试官经常问"什么情况下分区裁剪会失效"，把这5种记住：

1. 对分区键做函数运算（上面讲过）

WHERE YEAR(dt) = 2025  -- ❌ 失效
WHERE dt >= '2025-01-01' AND dt < '2026-01-01'  -- ✅

2. 分区键隐式类型转换

-- dt是STRING类型
WHERE dt = 20250101  -- ❌ 数字和字符串比较，可能失效
WHERE dt = '20250101'  -- ✅ 类型匹配

3. OR条件中包含非分区字段

WHERE dt = '2025-01-01' OR user_id = 'u001'  -- ❌ OR导致全表扫描
-- 改写为UNION ALL
SELECT * FROM user_event WHERE dt = '2025-01-01'
UNION ALL
SELECT * FROM user_event WHERE user_id = 'u001'  -- 这个还是全扫，但至少第一个查询能裁剪

4. JOIN条件中的分区键

-- 如果分区过滤条件在JOIN的ON里而不是WHERE里，可能失效
SELECT *
FROM user_event e
JOIN date_dim d ON e.dt = d.dt AND d.is_weekend = 1
-- 有些引擎不会把is_weekend=1的过滤下推到user_event的分区裁剪

5. 动态分区写入后未更新统计信息

Hive的CBO依赖统计信息做优化决策。如果用动态分区写入了数据但没有ANALYZE TABLE，优化器可能做出错误的执行计划。

-- 写入后更新统计信息
ANALYZE TABLE user_event PARTITION(dt='2025-01-01') COMPUTE STATISTICS;

实战：动态分区 vs 静态分区

写数据的时候有两种分区方式：

静态分区： 手动指定分区值

INSERT OVERWRITE TABLE user_event PARTITION(dt='2025-01-01')
SELECT user_id, event_name, event_time, properties
FROM staging_table
WHERE dt = '2025-01-01'

动态分区： 让Hive根据数据自动创建分区

SET hive.exec.dynamic.partition=true;
SET hive.exec.dynamic.partition.mode=nonstrict;
 
INSERT OVERWRITE TABLE user_event PARTITION(dt)
SELECT user_id, event_name, event_time, properties, dt
FROM staging_table

动态分区方便但有风险——如果源数据中dt的取值有几千种（比如脏数据导致日期格式不对），会创建几千个分区，直接打爆NameNode。我见过一次事故，有人用动态分区导入了一批日期格式错乱的数据，一次性创建了20000多个分区，HDFS的NameNode直接挂了，影响了整个集群。

生产环境建议：动态分区一定要设置最大分区数限制：

SET hive.exec.max.dynamic.partitions=1000;
SET hive.exec.max.dynamic.partitions.pernode=100;

面试加分：Spark中的Bucket

分区是按目录切分，Bucket是在分区内进一步按Hash切分文件：

CREATE TABLE user_event_bucketed (
  user_id STRING,
  event_name STRING,
  event_time TIMESTAMP
)
PARTITIONED BY (dt STRING)
CLUSTERED BY (user_id) INTO 256 BUCKETS
STORED AS ORC;

Bucket的好处：两张表如果按同一个字段做了相同数量的Bucket，JOIN时可以做Bucket Map Join——每个Bucket只和对应的Bucket匹配，不需要全量Shuffle。这在大表JOIN大表的场景下效果显著。

但Bucket在实际工作中用得没有分区多，因为Bucket数量一旦确定就不好改，而且很多团队对Bucket的了解不够深。面试的时候知道这个概念和适用场景就够了。