标准和规范总不像一个数学公式那样黑白分明,它的概念总是显得抽象和模糊。因此,并不存在真正意义上的标准和规范,而是指的从业人员相互之间的约定积累,以及在工作中达成共识的结论。
我们接到一个数据需求,小A同学想要分析调研自家app内的功能模块的订单数据情况,例如常见的首页有一个顶部广告位,可以放广告素材,这个广告位可以承接多种的运营活动和产品导流需求。现在我要为小A同学拿到这个广告的交易订单数据支持她做数据分析,但是我可能是一个新人,也可能早先并不接触这块业务,因此在整个接手项目过程中会非常吃力,大家尝尝会有这样的痛处,换位思考一下我们各自的产出是否也会对他人造成同样的困扰?
因此,那些核心的数据,对业务影响很大的数据需求,我们应该尽可能的保证其质量,为自己的团队树立口碑,更好的服务业务于数据方的需要,做到沟通成本的降低和项目返工的几率。基于以上的原则,制定数据仓库的交付标准,规范项目的交付流程就是对自己数据仓库搭建的标准和规范的整理。也由此可以看出我们的需求方可能是数据研发工程师,也可能是数据分析师,甚至是一位产品经理,他们份数不同的角色,拥有不同的能力模型。对此我们的交付物标准可针对不同的角色归纳总结一下大致为:数据表、表结构的说明文档、使用指南(甚至不仅限于文档,还可以是视频)、数据质量报告、数据培训资料或课程。
其中关于数据表和表结构的说明文档大致包含以下信息:
字段名称(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 |
根据以上示例,我们就可以反复的研究推敲什么能沉淀,什么是可以成为数据仓库表的标准和规范。以这个示例出发,我们常见的问题会有哪些?
交付的标准可以从三个角度来考虑:交付基本信息、交付物的标准和规范、流程标准和规范。
数据表的命名规则不仅要遵从整个数据仓库的标准和规范,也应该有自己的特殊要求。示例中我们提到的表名称为xxx.oder,这个显然是缺乏优秀可言的,公司或者事业群甚至业务范畴内必定存在多种多样的订单表,均不能可能仅靠库名区分,也不可先到先得的抢订关键字。
为了应对负责的业务和组织关系,表的命名最佳选择是能够表明其从属和业务关系,仅此在公司范围或者事业群、业务范围内应该给予一个标准规范使大家遵循。例如格式规则:库名.fact业务库名称主题简称[二级主题简称]自定义表名,类似的思路可提高用户快速的对数据表产生范畴概念,且避免上述诸多问题。
同理<数据表的命名规则>,很多人是无法忍受“订单表”这个名称的,没有人期望看到数据仓库中成百上千的订单表。因此中文的名称也应该足够的定语去描述,例如xxx业务订单表。
在使用数据表的过程中,最大的困惑是对表的认识不足。在没有任何交流和业务铺垫知识的情况下,描述可能是作为唯一的发言权存在文档描述中的,对于表的描述应该尽可能全的去介绍这张表是什么,生成的条件,适用的范围。
数据表中最重要的是对各个字段,尤其是关键字段的文字说明。数据中多数的问题都是错误的字段理解不到位或者无解而产生的。对于字段的描述常见的问题会很多,这块内容如果能配套一个系统去做,是我当前能想到最好的办法,但是目前还未发现哪家公司有过尝试。
综上所述,我们会有所启发,表的标准和规范主要是为了更全面的介绍表,消除歧义和使用过程中的疑虑。表的规则并非生搬硬套,而是根据公司和部门内部长期达成的共识而积累产生的。在上述的几点问题中,可以不断的延伸出表规范:
重要:对常用的字段设定限制词汇,对重要受影响与语言计算的字段规定字段类型。
当需求方提出数据需求时,从数据接口人接到需求到最终交付,整个过程应该建立操作执行流程,以保证交付质量和需求方的满意度,做符合预期的项目交付和保证,已达到团队口碑的树立和优秀成果产出。
本篇转载自 Joker 的文章《数据仓库表的标准和规范关注点》,修改了格式和个别文章结构。