数据仓库表的标准和规范关注点

Posted 2021-04-24 木东居士

0x00 前言

标准和规范总不像一个数学公式那样黑白分明，它的概念总是显得抽象和模糊。因此，并不存在真正意义上的标准和规范，而是指的从业人员相互之间的约定积累，以及在工作中达成共识的结论。

我们接到一个数据需求，小A同学想要分析调研自家app内的功能模块的订单数据情况，例如常见的首页有一个顶部广告位，可以放广告素材，这个广告位可以承接多种的运营活动和产品导流需求。现在我要为小A同学拿到这个广告的交易订单数据支持她做数据分析，但是我可能是一个新人，也可能早先并不接触这块业务，因此在整个接手项目过程中会非常吃力，大家尝尝会有这样的痛处，换位思考一下我们各自的产出是否也会对他人造成同样的困扰？

因此，那些核心的数据，对业务影响很大的数据需求，我们应该尽可能的保证其质量，为自己的团队树立口碑，更好的服务业务于数据方的需要，做到沟通成本的降低和项目返工的几率。基于以上的原则，制定数据仓库的交付标准，规范项目的交付流程就是对自己数据仓库搭建的标准和规范的整理。也由此可以看出我们的需求方可能是数据研发工程师，也可能是数据分析师，甚至是一位产品经理，他们份数不同的角色，拥有不同的能力模型。对此我们的交付物标准可针对不同的角色归纳总结一下大致为：数据表、表结构的说明文档、使用指南（甚至不仅限于文档，还可以是视频）、数据质量报告、数据培训资料或课程。

0x01 举个例子

其中关于数据表和表结构的说明文档大致包含以下信息：

• 数据表名称

• 数据表中文名称

• 数据表描述

• 数据字段说明（字段名称、字段类型、字段描述、取值规范（示例&范围）、备注）

举个栗子：

• 数据表名称：xxx.oder

• 数据表中文名称：xxx广告业务订单数据表

• 数据表描述：xxx业务订单数据，数据来源于xxx业务系统。为订单数据的全量表，包含订单流水记录，订单状态没更新一次生成一条数据，T+1调入入库。

• 数据字段说明示例如下：

字段名称（cod_name）	类型（data_type）	字段描述（comment）	取值规范（示例&范围）	备注
order_id	bigint	订单id	212345532445	空
busi_id	string	订单的业务分类，a代表xxx，b代表xxx	a	空
city_id	string	商品的所属城市id	1	全国性的为-1
city_name	string	商品的所属城市名称	北京市	全国性的为-1
order_souce	string	订单来源，标记来源与数据埋点	xxx代表app首页顶通广告	xxx

• 使用说明：......

根据以上示例，我们就可以反复的研究推敲什么能沉淀，什么是可以成为数据仓库表的标准和规范。以这个示例出发，我们常见的问题会有哪些？

0x02 交付标准

交付的标准可以从三个角度来考虑：交付基本信息、交付物的标准和规范、流程标准和规范。

一、交付基本信息

• 就绪时间：按照需求方和当前公司集群环境提供合理的就绪时间保证约定

• 数据可用：标注关键字段说明以及关键字段适用范围、可用标准。比如关键字段的格式，数据生成条件，空置率（空置的原因），有效枚举值范围（枚举值颗粒度），以及常见关联表字段的关联关系（映射）

• 历史问题：数据可用的起止日期（是否需要回溯数据），历史上的主要变动和口径变动记录。

• 表结构说明：对各个字段或者关键字段的字段名称、字段类型、字段描述、取值规范（示例&范围）使用说明

二、交付物的标准和规范

1. 数据表的命名规则

数据表的命名规则不仅要遵从整个数据仓库的标准和规范，也应该有自己的特殊要求。示例中我们提到的表名称为xxx.oder，这个显然是缺乏优秀可言的，公司或者事业群甚至业务范畴内必定存在多种多样的订单表，均不能可能仅靠库名区分，也不可先到先得的抢订关键字。

为了应对负责的业务和组织关系，表的命名最佳选择是能够表明其从属和业务关系，仅此在公司范围或者事业群、业务范围内应该给予一个标准规范使大家遵循。例如格式规则：库名.fact业务库名称主题简称[二级主题简称]自定义表名，类似的思路可提高用户快速的对数据表产生范畴概念，且避免上述诸多问题。

2. 数据表中文名称

同理<数据表的命名规则>，很多人是无法忍受“订单表”这个名称的，没有人期望看到数据仓库中成百上千的订单表。因此中文的名称也应该足够的定语去描述，例如xxx业务订单表。

3. 数据表的描述

