数仓命名规范
总结
| 记忆点 | 内容 |
|---|---|
| 表名公式 | {层级}_{业务域}_{主题}_{描述}_{时间粒度} |
| 字段原则 | 全小写snake_case，同义统一命名，加类型后缀 |
| 分区规范 | dt为主分区，按需加hour/region |
| 落地三步 | 文档化 → 建表卡控 → 存量迁移 |
| 核心价值 | 好命名 = 自文档化，降低沟通和维护成本 |
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
基础 | 大数据面试 · 数仓建模系列
| 面试真题 你们数仓的表是怎么命名的？有没有统一的命名规范？是你定的还是团队一起定的？ |
|---|
命名规范为什么重要？
看到一张表叫user_data_new_v2_final_bak，你知道它是哪一层的吗？谁建的？干嘛用的？再看一张叫dws_trade_user_pay_amount_1d的表，不用看文档就能猜到：DWS层，交易域，用户粒度，支付金额，天级汇总。
好的命名规范 = 自文档化。表名本身就是文档，团队不用反复问「这张表是什么」。
| Wood的实战经验 我在短剧出海公司接手数据组时，遗留了200多张表，一半没有注释，表名风格五花八门。我做的第一件事就是定命名规范，然后花了两周把所有表重命名。痛苦，但值得。命名统一之后，团队沟通效率至少提升了30%，新人入职看表名就能猜到大概用途。 |
|---|
表命名公式
核心格式：{层级}_{业务域}_{主题/实体}_{描述}_{时间粒度}
| 部分 | 含义 | 示例值 |
|---|---|---|
| 层级 | 所属数仓层 | ods / dwd / dws / ads / dim |
| 业务域 | 业务所属领域 | trade(交易) / user(用户) / ad(广告) |
| 主题/实体 | 核心实体或主题 | order(订单) / payment(支付) / click(点击) |
| 描述 | 补充说明 | detail(明细) / summary(汇总) / wide(宽表) |
| 时间粒度 | 数据更新频率 | di(日增量) / df(日全量) / 1d(天) / 1h(时) |
命名实例
| ods_trade_order_di -- ODS层，交易域，订单表，日增量 dwd_trade_order_detail_di -- DWD层，交易域，订单明细，日增量 dws_trade_user_pay_1d -- DWS层，交易域，用户支付汇总，天级 ads_trade_daily_report -- ADS层，交易域，每日报表 dim_user_df -- 维度表，用户，日全量 |
|---|
字段命名规范
全部小写+下划线分隔（snake_case），同一含义用同一名称全库统一，不要缩写到看不懂（usr_nm → user_name）。
常用约定：主键/ID用{entity}_id，金额用{desc}_amount，数量用{desc}_cnt，比率用{desc}_rate，时间戳用{action}_time，布尔标记用is_{desc}，分区字段用dt/hour。
怎么让规范落地？
定规范容易，让全团队遵守才是挑战。我的经验分三步：
第一：写成文档。新人入职第一天读。不用写得很长，一页纸的表格+10个示例就够了。
第二：建表审批卡控。DataWorks/Hive Metastore层面做校验：表名不符合正则的直接拒绝建表。技术手段卡住，比人工Review靠谱100倍。
第三：存量表逐步迁移。不要一刀切改名（会影响下游），而是新建规范表 → 数据迁移 → 旧表加deprecated标记 → 下游切换完毕后下线旧表。
| 面试加分提示 这题考的不是你背了多少规范条目，而是你有没有推动过规范落地： 「我接手数据组时，200多张表命名风格不统一，很多没注释。我做了三件事：第一，参考Kimball体系定了一套命名规范（层级+业务域+实体+粒度）；第二，在DataWorks上做了建表校验，不符合规范的不让建；第三，花了两周把存量表逐步迁移到新命名。迁移后团队协作效率明显提升，新人上手也快多了。」 重点：不只是定规范，而是推动执行并看到效果。 |
|---|