ODS 的设计原则
ODS（贴源层）与源系统保持同构：字段名、类型尽量不动，只做落地与分区管理，保留原始信息以便对账与回溯。核心原则是「不加工、可追溯」——任何业务规则的清洗都放到 DWD，这样数据对不上时还能回到最原始的记录去核对。
增量与快照两条链路
常见做法是两条链路并存：定时增量抽取覆盖当天的变化数据，周期性全量快照保留某个时刻的完整状态。增量保证时效与成本，全量快照用来兜住物理删除与历史修正——只保留增量的话，源端删除的记录在贴源层永远看不出来。
基本信息
| 原则 | 同构落地、不加工、可追溯 |
|---|---|
| 分区 | 按抽取日期 dt 分区，写入时按分区覆盖 |
| 写入方式 | 增量场景按当日分区覆盖，避免重复追加 |
| 保留策略 | 按合规要求确定原始数据保留期限 |
| 常见链路 | 增量抽取加周期全量快照两条链路并存 |
ODS 常见做法
| 做法 | 目的 | 注意 |
|---|---|---|
| 字段与源库对齐 | 保留原始语义，便于对账 | 源库改字段时需要同步演进 |
| 按抽取日期分区 | 重跑时按分区覆盖，天然幂等 | 分区列命名统一，避免混乱 |
| 保留原始字符串 | 不做类型转换，避免精度与格式丢失 | 下游转换时统一规则 |
| 同时保留全量快照 | 捕获删除与历史修正 | 存储成本上升，需权衡保留周期 |
典型使用场景
- 新数据源接入：先把原始表落地，再逐层加工
- 对账与追溯：下游数字异常时回查最原始记录
- 数据修复：源端历史数据被修正后，重刷对应分区
- 合规审计：保留原始数据以满足留痕要求
- 全量开荒：用批量工具或 CDC 快照导入存量数据
ODS 建表
ODS 建表
CREATE TABLE IF NOT EXISTS ods_order_mysql (
id BIGINT COMMENT '订单id',
user_id BIGINT,
total_amount DECIMAL(18,2),
status INT,
create_time STRING, -- 保留源库原始格式，不在这一层做类型转换
update_time STRING
) COMMENT '订单表贴源'
PARTITIONED BY (dt STRING COMMENT '抽取日期')
STORED AS ORC;当日分区覆盖写入
当日分区覆盖写入
-- 只覆盖当天分区：重跑多少次结果都一致
INSERT OVERWRITE TABLE ods_order_mysql PARTITION (dt = '2026-10-11')
SELECT id, user_id, total_amount, status, create_time, update_time
FROM src_order
WHERE update_time >= '2026-10-11 00:00:00'
AND update_time < '2026-10-12 00:00:00'; -- 左闭右开，边界不重不漏ODS 不做业务规则清洗能省掉大量「数据对不上却无法回源」的争论：原始值一旦被转换或脱敏覆盖，就没法和源库逐字段核对了。
只保留增量、不保留任何全量快照，源端物理删除的记录在贴源层无从发现：目标端的已删除数据会永久残留，对账时只能靠人回忆业务流程。