数仓规范：命名规范如何设计？

0 前言

1 表命名规范

2 字段命名规范

3 任务命名规范

4 层级命名规范

5 自定义函数命名规范

6 视图和存储过程的命名规范

7 综合案例分析

8 常见陷阱和如何避免

9 工具和最佳实践

10 小结

想进一步了解数仓建设这门艺术的，可以订阅我的专栏数字化建设通关指南，将在该专栏进行详细解析。

专栏原价99，现在活动价39.9，按照阶梯式增长，还差3个名额将上升至59.9，直到恢复原价。

数字化建设通关指南

0 前言

数据仓库建设的目的仍是为了下游应用，因此，降低下游用户的应用成本是至关重要的。下面这些问题，你可以看看是否遇到过。很多表名非常类似，涉及各个层级的数据，也不知道粒度如何，用起来非常混乱！表内的字段名特别乱，甚至不同表中相同含义字段的命名不一致！任务名与表名差异很大，很难找到表对应的调度任务是哪一个！以上这些问题，都是由于命名不规范所导致的。那规范的命名又包括哪些方面呢？下面，我们一起来看一下。

1 表命名规范

表命名，核心原则是“见名知意”，通过规范的标准，降低用户的识别成本。表命名的通用方式为[数据分层]_[业务域]_[内容描述]_[刷新周期]_[存储策略]

1.1 前缀命名
维表命名形式：dim_描述
事实表命名形式：fact_描述_[AB]
临时表命名形式：tmp_ 正式表名_ [C自定义序号]
宽表命名形式：dws_主题_描述_[AB]
备份表命名形式：正式表名_bak_yyyymmdd
表命名解释：

1）表名使用英文小写字母，单词之间用下划线分开，长度不超过40个字符，命名一般控制在小于等于6级。
2）其中ABC第一位"A"时间粒度：使用"c"代表当前数据，"h"代表小时数据，"d"代表天数据，"w"代表周数据，"m"代表月数据，"q"代表季度数据， "y"代表年数据。
3）其中ABC的第二位"B"表示对象属性，用"t"表示表，用"v"表示视图。
4）其中ABC的第三位"C"自定义序号用于标识多个临时表的跑数顺序。

1.2 注释
注释要结合表的英文名，要求注释简洁明了，体现出表的业务出处、主题和用途。

1.3 存储格式
所谓的存储格式就是在Hive建表的时候指定的将表中的数据按照什么样子的存储方式，如果指定了方式，那么在向表中插入数据的时候，将会使用该方式向HDFS中添加相应的数据类型。在数仓中建表默认用的都是PARQUET存储格式，相关语句如下所示：

STORED AS INPUTFORMAT

‘org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat’

OUTPUTFORMAT

‘org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat’

1.4 字符集
Hadoop和hive 都是用utf-8编码的，在建表时可能涉及到中文乱码问题，所以导入的文件的字符编码统一为utf-8格式。

1.5 约定
理论上在数仓落地的表不应该出现null未知类型，对于可能出现null的字段，如果为字符型统一为空字符串，如果是数值则给0。

1.6 刷新周期

1.7 存储策略

8 来源系统：如果数据来自特定的源系统，可以在名称中标注。
例如：_erp、_crm、_pos

示例：

-- 创建订单事实表（每日粒度）
CREATE TABLE fact_order_daily (
    order_id INT,
    customer_id INT,
    order_date DATE,
    total_amount DECIMAL(10,2),
    -- 其他字段...
);

-- 创建客户维度表
CREATE TABLE dim_customer (
    customer_id INT,
    customer_name VARCHAR(100),
    customer_email VARCHAR(100),
    -- 其他字段...
);

-- 创建来自ERP系统的库存汇总表（月度粒度）
CREATE TABLE dws_inventory_monthly_erp (
    product_id INT,
    warehouse_id INT,
    month_date DATE,
    avg_stock_qty INT,
    -- 其他字段...
);

-- 创建临时表用于数据处理
CREATE TABLE tmp_order_analysis (
    -- 临时分析用字段...
);

注意点：

全小写：使用全小写字母，避免大小写敏感性问题。
下划线连接：使用下划线 _ 连接不同的单词，提高可读性。
避免特殊字符：不要使用空格、横杠或其他特殊字符。
长度限制：表名长度应控制在64个字符以内，以适应大多数数据库系统的限制。

2 字段命名规范

字段命名作用同表命名作用一致，同样是为了减少应用上的歧义。字段命名需要遵循以下几项原则。

