OLAP 冷热分层与数据搬运
实时分析库（ClickHouse、Doris、StarRocks）的存储成本与容量都高于对象存储，常规做法是把近期热数据留在 OLAP 集群、历史数据沉到湖表，查询侧用视图或联邦查询把冷热两段结果合并。关键参数是下沉边界：它必须不短于业务回溯期，否则历史查询会出现空洞。
基本信息
| 热数据 | 近期数据留在 OLAP 集群 |
|---|---|
| 冷数据 | 历史数据沉到湖表 |
| 合并方式 | 视图 UNION 或联邦查询 |
| 搬运粒度 | 按分区同步并校验 |
| 关键参数 | 下沉边界与业务回溯期 |
典型使用场景
- 控制集群容量：只保留近 90 天明细，更早数据下沉到湖表
- 跨期对比查询：用 UNION 视图把冷热两段拼成完整时间轴
- 明细排查：涉及历史工单时走联邦查询，让过滤条件尽量下推
- 搬迁评估：先确认业务回溯期与合规留存要求，再决定下沉边界
- 一致性监控：定期比对冷热两段的行数与金额，及时发现搬运断档
冷热合并视图
冷热合并视图
CREATE VIEW dw.v_trade_store_day AS
SELECT store_id, dt, order_cnt, pay_amt
FROM dw.dws_trade_store_day_recent -- 热段：OLAP 集群内明细
UNION ALL
SELECT store_id, dt, order_cnt, pay_amt
FROM lake.dws_trade_store_day_history; -- 冷段：湖表外接
-- 查询务必带上 dt 条件，让冷热两段都能做分区裁剪
-- 例如：SELECT * FROM dw.v_trade_store_day WHERE dt >= '2026-01-01';冷热设计要点
| 要点 | 做法 | 风险 |
|---|---|---|
| 下沉边界 | 按业务回溯期确定 | 边界过近导致历史缺数 |
| 合并方式 | 视图 UNION ALL | 过滤不下推会全量扫描 |
| 搬运一致性 | 按分区同步并校验 | 中断几天出现空洞 |
| 成本分配 | 热在 OLAP、冷在对象存储 | 冷段查询延迟上升 |
冷段查询延迟明显高于热段，跨期查询要对使用方做好预期管理，高频历史区间可以再做一层预聚合。
历史数据下沉过早而回溯期设置过短，运营查询整年数据时缺一段，且往往到月度汇总时才被发现，补数成本很高。
下沉边界不要一次设到位：先从较长的保留期开始，按实际查询命中情况逐月收缩，比一次性设成最短回溯期安全得多。