《数据定义规范》

     上节我们深入分析了痛点产生的原因，并规划了阶段式的整体解决方案，主要是：从管理组织规范->数据定义规范->建模规范->研发规范->规范化推进 分步骤有序建立数据规范并落地。接下来我们对每个环节进行详细说明，其中“管理组织规范”已经在上节阐述了其必要性和职责范围，本章节就不再赘述了，本节重点放在“数据定义规范”这个环节。

   数据定义规范的作用是使得数据在定义上进行规范，各个业务线对该规范达成一致，来更好的进行数据的管理，加速数据定位，消除数据的二义性。

   举个例子：数据仓库存在如下两张登录表login_1，login_2，其中两张表均有login_num 这个字段，我的业务需求是按用户名来统计每天的总登录次数，那么我到底是使用login_1还是login_2呢？或是我能直接取已经存在的login_num来作为我需求中需要的指标值吗？不能，因为我所看到的表名称是不规范的，且login_num这个字段到底代表什么含义，也是缺失的，这就是表和指标不规范带来的无法快速定位需要的数据，数据二义性的典范。

  整个数据定义规范分为两块：表的规范化定义和指标的规范化定义

1.表的规范化定义

  如上面建设的login_1和login_2，有可能是代表了重复建设的两个表，也有可能代表着不同业务的登录表，或是其他的情况，那如何通过规范化来区分这些情况呢？经过研究，我们的表名称可以由以下几个部分进行组合： 表名=主题域+自定义+更新频率：其中主题域、更新频率为有限集合，使用数据字典维护，最终可自动生成表名称；

A. 主题域：

    在阐述主题域之前，先说说主题的概念，主题主要是将经营的业务数据进行综合，归类和分析的一个抽象概念，数据仓库中的数据是面向主题组织的，每一个主题对应一个分析的领域，比如打车业务中，“客户行为数据”就是一个主题。

   主题域就是紧密相关联的主题的集合，比如“客户行为数据”主题和“客户转化数据”这两个主题都在“客户数据”这个大的主题域下。

主题域的划分主要有如下几个方法：

    (1)按照业务过程划分：按照公司经营的业务范围，将业务按照模块垂直拆分成几大主题域，而每个主题域又可以拆分为多个主题，其中主题域，以及主题域和主题映射关系，均可维护在数据字典中。

    (2)按照功能块来划分：比如短视频app中的“聊天域”，“广告域”，其中“广告域”下面又可以分为“流量分析”,“客户分析”等主题；

    (3)按照部分来划分：按照部门职责来划分对应的主题域，比如“技术域”,“销售域”等；

     建议采用按照业务过程来拆分主题域，这样表名带有主题域信息，就能知道该表所属的业务范围了，为了防止表名称过长，表名里面携带主题域的缩写信息，而对应的主题信息作为表的附属信息，通过系统记录到后台中进行维护。

    这里需要注意的是，由于业务在不断发展，主题域在初期划分的时候很可能不是一个完整全面的集合，这个可以后期进行迭代升级补充即可。

B.自定义：

   除了用主题限定表名称外，还需要额外自定义信息来补充表的含义，自定义部分是区分同一主题下不同表的业务意义的，所以这块需要凸显出表的业务含义，如user_login_log表，表示用户登录日志，admin_login_log表，表示管理员登录日志。

  自定义标签名命名规范遵从DBA发布的库表设计命名规范：表名使用小写字母，“_”分割，不超过16个字符，使用名词且见名知意。不使用temp、old、new等带有误导性的关键词作为表名的一部分。

C.更新频率：

   在数据字典中可以维护其表的更新频率全集，如：按小时更新的，则表名后缀为hour，按天更新的，表名后缀带day。

    以上就是表名称的规范化的制定，有人会疑惑：表名称规范对应的3个部分，其中主题和更新频率是数据字典维护的，用户直接选择的，但是自定义部分仍然会存在用户定义成login_1，login_2，仍然会存在歧义和重复，对于这个部分，我们主要做了以下工作来规避：

