我们如何用“十步法”完成了一次企业级数据治理的落地？

这次数据治理的课题是：面对持续增长的存储投资需求，如何进一步提升公司大数据的存储效率，从而实现高效低成本运营？

1、数据治理的驱动力

2015年-2016年我们就完成了企业级大数据平台的建设和应用上云迁移，将公司的三域B（业务）/O（网络）/M（管理）数据进行了统一归集，但在实施中也发生了很多妥协。

因为大量的O域应用跟存储的数据是紧耦合的，也就是说这些数据是非标准化的，如果要实施数据的统一标准化归集，必须进行存量应用的大量改造，但这种改造的代价牵一发而动全身，在一个大数据平台项目周期几乎是不可能完成的，那怎么办？

先破后立！

当时的原则就是允许存量应用的数据保留一份，大数据平台先从这些数据的源头统一归集一份，待到时机成熟的时候，再考虑存量应用的改造和数据的合并。

这就意味着大数据平台从建立伊始，其上的数据并不是企业大数据唯一的一份，还有大量的存量应用在使用用非标准化的数据，更为关键的是：这些数据的源头往往是一个，意味着数据的较高冗余。

这是很多企业的现状，发现在建成大数据平台后，感觉又多了一个山头？

每年随着数据量的增长，大数据平台需要投资扩容，但大量的存量应用依赖的数据也在同步增长，因此也需要扩容，当这份冗余的数据还是最大的一份的时候，公司的投资也要开始叫了。

因此，所以能实施一次数据治理，往往是数据的问题已经在公司层面显性化的暴露出来，在降本增效这个大背景下，很多公司是有数据治理的驱动力的，毕竟节省的是真金白银。

现实中，我们大量的数据治理活动都是小组级、部门级的，跟数据产品，数据变现，智慧运营这些工作相比，重要程度实际是偏低的。

大多时候，公司层面并没有感觉到未实施数据治理的痛苦。IT部门虽然痛苦，但为公司呈现数据的时候，大多数时候也是打肿脸充胖子，即使你花了大量的人肉去保障，但又有谁会理解人肉的痛苦呢？

因此，数据治理从来都不是自底向上就能干成的事情，你只有在一个势上，才能有干成事的机会，说起来有点悲壮。

数据治理大多数时候也是失败的结局，因为要治理就要牵扯多方利益，没有公司的统筹协调，谁愿意损失哪怕一点点利益？

因此，并不是说我们就能干成数据治理，其实很多时候，唯运气而已。当然要最终干成事，还是要有实力的，否则一旦有了机会，你也抓不住。

2、数据组织的保障

笔者在反思为什么还是能最后干成这个事情？很多企业也有这个驱动力啊！但为什么很难干成？

想来想去，我觉得有个统一的实体数据管理组织是非常关键的。

为什么？

因为这个组织就是以数据为生的，搞企业级数据管理的组织，哪个不想“一统天下”，他们天然有数据治理的驱动力，而且这个组织一定会有一批懂数据的人，有机会，就一定会跳出来。

2015年，我们成立了大数据中心，下设了三个科室，而数据管理部就是专干这个事情的，其是企业进行数据治理真正的组织和人力保障。

虽然大数据中心成立的直接目的是为了变现，但把数据治理这个事情干了是很顺理成章的事情，因为没有高质量的数据，你也没法很好变现。

降低数据冗余这个事情公司提出来，大数据中心自然要牵头，我们当然有权利要求其它部门进行配合，这就有了事实上的跨部门组织。

你看，天时、地利、人和都全了，接下来，就落到方案层面了。

3、理解冗余的现状

理解现状是第一位的，我们做了与相关部门的充分调研，发现除了大数据平台公共租户有一份标准化的DPI（可以理解为上网日志）数据即A1，在其他应用租户和Hbase集群有两套系统内有类似的数据即A2和A3，但三类数据的存储方式各有不同，但实际源头是一致的，都来自探针，经过不同的加工处理后，就形成了一定的冗余，如下图所示。

通过分析这三份数据，可以得到如下一份清晰的数据分布现状报告，这是数据治理工作的起点。梳理工作来来回回持续的时间长达一个月，因为涉及多方系统和应用，双方要对齐口径，确保理解的一致性。

梳理现状中有几个要点，特别提一提：

首先，要有标准化意识，比如规范梳理的模板，明确各个指标的口径，比如存储量是什么意思，裸存储还是可用存储，事无巨细，一旦某个口径出现少许偏差，就可能谬以千里，曾经我们按照口头约定的方式去梳理，几周后拿各自的材料一对，发现到处是各说各话的口径和理解，还得重新来过。

其次，要有迭代的意识，清楚梳理是一个持续逼近真相的过程，无法一步到位，不要想着开一次会就能明确清楚要求，这种治理大多是开了个好头但最终烂尾，一定要是在每天，每周的沟通中逐步达成共识，毕竟每个部门都有自己的利益。

再次，要有全局的意识，始终站在公司的立场来处理问题，因为凡是涉及到各方利益的事情，一定是有部门墙和本位主义的，比如对方就不想整合某个数据，这个时候数据管理部门就要有原则，先把问题抛出来，如果合理，在公司层面汇报的时候，还要帮助对方去据理力争，毕竟很多应用积重难返，改造的代价太大了。

最后，要有担当的意识，如果对方在梳理中存在问题，或者推进困难，就要主动去推进问题的解决，很多时候数据管理部门的同事会抱怨对方不配合，其实很多时候就是借口，或者为自己的不作为找理由，除非公司本身就不想干这事，或者升级渠道没有打开。

升级渠道未打开，往往是未设置专业的数据管理组织导致的，数据的很多治理问题无法解决，根子在于没人真正的把声音传递到公司决策层，干不成事情是很显然的。