字段名需含义清晰，唯一解释，不可出现同名不同义的情况。
字段名建议用英文简写，不建议用拼音，更不建议用拼音简写。
字段名一律小写，避免出现混乱的情况。·
字段名各单词间用下画线进行分割。字段名长度不宜过长，建议控制在20个字符以内。

1)修饰词

修饰词是对指标场景的描述，例如PV是一个原子指标，那么主页PV、列表页PV、详情页PV就是在PV基础上增加的修饰词，将原子指标包装成一个用于描述特定场景的数据。

2)原子指标

原子指标可以理解为指标的内核、业务指标的最小颗粒度，例如PV、UV、人均PV、人均时长等。根据指标的类型，原子指标的命名规范如图3-20所示。

3）时间修饰

大多数情况下，指标描述的是当日的数据表现，但仍有些应用场景，需要记录过去或者未来一段时间的表现情况。例如，过去7日搜索PV、过去第7日搜索PV、未来7日搜索PV、未来第7日搜索PV等。对于这种需要跨度的时间修饰，命名需要遵循一定原则，用以区分过去／未来、N日内／第N日，如图所示。

3）派生指标

4）衍生指标

注意点：

（1）前缀使用：对于特定类型的字段，可以使用前缀。

is_ 表示布尔值（例如：is_active）
has_ 表示布尔值（例如：has_children）
num_ 表示计数（例如：num_orders）
pct_ 表示百分比（例如：pct_discount）
amt_ 表示金额（例如：amt_total）

时间字段：对于时间相关的字段，使用统一的命名方式。

date 后缀表示日期（例如：order_date）
time 后缀表示时间（例如：login_time）
timestamp 后缀表示时间戳（例如：create_timestamp）

主键：主键字段通常使用 id 作为后缀。

例如：customer_id、order_id
外键：外键字段应与引用表的主键名称保持一致。

例如：如果 customer 表的主键是 customer_id，那么在 order 表中引用它的外键也应该叫 customer_id

全小写：使用全小写字母。

下划线连接：使用下划线 _ 连接不同的单词。

避免保留字：不要使用数据库的保留字作为字段名。

避免缩写：除非是广为人知的缩写（如 ID），否则应使用完整单词。

一致性：相同含义的字段在不同表中应保持一致的命名。

示例：

CREATE TABLE fact_order (
    order_id INT PRIMARY KEY,
    customer_id INT,  -- 外键，引用 dim_customer 表
    order_date DATE,
    order_timestamp TIMESTAMP,
    total_amount DECIMAL(10,2),
    num_items INT,
    is_paid BOOLEAN,
    payment_method VARCHAR(50),
    discount_pct DECIMAL(5,2),
    shipping_amt DECIMAL(8,2),
    has_gift_wrap BOOLEAN,
    -- 其他字段...
);

CREATE TABLE dim_customer (
    customer_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    customer_email VARCHAR(100),
    registration_date DATE,
    is_active BOOLEAN,
    last_login_timestamp TIMESTAMP,
    lifetime_value DECIMAL(12,2),
    -- 其他字段...
);

在这个例子中，我们可以看到：

字段名清晰描述了其内容（例如 total_amount、num_items）
使用了适当的前缀（例如 is_paid、discount_pct）
时间相关字段使用了统一的后缀（_date、_timestamp）
主键和外键的命名保持一致（customer_id）
所有字段名都是小写并使用下划线连接
通过遵循这些规则，我们可以创建出清晰、一致且易于理解的数据模型，大大提高了数据仓库的可用性和可维护性。

3 任务命名规范

表的生成代码往往需要配置一个调度任务加以完成，这里需要注意，调度任务命名需与表命名一致，建议采用相同的名称，如果已被占用，建议使用表命名作为基准，增加后缀作为任务命名，方便后续查找应用。

命名规范

ETL 脚本名称尽可能和所产出的表同名；
数据采集、数据推送脚本尽可能标识数据去向；
ETL 脚本若产生多个表，采用对应的数据域和语义描述命名；
Jar 包命名以实际的业务处理逻辑语义描述为主，调度任务命名同样尽量以产出表名命名根据脚本命名规范。

具体实例
我们对如下的脚本进行命名：

数据导出脚本命名：
dws_jttl_pull_month_tmp_exp.sh，其中exp表示向外导出用于标识方向

ETL过程脚本命名：
dws_jttl_pull_month.sh

一个ETL脚本产生多个表：
dws_phm_switchshock_min_hh_mm.sh

