弗兰的悲惨之旅
99.73M · 2026-04-04
数据仓库做大之后，最先“失控”的往往不是数据，而是命名。命名规范看似细节，却直接决定了数据是否好找、好用、好维护。
作为数据湖仓设计与实践系列文章第 5 篇，本文从实际使用出发，梳理了表与字段命名的核心方法，通过分层前缀、词根统一和周期编码，让表名更自解释；同时结合指标命名与治理流程，帮助构建清晰、可协作的数据体系。
在数据仓库体系中，命名规范并不是形式问题，而是直接影响协作效率与数据质量的基础设施。一个好的命名体系，核心目标只有一个——让表名本身就携带足够多的信息，使人无需额外查文档，就能理解这张表“是什么、从哪来、怎么用”。
理想状态下，一个表名应当能够被“一眼读懂”，至少包含以下关键信息：数据分层、归属团队、业务域、主题域、核心对象含义，以及更新周期或数据范围。当这些信息被规范地编码进表名后，查找数据、理解口径、排查问题甚至团队交接都会变得更加高效，显著降低沟通成本。
要实现这一点，命名体系必须建立在统一的“词根体系”之上。本质上，这是在统一团队的业务语言。例如，同一个业务对象必须使用同一个词根，不能在不同表中混用不同表达（如 rack 和 shelf）。同样，指标命名也需要统一规则，例如所有“率类指标”统一使用 _rate 后缀，避免 ratio、percent、rt 等混用带来的歧义。
此外，数据分层前缀必须强制规范。通过前缀，使用者可以第一时间判断这张表所处的层级及其用途：ods_ 表示贴源数据，dwd_ 表示标准明细层，dws_ 表示公共汇总层，ads_ 面向应用交付，而 dim_ 则用于统一维度。这种前缀不仅是命名规则，更是数据分层设计的直接体现。
另一个容易被忽视但非常关键的点是，更新周期或数据范围必须显式体现在表名中。例如 _1d 表示最近一天，_td 表示截至当日，_7d 表示最近七天。这种设计可以有效避免“同名表但时间口径不同”的问题，是防止指标误用的重要手段。
在资产管理层面，还需要明确区分不同类型的表。正式表是可长期维护的数据资产；中间表仅服务于作业过程，应设置保留策略；临时表则只用于一次性验证，禁止进入生产链路。通过在命名中引入 mid_ 与 tmp_ 前缀，可以从源头避免数据资产污染。
最后，命名规范必须与数据治理流程绑定。任何新增表或字段，都必须同步补齐元数据，包括负责人、字段含义、指标口径、更新频率、依赖关系及生命周期。缺乏这些信息的“裸表”，在短期内或许可用，但从长期看几乎一定会演变为技术债。
在落地过程中，应优先固化统一模板，保证关键字段（如层级、业务域、周期）强制一致，同时允许在非关键部分保留适度灵活性，以兼顾规范性与实际需求。
在具体实践中，表命名需要有清晰的结构化模板，以确保信息表达完整且一致。通用的命名模板可以定义为：{layer}_{dept}_{biz_domain}_{subject}_{object}_{cycle_or_range}
这一结构中，各部分承担明确职责：layer 表示数据分层，dept 表示团队归属，biz_domain 表示业务域，subject 是分析视角下的主题抽象，object 表示具体对象或行为，而 cycle_or_range 则用于标识数据的时间范围或更新周期。
其中，周期与范围的编码尤为关键。常见表达包括 _1d（最近一天）、_td（截至当日）、_7d 或 _30d（最近 N 天）。此外，还可以通过附加标识区分数据类型或更新方式，例如 d 表示日级快照，w 表示周级数据，i 表示增量表，f 表示全量表，l 表示拉链表。这些约定能够帮助使用者快速理解数据的时间语义。
以汇总层为例，可以参考如下命名方式：dws_asale_trd_byr_subpay_1d 表示买家粒度、交易分阶段付款、最近一天汇总数据；dws_asale_trd_itm_slr_hh 则表示卖家视角下的商品小时级汇总。这类命名虽然较长，但信息完整且具备高度可读性。
维度表采用单独规范，统一以 dim_ 开头，并使用 {scope}_{object} 结构，例如 dim_pub_area 表示公共区域维度，dim_asale_item 表示商品维度。这种设计强调维度的跨主题复用能力。
中间表需要与目标表强绑定，其命名方式通常为 mid_{target_table}_{suffix}。例如，为生成某张 DWS 表而创建的中间表，可以命名为 mid_dws_xxx_01，而用于补充维度的中间表则可以使用 _dim 后缀。这种方式可以清晰反映数据流转关系。
临时表则必须严格限制使用范围，统一以 tmp_ 开头，仅用于开发或验证阶段，禁止进入生产依赖链路。
与此同时，对于人工维护的数据，可以在 DWD 层显式标记 manual，例如 dwd_trade_manual_client_info_l，以区分自动化与人工干预的数据来源。
在字段层面，命名规范同样需要统一且严格执行。首先，所有字段必须采用小写字母加下划线分隔的形式，禁止使用驼峰命名。命名应优先保证可读性，而非追求简短；对于同一语义的字段，必须保持名称一致，通过词根统一来降低理解成本。
分区字段需要在全局范围内统一标准，例如日期分区统一使用 dt，小时使用 hh，分钟使用 mi，并约定固定格式。这种统一不仅有助于开发效率，也能避免跨表使用时的混乱。
字段后缀应当具备明确语义。例如，数量类字段统一使用 _cnt，金额类字段需在 _amt 或 _price 中二选一并全局统一，布尔类型字段统一采用 is_ 前缀且不允许为空。这些约定能够让使用者在看到字段名时快速判断其数据类型与含义。
对于 NULL 值的处理，也需要在命名规范之外形成统一约定。通常，维度字段使用 -1 表示未知或未匹配，指标字段使用 0 表示无发生。这种设计可以避免在聚合计算过程中出现大量 NULL 传播问题，提高数据稳定性。
在指标命名方面，推荐采用结构化方式，将业务语义拆解为多个部分进行组合。一个完整指标通常由“业务修饰词 + 日期修饰词 + 聚合方式 + 基础指标”构成。例如，trade_amt 表示交易金额，install_poi_cnt 表示安装门店数量，而 pay_succ_rate 表示支付成功率。对于聚合类指标，应统一使用 sum、avg、max、min 等固定枚举，避免出现 total 等混用情况。
以一个完整的数据流为例，可以更清晰地理解这一体系。在明细层，订单增量表可以命名为 dwd_trade_order_i，包含订单 ID、用户 ID、支付金额、订单状态及分区字段等基础信息。在汇总层，可以构建 dws_trade_user_pay_1d，按用户粒度汇总最近一天的支付情况，对应指标包括支付成功次数、支付金额总和及支付成功率。在最终交付层，则可以生成面向业务的指标看板表，如 ads_fin_kpi_board_d，用于展示 GMV、退款金额、净收入以及支付用户数等核心指标。
通过从表到字段再到指标的全链路规范，可以构建一个语义清晰、结构统一、易于协作的数据仓库体系。这种规范在初期可能增加一定约束成本，但从长期来看，是支撑数据规模化与团队协同的关键基础。
前文回顾uD83DuDC47：
下文预告uD83DuDC47：（六）DataOps开发标准与建议
",
