小时级分区设计要点
实时或准实时落仓的链路用小时分区：dt 加 hh 两级，写入按小时覆盖，重跑只影响目标小时。需要清醒对待的是规模：小时分区数量是日分区的 24 倍，文件数与元数据压力同步上升，必须配套严格的保留策略，否则元数据服务会先撑不住。
基本信息
| 适用场景 | 实时或准实时落仓 |
|---|---|
| 分区结构 | dt 加 hh 两级 |
| 写入方式 | 按小时覆盖 |
| 保留策略 | 滚动清理过期小时分区 |
| 主要风险 | 分区数与文件数膨胀 |
典型使用场景
- 准实时链路：小时级产出支撑当日看板，日终再产出日汇总
- 排障定位：按小时分区缩小重跑范围，只刷新受影响的那一小时
- 日内监控指标：小时分区支持日内同比、环比分析
- 保留策略：小时分区只留最近若干天，更早数据用日分区承载后清理
- 写入控制：单小时数据量小，写出并行度与文件数需要一起约束
小时分区写入与清理
小时分区写入与清理
-- 按小时覆盖写入，重跑只影响这一个小时
INSERT OVERWRITE TABLE dwd_flow_event_hour PARTITION (dt = '2026-10-12', hh = '08')
SELECT event_id, user_id, event_time, etl_load_time
FROM stg_flow_event
WHERE dt = '2026-10-12' AND hh = '08';
-- 保留策略：仅保留近 7 天小时分区，更早数据由日分区承载
ALTER TABLE dwd_flow_event_hour DROP IF EXISTS PARTITION (dt < '2026-10-06');小时与日分区对照
| 维度 | 小时分区 | 日分区 |
|---|---|---|
| 分区数量 | 日粒度的 24 倍 | 基准 |
| 时效性 | 日内可查 | 通常 T+1 |
| 文件数压力 | 高，需控小文件 | 相对低 |
| 适用对象 | 实时看板与排障 | 常规报表 |
小时分区保留期设得过长，文件数与元数据量会迅速堆高，元数据服务响应变慢的影响面是整个集群，而不只是这一张表。
小时分区的日界要按业务时区确定：如果日切不在自然日零点，hh 边界与业务日界线会错位，跨日汇总必须按业务日切口径处理。
小时分区通常只承接当日数据，更早的数据在下游合并为日分区后即可清理；把「小时明细」和「日汇总」分成两张表，可以让保留策略各按自己的周期执行。