该脚本文件描述了按分钟、小时、月份转辙机振动的监控数据。说明了该脚本有三张表

一张按分钟统计的表，一张按小时统计的表、一张按月份统计的表。

调度任务命名：
dws_jttl_pull_day

4 层级命名规范

参考

5 自定义函数命名规范

自定义函数命名规范在表的生成过程中，一般会用到SQL的内置函数，然而在面对一些复杂逻辑，内置函数无法满足需求时，往往需要自己创建函数，以满足对应的应用场景。为了便于应用及管理，自定义函数命名需要遵循一定规范。自定义函数命名的通用方式为[业务域]_udf/udaf/udtf_[内容描述]，以“城市等级划分函数”为例，如图所示。

6 视图和存储过程的命名规范

视图和存储过程是数据仓库中重要的对象，它们的命名同样需要遵循一定的规范，以确保整个系统的一致性和可读性。

（1）视图命名规范

前缀使用：使用 v_ 作为视图的前缀。
目的描述：在前缀后添加描述视图目的或内容的词语。
数据粒度：如果视图代表特定的数据粒度，可以在名称中体现。
全小写：使用全小写字母。
下划线连接：使用下划线 _ 连接不同的单词。

-- 创建一个展示每日销售汇总的视图
CREATE VIEW v_sales_daily_summary AS
SELECT 
    order_date,
    SUM(total_amount) as daily_sales,
    COUNT(DISTINCT customer_id) as unique_customers
FROM fact_order
GROUP BY order_date;

-- 创建一个展示高价值客户的视图
CREATE VIEW v_high_value_customers AS
SELECT *
FROM dim_customer
WHERE lifetime_value > 10000;

（2）存储过程命名规范

前缀使用：使用 p_ 作为存储过程的前缀。

动作描述：在前缀后添加描述存储过程主要动作的动词。

对象描述：在动作后添加存储过程操作的主要对象。

全小写：使用全小写字母。

下划线连接：使用下划线 _ 连接不同的单词。

-- 创建一个更新客户终身价值的存储过程
CREATE PROCEDURE p_update_customer_lifetime_value
AS
BEGIN
    -- 存储过程的具体实现
END;

-- 创建一个生成每月销售报告的存储过程
CREATE PROCEDURE p_generate_monthly_sales_report
    @year INT,
    @month INT
AS
BEGIN
    -- 存储过程的具体实现
END;

7 综合案例分析

假设我们正在为一家在线零售公司构建数据仓库，主要包括订单、客户、产品和销售等数据。

-- 创建数据库
CREATE DATABASE prod_ecommerce_dw_v1;

USE prod_ecommerce_dw_v1;

-- 创建维度表
CREATE TABLE dim_customer (
    customer_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    customer_email VARCHAR(100),
    registration_date DATE,
    is_active BOOLEAN,
    last_login_timestamp TIMESTAMP
);

CREATE TABLE dim_product (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(200),
    category_id INT,
    category_name VARCHAR(100),
    brand_name VARCHAR(100),
    unit_price DECIMAL(10,2)
);

-- 创建事实表
CREATE TABLE fact_order (
    order_id INT PRIMARY KEY,
    customer_id INT,
    order_date DATE,
    order_timestamp TIMESTAMP,
    total_amount DECIMAL(12,2),
    num_items INT,
    is_paid BOOLEAN,
    payment_method VARCHAR(50),
    dt STRING
)
PARTITIONED BY (dt);

-- 创建汇总表
CREATE TABLE dws_daily_sales (
    dt STRING,
    total_sales DECIMAL(15,2),
    total_orders INT,
    avg_order_value DECIMAL(10,2),
    num_unique_customers INT
)
PARTITIONED BY (dt);

-- 创建视图
CREATE VIEW v_top_selling_products AS
SELECT 
    p.product_id,
    p.product_name,
    SUM(fo.num_items) as total_sold,
    SUM(fo.total_amount) as total_revenue
FROM fact_order fo
JOIN dim_product p ON fo.product_id = p.product_id
GROUP BY p.product_id, p.product_name
ORDER BY total_sold DESC
LIMIT 100;

-- 创建存储过程
CREATE PROCEDURE p_update_daily_sales_summary(IN target_date DATE)
BEGIN
    INSERT INTO dws_daily_sales
    SELECT 
        DATE_FORMAT(target_date, '%Y%m%d') as dt,
        SUM(total_amount) as total_sales,
        COUNT(DISTINCT order_id) as total_orders,
        AVG(total_amount) as avg_order_value,
        COUNT(DISTINCT customer_id) as num_unique_customers
    FROM fact_order
    WHERE DATE(order_date) = target_date;
