数仓命名规范是什么
命名规范用固定结构表达层次、主题、内容与周期：层级前缀 + 主题域 + 业务描述 + 周期后缀。一个名字就能读出它属于哪一层、是什么数据、多久更新一次，检索与推断都变得确定。规范的价值不在形式统一，而在于让陌生人在不看文档的情况下也能正确使用一张表——而这恰恰是防止误用全量表与增量表的关键。
基本信息
| 层级前缀 | ods_ 贴源 / dwd_ 明细 / dim_ 维度 / dws_ 汇总 / ads_ 应用 |
|---|---|
| 主题域 | trade、user、traffic 等，与组织的数据域划分一致 |
| 业务描述 | order_detail、user_login，用下划线分词，全部小写 |
| 周期后缀 | 1d 按天、1h 按小时、di 日增量、df 日全量 |
| 临时表 | 统一 tmp_ 前缀并带创建日期与清理约定 |
| 落地方式 | 规范可脚本化巡检，命名不合规在发布环节拦截 |
典型使用场景
- 建表评审：按命名结构核对层级与周期是否与实现一致
- 自助取数：业务按名字判断能否直接用，减少沟通成本
- 血缘排查：按前缀快速定位上下游所处的层
- 容量治理：按后缀识别全量表，优先治理重复存储
- 规范巡检：脚本扫描仓内表名，输出不合规清单推动整改
完整命名读法
完整命名读法
# dws_trade_category_1d
# dws -> 汇总层；trade -> 交易域；category -> 按类目汇总；1d -> 按天更新
# dwd_trade_order_detail_di
# dwd -> 明细层；di -> 日增量（只含当天变化或当天新增）
# dim_user_df
# dim -> 维度层；df -> 日全量（每天一份完整快照，行数稳定）
# ads_trade_gmv_1d
# ads -> 应用层，面向具体报表的交付结果命名要素与反例
| 要素 | 示例 | 常见反例 |
|---|---|---|
| 层级前缀 | ods_ / dwd_ / dim_ / dws_ / ads_ | 前缀缺失，看不出数据在哪一层 |
| 主题域 | trade / user / traffic | 混用中英文与缩写，同义不同名 |
| 业务描述 | order_detail / user_login | 拼音、驼峰、无分隔的长串 |
| 周期后缀 | 1d / 1h / nd / di / df | 全量与增量后缀混用或省略 |
| 临时与中间表 | tmp_ 前缀并约定清理周期 | tmp 表长期驻留，成为事实上的生产表 |
命名规范最好能自动巡检：脚本定期扫描仓内表名与后缀、与分区实际更新频率比对，把不合规项报给表负责人，比发文档有效得多。
全量与增量后缀必须与真实实现一致：名字写成 di 但实际每天全量覆盖的表，会让下游按增量方式累加，直接算出翻倍的数据。