分区规划基础：分区概念、分区的好处、分区的代价、何时该分区
聊数据湖，绕不开分区。我见过太多团队，一上来就建表，数据往里一丢，等到查询慢得像蜗牛爬，才回头补分区。说实话，分区不是什么高深技术，但用好了，性能翻倍；用不好，运维想哭。
这一节，咱们把分区这件事彻底聊透。从概念到收益，从代价到决策时机，我把自己踩过的坑和积累的经验都摊开来讲。
什么是分区？
分区，说白了就是把一张大表，按某个字段拆成多个物理子目录或子文件。你想想看，一本一千页的书，你要找某一页，是整本翻快，还是先看目录定位到章节再翻快？分区就是这个道理。
在数据湖里，分区通常表现为目录层级。比如按日期分区：
/data/events/
dt=2024-01-01/
event_001.parquet
event_002.parquet
dt=2024-01-02/
event_003.parquet
event_004.parquet查询时如果带上 WHERE dt = '2024-01-01'，引擎直接跳过其他目录，只扫这一个分区。嗯，这就是分区最核心的机制——分区裁剪。
核心概念：分区字段是逻辑上的"索引"，物理上表现为目录结构。查询时通过分区字段过滤，引擎只读取匹配的分区目录，避免全表扫描。
分区的好处
好处其实很直观，我列几个最实在的：
- 查询性能大幅提升：数据量越大，效果越明显。TB 级表，分区后查询可能从小时级降到秒级。
- 降低扫描成本：云上数据湖按扫描量计费，分区能帮你省下真金白银。我在项目中见过，一个分区优化，月账单直接砍掉 40%。
- 便于数据管理：可以按分区做生命周期管理，比如只保留最近 30 天的分区，旧分区自动归档或删除。
- 支持增量处理：ETL 作业可以只处理新增分区，不用重跑全量数据。
| 场景 | 未分区 | 已分区 |
|---|---|---|
| 查询某天数据 | 扫描 1TB | 扫描 10GB |
| 删除旧数据 | 全表重写 | 直接删目录 |
| 增量加载 | 全量比对 | 追加分区 |
分区的代价
别急着给所有表都加上分区。分区不是免费的午餐，代价也很实在。
元数据膨胀：每个分区都会在 Hive Metastore 或 Glue Catalog 里生成一条记录。分区数量一多，元数据操作就变慢。我曾经接手过一个项目，一张表分了 10 万个分区，执行 SHOW PARTITIONS 都要等半分钟。
小文件问题：分区粒度过细，每个分区里数据量很少，就会产生大量小文件。小文件多了，NameNode 压力大，查询时打开文件的 overhead 也高。说白了，分区不是越细越好。
写入性能下降：写入数据时，引擎需要创建或更新分区目录。分区越多，写入的元数据操作越频繁，写入吞吐量会受影响。
避坑指南：我曾经在一个实时数仓项目里，按小时分区，结果每天产生 24 个分区，每个分区只有几百 MB 数据。查询时分区裁剪确实快，但小文件太多，导致 Spark 作业的 task 调度开销比实际计算还大。后来改成按天分区，问题才解决。
何时该分区？
这个问题没有标准答案，但我总结了几条经验法则：
- 数据量够大：单表超过 100GB，分区才有明显收益。小表分区反而增加复杂度。
- 查询有明确过滤条件：如果查询经常按某个字段过滤，比如日期、地域、业务线，那这个字段就是天然的分区键。
- 数据有生命周期：需要定期清理或归档的数据，按时间分区最合适。
- 分区数量可控：单个表的分区数建议控制在 1 万以内。超过这个量，元数据压力会显著增加。
个人习惯：我一般先按天分区，如果数据量特别大（每天超过 100GB），再考虑按小时。分区字段尽量选基数适中、分布均匀的列。比如用日期不用时间戳，用业务线不用用户 ID。
你想想看，分区就像给数据建索引，用对了是利器，用错了是负担。核心就一句话：分区是为了减少扫描数据量，不是为了分区而分区。