END;

在这个案例中，我们可以看到：

数据库名称 prod_ecommerce_dw_v1 清晰地表明了这是生产环境的电子商务数据仓库，版本为1。

维度表使用 dim_ 前缀，如 dim_customer 和 dim_product。

事实表使用 fact_ 前缀，如 fact_order。

汇总表使用 dws_ 前缀，如 dws_daily_sales。

所有表和字段名都使用小写字母和下划线。

视图使用 v_ 前缀，如 v_top_selling_products。

存储过程使用 p_ 前缀，如 p_update_daily_sales_summary。

分区字段使用 dt，格式为 yyyymmdd。

8 常见陷阱和如何避免

在实施数据仓库命名规范时，有一些常见的陷阱需要注意：

过度缩写：为了节省空间而过度使用缩写可能导致命名难以理解。
避免方法：除非是广为人知的缩写，否则尽量使用完整词汇。
不一致性：在不同的表或模块中使用不同的命名风格。
避免方法：制定详细的命名指南，并定期审查以确保一致性。
使用特殊字符：在名称中使用特殊字符可能导致SQL语句编写困难。
避免方法：仅使用字母、数字和下划线。
使用保留字：使用数据库的保留字作为对象名称。
避免方法：熟悉所使用数据库系统的保留字列表，避免使用这些词。
忽视业务含义：纯粹从技术角度命名，忽视业务含义。
避免方法：在命名时考虑业务用户的理解，使用业务术语。
命名过长：创建过长的名称，超出数据库系统的限制。
避免方法：在保证清晰的前提下，控制名称长度，通常不超过64个字符。
重复信息：在字段名中重复表名中已包含的信息。
避免方法：例如，在 customer 表中，不要使用 customer_name，直接用 name 即可。
使用数字前缀：某些数据库可能不支持以数字开头的标识符。
避免方法：始终以字母开头命名。
忽视未来扩展：命名不考虑未来可能的扩展需求。
避免方法：设计命名方案时考虑可能的未来变化，预留扩展空间。
混用大小写：在一些大小写敏感的数据库中可能导致问题。
避免方法：统一使用小写，即使在不区分大小写的数据库中也是如此。

通过注意这些陷阱并采取相应的避免措施，我们可以创建一个更加健壮和可维护的数据仓库命名系统。

9 工具和最佳实践

为了更好地实施和维护数据仓库命名规范，我们可以利用一些工具和最佳实践：

数据字典：维护一个详细的数据字典，记录所有表、字段的名称、含义和用途。

工具推荐：Confluence, Microsoft Excel, Dataedo

命名规则检查器：使用自动化工具检查命名是否符合规范。

工具推荐：SQL Prompt, ApexSQL Refactor

版本控制：使用版本控制系统管理数据库脚本和文档。

工具推荐：Git, SVN

自动化文档生成：使用工具自动生成数据库文档，包括表结构、关系图等。

工具推荐：Dataedo, SchemaSpy

代码审查：实施严格的代码审查流程，确保新添加的对象符合命名规范。

工具推荐：GitHub, GitLab, Bitbucket

培训和指南：为团队成员提供详细的命名规范指南和培训。

定期审计：定期审查数据仓库对象，确保它们持续符合命名规范。

元数据管理：使用元数据管理工具来维护和管理数据仓库的结构信息。

工具推荐：Alation, Collibra

命名模板：创建标准化的命名模板，特别是对于复杂的对象如存储过程和视图。

自动化重命名工具：使用工具批量重命名不符合规范的对象。

工具推荐：ApexSQL Refactor, Redgate SQL Prompt

示例：使用Python脚本检查表名是否符合规范

import re

def check_table_name(name):
    pattern = r'^(dim|fact|dws|ods|tmp)_[a-z0-9_]+$'
    if re.match(pattern, name):
        return True
    else:
        return False

# 测试
table_names = ['dim_customer', 'FACT_ORDER', 'dws_daily_sales', 'TempTable']
for name in table_names:
    if check_table_name(name):
        print(f"{name} is valid")
    else:
        print(f"{name} is not valid")

通过使用这些工具和最佳实践，我们可以更有效地实施和维护数据仓库命名规范，提高整个团队的工作效率和数据质量。

参考链接：https://blog.csdn.net/u012955829/article/details/142420972