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

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

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

• -文件存储命名约定——如何命名和构造数据湖的文件存储
• -数据对象命名约定--为表和视图等数据对象命名
• -表命名约定——按照Kimball模式设计命名表
• -属性（列）命名约定
• -列命名惯例（缩写）

为什么命名约定很重要？

• 它提高了可读性。
• 它加快了发展。
• 加入新的团队成员会更快。

它改进了发现过程

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

它加快了开发

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

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

新的团队成员加入

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

存储命名约定

随着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提取：

• bronze/shopify/2023/01/09/12/40/12/shopify.parquet

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

• silver/%component_name%/%partitions%/%source_name%.parquet

数据对象命名约定

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

表命名约定

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

属性（列）命名约定

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

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

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

属性命名约定（缩写）

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

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

参考

• Kimball Naming Conventions
• Kirill Andriychuk’s Linkedin page