在使用数据表的过程中，最大的困惑是对表的认识不足。在没有任何交流和业务铺垫知识的情况下，描述可能是作为唯一的发言权存在文档描述中的，对于表的描述应该尽可能全的去介绍这张表是什么，生成的条件，适用的范围。

4. 数据字段字段说明

数据表中最重要的是对各个字段，尤其是关键字段的文字说明。数据中多数的问题都是错误的字段理解不到位或者无解而产生的。对于字段的描述常见的问题会很多，这块内容如果能配套一个系统去做，是我当前能想到最好的办法，但是目前还未发现哪家公司有过尝试。

• a、字段名称：“order_id”，“orderid”，“id”，“xxx_oder_id”同一业务各自采用不同的命名，长久来看使用者经常会内心疑问字段是否确为xxx。在A表中的“order_id”是否对应B表中的“id”。或者表表内同时出现“order_id”，“id”，和“xxx_oder_id”。用于会常有疑虑三者之前的关系。

• b、维度枚举值：统一枚举值的规范，包含枚举值文字对齐、编码对齐、颗粒度对齐。例如我们对订单的业务的商家分类有付费商家（编号0）、免费商家（编号1），然而可能已经在其他的业务范围内有其他的不同体现，我们的中文值叫做“付费”，“合作商家”，“协议商家”，而不叫“付费商家”。我们的颗粒度不一致，其他的业务范围内分为框架付费客户，第三方合作商户、协议用户（有协议但不付费）、xxx类型付费商家、高潜商家，意向商家。我们的编码是0和1，其他的业务范畴是y和n。

• c、字段类型：是否经常因为类型和语言的特性导致数据计算错误，尤其在我们刚成为职场新人的时候，这种现象屡见不鲜，数据仓库中很多字段对与类型并不敏感，因此可能会导致同样的字段信息在不同的数据表中属于不同的类型。

• d、字段描述：应尽可能的描述字段，对应维度等有效的枚举值列出所有的枚举项，对于数量大的字段应该结合和面的字段格式描述字段实际涨什么样子，或者对值进行归类。

• e、取值规范（示例&范围）：以时间为例，准确的给出一个实例，有效区分”20181010“，”2018-10-10“，”2018-10-10 23：30“，还是它实际为一个时间戳。以城市维度为例它可能是“北京市”，也可能是“北京”。城市在关联的时候颗粒度也还可能是行政区的地级市维度表，也还可能是产品本身的城市维度表（本身可能以更小的行政区颗粒度作为城市同级别处理）。

综上所述，我们会有所启发，表的标准和规范主要是为了更全面的介绍表，消除歧义和使用过程中的疑虑。表的规则并非生搬硬套，而是根据公司和部门内部长期达成的共识而积累产生的。在上述的几点问题中，可以不断的延伸出表规范：

1. 使用有意义的英文词汇，约定俗成的词汇；

2. 合理的范围长度；

3. 通用型的简写，或者尽量使用全称；

4. 兼顾更大范围内的标准和规范；

6. 确定名称分类规则，以xxx开通表示XXX，以xxx结尾表示xxx；

7. 注明作者、调度时间、就绪时间……

8. 命名须用英文单词小写命名，禁用xxx，单词之间“_”连接，超过10个字段，可用简写；

9. 禁止出现数字，特殊字符；

10. 必须有数据结构描述（字段名称、字段类型、字段描述、取值规范（示例&范围）、备注）；

11. 字段名由字母、下划线组成，禁止使用数字，不同词汇之间用下划线分隔；字符长度不超过x位；

12. 主键或者唯一动作，应置为第一列，日期时间字段应该放在前列，其他字段遵循有钱及依次排列；

重要：对常用的字段设定限制词汇，对重要受影响与语言计算的字段规定字段类型。

三、流程标准和规范

当需求方提出数据需求时，从数据接口人接到需求到最终交付，整个过程应该建立操作执行流程，以保证交付质量和需求方的满意度，做符合预期的项目交付和保证，已达到团队口碑的树立和优秀成果产出。

1. 需求方提出需求（接口人定期收集需求）；

2. 双方协定交付内容和标准，接口人辅助需求方完成需求模板的填写工作；

3. 接口人对需求调研，排期、涉及、研发（或接口人分配工作）；

4. 数据测试，校验是否符合（2）中的双方交付内容和标准（不符合-优化（或及时反馈需求方，再行商议）。符合-任务上线并提供相关使用指南或培训）

5. 需求方对数据交付物进行验收（通过-回溯数据，不通过-根据（2）一起回顾协定，重新达成共识）

6. done（我认为一个好的需求方，通常会根据项目大小、重要程度写一份汇报邮件，感谢一下承接方做出的贡献和成果）

0xFF 总结

本篇转载自 Joker 的文章，修改了格式和个别文章结构。