
![](https://developer.qcloudimg.com/http-save/yehe-11851421/c56778c4def1050275db99c2656be28a.jpg)

数据仓库做大之后，最先“失控”的往往不是数据，而是命名。命名规范看似细节，却直接决定了数据是否好找、好用、好维护。

作为数据湖仓设计与实践系列文章第 5 篇，本文从实际使用出发，梳理了表与字段命名的核心方法，通过分层前缀、词根统一和周期编码，让表名更自解释；同时结合指标命名与治理流程，帮助构建清晰、可协作的数据体系。

## 命名规范的目标与方法：让表名“自解释”、让团队“自动协作”

在数据仓库体系中，命名规范并不是形式问题，而是直接影响协作效率与数据质量的基础设施。一个好的命名体系，核心目标只有一个——让表名本身就携带足够多的信息，使人无需额外查文档，就能理解这张表“是什么、从哪来、怎么用”。
### 命名规范的核心目标：让表名携带足够多的元信息
理想状态下，一个表名应当能够被“一眼读懂”，至少包含以下关键信息：数据分层、归属团队、业务域、主题域、核心对象含义，以及更新周期或数据范围。当这些信息被规范地编码进表名后，查找数据、理解口径、排查问题甚至团队交接都会变得更加高效，显著降低沟通成本。
### 命名体系=词根体系（统一业务语言）
要实现这一点，命名体系必须建立在统一的“词根体系”之上。本质上，这是在统一团队的业务语言。例如，同一个业务对象必须使用同一个词根，不能在不同表中混用不同表达（如 rack 和 shelf）。同样，指标命名也需要统一规则，例如所有“率类指标”统一使用 `_rate` 后缀，避免 ratio、percent、rt 等混用带来的歧义。
### 分层前缀必须固定：先看“这是哪一层的资产
此外，数据分层前缀必须强制规范。通过前缀，使用者可以第一时间判断这张表所处的层级及其用途：`ods_` 表示贴源数据，`dwd_` 表示标准明细层，`dws_` 表示公共汇总层，`ads_` 面向应用交付，而 `dim_` 则用于统一维度。这种前缀不仅是命名规则，更是数据分层设计的直接体现。
### 更新周期/数据范围必须编码到表名里（防口径误用）
另一个容易被忽视但非常关键的点是，更新周期或数据范围必须显式体现在表名中。例如 `_1d` 表示最近一天，`_td` 表示截至当日，`_7d` 表示最近七天。这种设计可以有效避免“同名表但时间口径不同”的问题，是防止指标误用的重要手段。
### 表分类要明确：常规表 vs 中间表 vs 临时表（防资产污染）
在资产管理层面，还需要明确区分不同类型的表。正式表是可长期维护的数据资产；中间表仅服务于作业过程，应设置保留策略；临时表则只用于一次性验证，禁止进入生产链路。通过在命名中引入 `mid_` 与 `tmp_` 前缀，可以从源头避免数据资产污染。
### 命名与治理流程绑定：新增表/字段必须补齐元数据
最后，命名规范必须与数据治理流程绑定。任何新增表或字段，都必须同步补齐元数据，包括负责人、字段含义、指标口径、更新频率、依赖关系及生命周期。缺乏这些信息的“裸表”，在短期内或许可用，但从长期看几乎一定会演变为技术债。
### 落地原则：先固化“模板”，再允许“少量自由字段
在落地过程中，应优先固化统一模板，保证关键字段（如层级、业务域、周期）强制一致，同时允许在非关键部分保留适度灵活性，以兼顾规范性与实际需求。


## 表命名规范：模板 + 周期/范围编码 + 典型样例
- 1）常规表命名模板

在具体实践中，表命名需要有清晰的结构化模板，以确保信息表达完整且一致。通用的命名模板可以定义为：
`{layer}_{dept}_{biz_domain}_{subject}_{object}_{cycle_or_range}`

这一结构中，各部分承担明确职责：layer 表示数据分层，dept 表示团队归属，biz_domain 表示业务域，subject 是分析视角下的主题抽象，object 表示具体对象或行为，而 cycle_or_range 则用于标识数据的时间范围或更新周期。

- 2）周期/数据范围编码

其中，周期与范围的编码尤为关键。常见表达包括 `_1d`（最近一天）、`_td`（截至当日）、`_7d` 或 `_30d`（最近 N 天）。此外，还可以通过附加标识区分数据类型或更新方式，例如 d 表示日级快照，w 表示周级数据，i 表示增量表，f 表示全量表，l 表示拉链表。这些约定能够帮助使用者快速理解数据的时间语义。
- 3）DWS 官方示例

以汇总层为例，可以参考如下命名方式：`dws_asale_trd_byr_subpay_1d` 表示买家粒度、交易分阶段付款、最近一天汇总数据；`dws_asale_trd_itm_slr_hh` 则表示卖家视角下的商品小时级汇总。这类命名虽然较长，但信息完整且具备高度可读性。
- 4）维度表命名（dim\_ 开头）

维度表采用单独规范，统一以 `dim_` 开头，并使用 `{scope}_{object}` 结构，例如 `dim_pub_area` 表示公共区域维度，`dim_asale_item` 表示商品维度。这种设计强调维度的跨主题复用能力。
- 5）中间表 mid\_：只服务作业过程，命名要“绑定目标表”

中间表需要与目标表强绑定，其命名方式通常为 `mid_{target_table}_{suffix}`。例如，为生成某张 DWS 表而创建的中间表，可以命名为 `mid_dws_xxx_01`，而用于补充维度的中间表则可以使用 `_dim` 后缀。这种方式可以清晰反映数据流转关系。
- 6）临时表 tmp\_：只允许测试验证（禁止进入生产依赖）

临时表则必须严格限制使用范围，统一以 `tmp_` 开头，仅用于开发或验证阶段，禁止进入生产依赖链路。
- 7）手工表（manual）：放在 DWD，显式标记人工维护

与此同时，对于人工维护的数据，可以在 DWD 层显式标记 `manual`，例如 `dwd_trade_manual_client_info_l`，以区分自动化与人工干预的数据来源。


## 字段与指标命名规范：通用规则 + 指标结构化命名 + 样例
- 1）字段命名公共规则（强制）

在字段层面，命名规范同样需要统一且严格执行。首先，所有字段必须采用小写字母加下划线分隔的形式，禁止使用驼峰命名。命名应优先保证可读性，而非追求简短；对于同一语义的字段，必须保持名称一致，通过词根统一来降低理解成本。
- 2）分区字段统一（避免全公司各玩各的）

分区字段需要在全局范围内统一标准，例如日期分区统一使用 `dt`，小时使用 `hh`，分钟使用 `mi`，并约定固定格式。这种统一不仅有助于开发效率，也能避免跨表使用时的混乱。
- 3）字段后缀统一：数量/金额/布尔（让人一眼识别类型）

字段后缀应当具备明确语义。例如，数量类字段统一使用 `_cnt`，金额类字段需在 `_amt` 或 `_price` 中二选一并全局统一，布尔类型字段统一采用 `is_` 前缀且不允许为空。这些约定能够让使用者在看到字段名时快速判断其数据类型与含义。
- 4）NULL 处理口径（字段语义必须可落地）

对于 NULL 值的处理，也需要在命名规范之外形成统一约定。通常，维度字段使用 `-1` 表示未知或未匹配，指标字段使用 `0` 表示无发生。这种设计可以避免在聚合计算过程中出现大量 NULL 传播问题，提高数据稳定性。
- 5）指标命名要结构化：业务修饰词 + 日期修饰词 + 聚合修饰词 + 基础指标

在指标命名方面，推荐采用结构化方式，将业务语义拆解为多个部分进行组合。一个完整指标通常由“业务修饰词 + 日期修饰词 + 聚合方式 + 基础指标”构成。例如，`trade_amt` 表示交易金额，`install_poi_cnt` 表示安装门店数量，而 `pay_succ_rate` 表示支付成功率。对于聚合类指标，应统一使用 `sum`、`avg`、`max`、`min` 等固定枚举，避免出现 total 等混用情况。
- 6）给一组“从字段到指标”的完整样例

以一个完整的数据流为例，可以更清晰地理解这一体系。在明细层，订单增量表可以命名为 `dwd_trade_order_i`，包含订单 ID、用户 ID、支付金额、订单状态及分区字段等基础信息。在汇总层，可以构建 `dws_trade_user_pay_1d`，按用户粒度汇总最近一天的支付情况，对应指标包括支付成功次数、支付金额总和及支付成功率。在最终交付层，则可以生成面向业务的指标看板表，如 `ads_fin_kpi_board_d`，用于展示 GMV、退款金额、净收入以及支付用户数等核心指标。

通过从表到字段再到指标的全链路规范，可以构建一个语义清晰、结构统一、易于协作的数据仓库体系。这种规范在初期可能增加一定约束成本，但从长期来看，是支撑数据规模化与团队协同的关键基础。

前文回顾👇：
* [（一）新兴数据湖仓架构搭建与开发规范全攻略：数据仓库与数据湖概述](https://mp.weixin.qq.com/s/xQDM6UbK_W9ZnrWq-bjdhQ)
* [（二）燃爆！AI 加持下，新兴数据湖仓架构与开发规范全解析！](https://mp.weixin.qq.com/s/RVlLiaWeUAICsvcnbHf56Q)
* [（三）ODS/明细层落地设计要点：把数据接入层打造成“稳定可运维”的基础设施](https://mp.weixin.qq.com/s/F600Xddbx5Yf7Fa3MWIzFQ)
* [（四）为什么你的数据仓库总在 ADS 层失控？DWS 才是关键答案](https://mp.weixin.qq.com/s/yOM8hGF-yMP8JQWV5o2ACQ)

下文预告👇：
（六）DataOps开发标准与建议


数据仓库做大之后，最先“失控”的往往不是数据，而是命名。命名规范看似细节，却直接决定了数据是否好找、好用、好维护。

（五）数据仓库越做越乱？问题可能出在“命名”上

数据库

大数据

架构设计

数据仓库命名规范是数据治理的关键环节，本文系统梳理了表与字段命名的最佳实践。从分层前缀、词根统一到周期编码，详细解析如何构建自解释的表名体系。涵盖常规表、中间表、临时表的命名模板，以及字段命名、指标结构化等规范，帮助团队建立清晰统一的数据协作标准，提升数据查找与维护效率。

数据仓库

数据治理

数据湖

数据流

2026采购季 | AI焕新·智启新局

bigdata-class

tchouse

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

（五）数据仓库越做越乱？问题可能出在“命名”上-腾讯云开发者社区-腾讯云

（五）数据仓库越做越乱？问题可能出在“命名”上

（五）数据仓库越做越乱？问题可能出在“命名”上

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