? 数据治理，这并不是数据仓库建设的一个必要环节。通常在数据仓库的建设初期我们会制定开发规范，然后在模型设计时，设计人员会统一数据类型，字段名等元素，并且很多建模工具已经支持此类功能。这个项目由数据治理发起，很大程度上是由于前期的工作缺乏规范，同时开发时间过短造成的。

? 好吧，既然治理，就要把数据都管好，想管好就一定要有规矩，无规矩不成方圆，做任何事都是这样的。所以我的治理方案第一步是数据探查，第二步就是数据标准的制定了，这个标准不仅是数据仓库的标准，也是上游业务系统和下游系统的参考依据，要保证全行数据的统一性。

? 一、数据标准范围

??现有系统的dw层，按功能分为了事实表和维表（关于表的概念，大家可以度娘、狗哥）。

? 二、技术标准制定步骤

? 2.1顺序选择

? 从主要业务的事实表（如客户基本信息表）下手，涉及到dw层的所有的事实表，都要进行梳理。按照前面的表来制定标准，用后面表里的类似字段来验证，采用迭代的方式制定最终标准。

? 2.2字段名

? 由于是从主要业务表开始的，所以原来的字段名没有问题就沿用，如果太离谱了就重新起具有业务意义的字段名。

? 2.3数据类型

? 第一：数据类型的问题集中在了前面文章中提到的过长的问题。如手机号长度是100位。因此可以参考ods的对应字段的数据类型，然后查看表中所有的去重数据，确定正确的数据类型；当然这个过程需要一些经验，比如客户号，一个业务系统的客户号肯定是固定长度的，所以我只要确定这个长度就好了，这个仓库都可以统一；但如果是家庭住址的话，最好还是问问业务系统了，到底是多少，是没法自己判断的。

? 第二：对于一些事实表中的维度数据类型，比如性别只有1，2，0；可以考虑使用char等类似固定数据类型。

? 2.4默认值

? 第一：核心业务系统，在客户填单字的时候有很多是选填的，如果业务系统没有给默认值，那我们就会拿到空值。这时，如果我们发现一个字段全部都是空值的时候，还要去看一下etl程序，是程序正确抽取了，源系统的数据就是这样，还是我们程序里就直接赋了null，这个问题在项目中经常出现。当源系统全部是空值时，我们是没法制定标准的，必须拿到源系统的表结构，不然很可能在ods层就出错了。

? 第二：要考虑的就是空值是否要给默认值，从分析的角度来说，数据仓库中是不应该有空值的，这样会造成空数据不进入样本数据，如果某一字段的空值多的话，会影响分析的结果。不过，在银行系统中，有很多的报送工作，向银监会，人行等，这个时候默认值容易与源系统的一些默认值混淆，会影响报送系统的数据处理，所以权衡之下，在此仓库我没有设定默认值（在这里不设定，后面肯定会有处理的，欢迎大家关注我的博客），由各个下游系统自己来设定。

? 第三：是否可为空的限制，这个一方面要考虑业务，比如家庭年收入，这种东西，限制了也是自己限制自己玩，有谁会真的填呢。另一方面就又到了报送了，如果上级报送部门要求必须报送了，那标准肯定要非空喽，不能实现的系统也要想办法来实现了，这是天朝嘛。

? 字段名，数据类型，是否为空就构成了基本的技术标准。在整理的过程中，会出现这样一个问题，比如address，在表一中是家庭地址，在表二中是单位地址，这就出现了业务的不统一。这也要有标准的，比如调整为home_address，emp_address或其他的方式。

2.4维表

? 第一：维表整理相对容易一些，原本系统中没有维表，只有事实表。我只需要重新建维表就行了。不过这里的业务系统并没有给出相关表明，只有txt的每个维度的值列表文档，全靠自己分辨了，如性别等不变维度直接建表，像产品这种快速变化维，必须要再去协调业务系统。

? 第二：自定义维度。由于数据仓库中的数据是集成性的，比如客户表中存入了信贷系统，核心系统的客户数据；但是他们各自的规则不同，虽然都是集体客户和个人客户，但一个是1、2，另一个确实01、02，这时我们需要确定仓库自己维表了，这在后面的文章中会给出方案。

? 这是我指定技术标准的思路，还有业务标准，数据治理实施，会在以后提到。