(1)对规范化定义在各个业务组进行宣讲，各业务组leader对组员进行规约，在理解上达成一致，尽可能规避风险；

(2)通过自动化手段检测和约束自定义表名称的规范化：如维护一个黑名单，不允许出现_1,old 这样的短语作为表名称的一部分；

(3)在流程上增加审核机制：对新增的表由数据管理组人员统一进行审核，通过后再在线上环境进行创建；

    通过以上三个步骤，可有效规避表的不规范问题，整个过程涉及到的人员和环节较多，所以需要大家的通力合作，才能最终达到规范化的目标；

     仍然以电商领域为例，我要创建一个用户基础信息表，且按天更新，则定义的规范化表名称为：

  acct_baseinfo_day,其中acct表示客户主题，baseinfo为自定义，day为更新频率。

2.指标的规范化定义

    数据指标是指在业务中将某个事件量化，数字化来衡量业务的好坏，揭示出产品用户的行为和业务水平状况，指导我们的业务运营，如在某款打车APP应用中，日活作为一个数据指标， 表示一天内日均活跃去重设备数，日新增注册用户量指标，则统计一天内安装应用后，注册APP的用户数。

   为什么要进行指标的规范化定义？主要是为了防止指标的重复性建设和二义性，如在最开始出现的例子中，数仓中的两张表login_1，login_2，均有login_num这个字段，但是login_num到底代表什么业务含义，是否重复建设的，这些都不得而知，所以我们需要从指标的定义上面来制定一些规范，遵循这样的规范后，可以有效控制指标的重复建设和二义性问题。

  指标是依附于数据表而存在的，并且指标也是从数据表中统计而来，通过对已有的指标进行分解，我们发现每个指标都可以按照业务限定+统计粒度+统计周期+原子指标进行分解，这4个部分均可以根据自身业务来用数据字典进行维护，数据字典作为有限集合，可以很好的统一指标的定义，通过这种结构化指标设计来消除二义性，统一数据口径：

 从业务角度来分析这4个部分，举个例子：在打车APP场景下，统计华中地区每个公司日活指标

A.业务限定：

   表示该指标统计的业务范围，例子中的“华中地区”即为业务限定；

B.统计粒度：

   即统计的维度信息，例子中的统计粒度为“公司”维度统计；

C.统计周期

   统计周期可以为按日，按周，按月等，表示该指标的时间属性，例子中的统计周期是“按日”；

D.原子指标

  原子指标表示不可再进行拆分的最细粒度的指标，例子中的对应的原子指标为“活跃数”，在算法上表现为APP用户去重计算所得；

   回到上面的例子，采用这4部分进行拆解后，该指标经过规范化定义为：华中地区_公司维度_按天_活跃数，在开发人员通过系统平台添加这种规范化指标后，并和规范化表中的字段列进行绑定后，那么数据分析人员在使用时就能快速准确定位到该指标，数据开发人员在进行开发时候也能知道系统中已经存在该指标，也就不会再进行二次开发了，即使开发人员在定义指标时候没有查重，其在平台上添加的时候，平台会进行检测，发现已经存在一样定义的指标，会拒绝创建该指标。通过这种方式来保障指标的规范化。

 以上为数据规范化定义的内容，主要包含数据表的规范化定义和数据指标的规范化定义，我们来回顾下重点：

 (1)数据表的规范化定义：表名=主题+自定义+更新频率：其中主题、更新频率为有限集合，使用数据字典维护，最终可自动生成表名称。其中自定义部分要契合业务含义，不能随意填写；可以通过文中提及的管理手段和工具来规避乱建的风险；

(2)数据指标的规范化定义：指标= 业务限定+统计粒度+统计周期+原子指标，4个部分均可以采用有限集合进行限定，可通过平台自动检测等手段避免重复建设风险；