首页/数据/数仓建模速查/周期后缀:_di/_df/_day/_mon
分层与规范64 条

周期后缀:_di/_df/_day/_mon

周期与刷新方式用后缀表达:di 增量日、df 全量日、day/week/mon 汇总周期;后缀与调度频率一致,避免把月表当日表读。

数仓建模速查数据更新于 2026-10-13

周期后缀是什么

表名后缀表达两件事:数据是增量还是全量(_di 每日增量、_df 每日全量快照),以及汇总的周期(_day、_week、_mon)。后缀必须与调度频率保持一致:日任务产出 _di 或 _df,周任务产出 _week,月任务产出 _mon。后缀最大的价值在于防止误读:_di 表可以跨天累加成累计值,_df 表只能取某一天的全量快照,把全量快照按天相加会得到放大数倍的错误结果,而且大多数情况下不会报错。

基本信息

_di每日增量表,每天只包含新增或变更的数据
_df每日全量快照表,每天一份完整数据
_day/_week/_mon按日、周、月汇总的周期后缀
一致性约束后缀必须与调度频率一致,改频率要改后缀
读取差异增量表可跨天累加,全量快照只能取最新一天
命名结构分层前缀 + 主题 + 维度 + 周期后缀
配套说明同主题同时存在增量与全量表时,要在注释里写清差异

典型使用场景

  • 增量同步的明细表用 _di,按天追加写入,月度累计只需叠加各天分区
  • 每日全量同步的表用 _df,只保留当天全量,查询必须限定单日分区
  • 汇总表用 _day、_week、_mon 区分周期,避免月表被当日表读取
  • 调度频率调整(如由日改为小时)后同步更新后缀,保持名称与产出节奏一致
  • 对账前先看后缀再决定口径:增量累加与快照累加本就是两套算法

后缀示例与读法

后缀示例与读法
# 后缀直接表达数据形态与周期
dwd_trade_order_di      每日增量明细,可跨天累加
dwd_trade_order_df      每日全量快照,只能取某一天
dws_trade_store_day     门店日汇总
dws_trade_store_mon     门店月汇总
ads_sale_board_day      看板日结果表

-- 读全量快照表必须限定单日分区,否则同一实体被重复计算
SELECT count(*) FROM dwd_trade_order_df WHERE dt = '2026-10-12';
-- 读增量表做月度累计,按月叠加各天分区
SELECT sum(pay_amt) FROM dwd_trade_order_di WHERE dt >= '2026-10-01' AND dt < '2026-11-01';

后缀逐项读法

后缀含义能否跨天累加典型来源
_di每日增量表可以,按天叠加即累计每日增量同步
_df每日全量快照不可以,只能取一天每日全量同步
_day日汇总表可以,按天叠加日调度汇总
_mon月汇总表可以,按月份叠加月调度汇总
对账时先看后缀再选算法:增量表按天累加得到的是累计发生量,全量快照表逐天相加得到的是各天快照之和,两者不是同一个东西。
月表被当日表读取、日表被当月表读取,通常不会报错,只是数字要么偏小要么大得离谱,靠人工发现的时间成本很高。

易错点

  • 全量快照表按天累加求月值:同一笔业务被重复计算,指标放大数倍且不易察觉
  • 后缀与调度频率不一致(日任务产出 _mon 表):下游按名字理解周期,取数整体错位
  • 同主题同粒度同时存在增量与全量表却不写差异:下游随机取一张,口径随时间漂移
  • 汇总周期后缀写成语义模糊的 _d 或 _m:不同团队理解不同,跨团队复用必然出错
  • 同步方式由全量改为增量却沿用 _df 后缀:命名的实际语义与数据不符,误导后续开发

数据来源与参考

  • 阿里《大数据之路:阿里巴巴大数据实践》
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