4、在业务上的策略

数据治理中的问题，很多需要从业务的视角寻找解决方案，而不是就技术论技术，针对DPI数据冗余的问题，我们首先考虑的是能否在短期内找到降低存储的方法，缓解当前的压力。

在业务层面进行了分析后，发现在字段裁剪、数据采样和周期优化等方面存在降低数据冗余的空间，当然这个需要业务方的确认。比如哪些表的字段没有任何应用上的调用，哪些表的调用周期间隔非常长，哪些表只需要访问近线的就可以了，然后我们得出了策略，如下表所示：

5、在技术上的策略

有大量的技术可以应用在数据存储效率的提升上，我们根据分析，采用了两种手段：

第一种：减少副本

现在诸如hadoop都是三副本，之所有采用三副本其实也是技术上妥协的结果，两副本也不是不可以，只是恢复起来麻烦而已，比如采用纠错码技术就可以做到。假如hadoop平台的计算资源利用率并不高，就可以采用纠错码技术，用计算换空间，4G日志留存这份数据就满足了这个条件。

第二种：格式优化

针对不同的场景可以采用不同的压缩手段，比如针对TextFlie+HIVE，可以采用普适性强、压缩效果更好的OrcFile文件格式，针对HFile+HBase，由于HFile文件膨胀很大，如果应用的时效性不高，则完全可以替换为HIVE这种格式。很多场合，并不是越快越好，总是要寻求性价比高的方案。

6、在整合上的策略

无论是技术策略还是业务策略，相对还是比较简单的，这些都是数据治理中低垂的果实，但一旦要进行三份数据的整合，则牵一发而动全身，你得权衡利弊，寻找最佳方案。

比如要对A1、A2两类单据进行整合，你得分析两类单据字段上差异，A1单据共涉及相关表14张，1346个字段，A2单据涉及相关表43张，2262个字段，虽然两者的源头一致，但数据的时延、粒度等由于应用的要求已经有很大的差异，因此需要进行详尽的差异性分析，最后的整合策略往往是妥协的结果。

又比如要对A1、A3进行整合，发现A1仅保留15天，需要全量字段，而A3虽然只有几个字段，但却需要保留180天，合并的价值很低，但改造代价却很大，如果为了治理而治理就缺失了意义。

因此，针对A1、A2、A3三份数据，最后的策略就是A1与A2大部分合并，但A3作为应用单独保留。

你看，做数据治理从来不是你痛下决心搞标准化就可以搞定的，还是要尊重现状，给出当前阶段对企业最有利的解决方案。

我们以前做指标口径的统一也一样，往往是既要建立一套标准化的指标体系，也要保留个性化指标部分，你强制管控，走理想主义，最后的结果就是失败。

7、预期的治理效果

前面说了这么多方案，最终就是要明确告诉公司这个数据治理方案能带来什么样的收益，所谓的临门一脚，否则，前面做得再多也没有意义。我们很多的数据治理工作却往往难以跟领导说清楚效果。

多年前做元数据，采购了元数据软件，SQL解析等功能做了一大堆，轰轰烈烈的完成了项目，但最后却说不清到底给业务上带来了什么价值，你问运维这个血统分析对你有用吗？他跟你笑笑，好像有用吧，但点击情况出卖了所有人。

你会发现，项目经理仅仅为系统上线负责，却没有人为最终的效果负责，没有一个人是利益相关的。

我们这个数据治理方案最终会带来什么效果呢？

很明确，存储压降XX%，节约费用XX万元，A1、A2融合后只保留一份，A2复用A1的建模结果，降低未来投资的需求。

8、落地的演进策略

数据治理工作涉及的面很广，无法毕其功于一役，因此，要清单式的列出多方的具体工作内容，如下图所示，比如A3的从HBASE存储改为HIVE的策略，就涉及应用和数据的并行改造，时间跨度很长，不能由于数据治理的要求影响前端使用。

然后按照难易程度给出实施优先级，比如我们就给了个三阶段的目标。第一阶段：单据的独立瘦身；第二阶段：单据的融合演进；第三阶段：数据的统一管理。

9、老板的终极汇报

完成了方案后，数据管理组织就需要代表各方去跟老板进行最终的汇报，无论前面的梳理如何繁琐、双方的分歧有多大、技术方案有多复杂，但给老板呈现的方案一定是清晰的、可落地的且效果可期的。

笔者当时作为代表去做了汇报，现场黑压压的来了几十号人，因为涉及的面太广了，大家也都是利益相关着。具体过程就不说了，下图是简化的总体思路一页。

10、项目的落地实施

经过前面的九步，我们才最终走到了第十步，进行真正的落地实施。但所有的思路，方向和内容，都已经在前九步明确掉了，你会发现数据治理最艰难的部分，其实就是说服各方形成方案的过程。

很多企业采用外包的方式进行数据治理，但你会发现，前面九步跟企业现状有千丝万缕的关系，如果你自己都理不清头绪，何况外人乎？

你也会发现，数据治理要实施成功，对于组织的挑战特别大，即使公司设立了大数据中心这种统一的组织，但并不意味着在那里简单的发号施令就可以搞定一样事情，而是要能够串接起各方力量，让大家为同一个目标而奋斗。

笔者刚接到任务的时候，最担心的也不是什么技术，而是想着如何跟外部门的领导协调好，才能为后续的工作铺平道路。作为数据治理的负责人，你既要知数据，又要懂管理，还要会实施，最后还能运营，一不小心就会搞成烂尾楼。

因此，虽然我们有DAMA的指导，但数据治理更是一门实践的学问，必须要结合企业的实际才能真正的做成事，数据治理的复杂性也不是一般人能想象的。