语言 Chinese, Simplified

SEO Title

命名约定是确保正确编目、开发一致性和更快入职体验的第一步。然而，它们往往被忽视，直到后期，团队在重构上投入了大量时间——我们都知道这会导致什么。

本文档提出了一组基本约定，用作数据仓库命名约定的模板，从而确保从数据工程项目一开始就执行这些标准。

太长，读不下去了该文档将带我们了解四种不同对象类型的命名约定：

为什么命名约定很重要？

当寻找一个特定的属性或理解它的含义时，只需看看它们的命名方式就变成了一项简单的任务。在考虑数据团队的存在以支持业务时，这无疑是一个需要考虑的关键方面。花在阅读这些属性上的时间将多于写这些属性。

很难以清晰简单的形式命名表、维度或属性？难以包含支持相同属性变化的附加修改器？命名约定确保开发人员在名称上花更少的时间进行创造性开发，并且可以简单地专注于开发代码。

此外，具有明确的约定有助于开发人员确保意义不会丢失，包括适当的粒度。

清晰的流程通常是加入新团队成员并确保他们从早期就尽可能高效的最快方式。强制执行命名约定是快速加入的另一部分，因为它有助于不必纠缠于属性含义，只需遵循文档并理解设计决策。

存储命名约定

随着Lakehouse等现代数据存储平台的出现，确保从一开始就满足标准变得越来越重要，而不仅仅是在表示层。

当在湖中存储数据时——S3，Blob存储——应该根据相应的阶段遵循一种模式。

从模式到Blob的所有对象都应该遵循四个主要的命名约定：

尽可能使用单个名称
- –例如，common not commons
使用小写名称
- –例如，common not COMMON
使用下划线连接多个单词
- –例如。data_source not datasource
保持对象名称简短但清晰，最好不超过10个字符
- –例如dw_aggreation not data_warehouse_aggregation_layer
与时间相关的对象应以位置表示法存储，以便于查找过程
- –例如， when referring to January, use 01 instead of 1

存储结构在很大程度上取决于相关联的层。然而，考虑一下青铜层作为水槽的情况。这些通常按来源或组件划分。考虑到这一点，该结构应反映捕获多个来源并根据特定时间范围过滤相关数据的能力。

注意：这不适用于Delta和Hudi等格式，因为在这种情况下，您应该努力将所有内容保持在一个单一的公共结构下

青铜存储模式应遵守以下规则：

bronze/%component_name%/%year%/%month%/%day%/%hour%/%minute%/%second%/%source_name%.parquet

例如，如果我们考虑作为水槽的青铜层，用于Shopify提取：

当使用Silver层时，会出现类似的模式，这一次，忽略了元数据直接注入存储层的时间——Delta、Hudi、Iceberg：

应根据确定对象类型的后缀来区分对象类型。这种方法背后的理由是允许类似的对象在同一模式中共存，同时使用逻辑（视图）实例来抽象对物理（表）资源的访问。这使得能够在不影响最终结果的情况下对物理实例（表）进行有效管理。

	Object Type	Suffix Notation	Example
	Table	%table_type%_table_name_%_t%	dim_customer_t
	View	%table_type%_table_name_%_v%	dim_customer_v

表命名约定是帮助数据编目过程的一个关键方面。适当的表命名约定可以帮助利益相关者和开发人员，促进前一种情况下的发现过程，并确保在后一种情况中开发时尊重粒度。

Object Type	Prefix Notation	Example	Format
Dimension	dim_%name%_ %object_type%	dim_customer_t	Use singular names; customer not customers; Note: if the dimension contains historical records (e.g.SCD2) a _hist prefix should be added after dim_
Transaction Fact	fact_%name% _%object_type%	fact_orders_t	Use plural names; orders not order
Snapshot Fact	fact_%name%_% snapshot_level% _%object_type%	fact_inventory_weekly_t	Use the single form of the adverb to represent the snapshot level to help differentiate from other objects containing the verb; e.g. fact_inventory_weekly_t not fact_inventory_week_t
Accumulating Snapshot Fact	fact_%name%_process _%object_type%	fact_orders_process_t
Bridge	brt_%base_name%_to_% target_name% _%object_type%	brt_diagnosis _to_group_t

明确的属性约定可以说是确保您的资源明确并随时可供利益相关者使用的最重要步骤之一。它们是确保您不会被问到以下问题的第一步：

我想知道订单的数量，我应该使用哪一列？订单数量还是订单金额？

属性约定必须由开发人员和利益相关者共同执行，需要不断的沟通和方法来确保操作概念与数据仓库相匹配。

Attribute Type	Format	Example
Natural Key (Operational Key)	%column_name%_nk	customer_nk
Surrogate Key	%dim_name%_id	date_id
Foreign Key	%dim_name%_id	time_id
Degenerate Dimension	dd_%field_name%	dd_order_number
Date	%field_name%_date	order_created_date
Timestamp	%field_name%_at	order_created_at
Time	%field_name%_time	order_created_time
(Textual) Booleans	is_%field_name%	is_valid
Amount (monetary amount)	%field_name%_amt	product_price_amt
Percentage (Between 0 and 1)	%field_name%_pct	conversion_rate_pct
Number (quantity)	%field_name%_qty	order_qty
Local Currency/Time/Entity	%field_name%_local_%dim_name%	local_currency_id
Standard Currency/Time/Entity	%field_name%_standard_%dim_name%	standard_currency_id

通常情况下，尤其是在处理财务数据时，我们发现自己不断重复使用相同的后缀来确定特定类型的修饰符。例如，除了时间增量计算之外，还包括包含或排除运算符。

本节重点介绍可以与任何属性命名约定结合使用的修饰符缩写。

Object Type	Format	Example
Discount	%field_name%_dct	order_product_sale_dct_amt
Excluding	%field_name%_exc	order_product_price_exc_vat_amt
Difference / Elapsed Time	%field_name%_delta	order_to_shipped_delta_hours_qty