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

最近组建了微信群后，发现大家对于企业的数据治理特别感兴趣，因此再来谈一谈。这次就讲讲一次具体数据治理的实践吧，就是怎么把一个事情干成。

从这个案例，大家可以端到端的了解到我们是如何通过十个步骤去推进这项工作的，至于这三年来我们在其他数据治理方面的进步，就留待后面写吧。

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

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的指导，但数据治理更是一门实践的学问，必须要结合企业的实际才能真正的做成事，数据治理的复杂性也不是一般人能想象的。

最后，为奋斗在数据治理战线的同仁点赞！