0x00 为什么数据治理难做

毛主席说：“研究任何过程，如果是存在着两个以上矛盾的复杂过程的话，就要用全力找出它的主要矛盾，捉住了这个主要矛盾，一切问题就迎刃而解了。”

对于数据治理而言，矛盾就是：“有限的机器资源与存储计算的无限增长之间的矛盾”。

因为存在主要矛盾，因而“数据治理”在被提出10多年后，依然是目前数据领域的热门问题。解决的方法也很简单，就是尽量限制存储计算的增长，不论是通过技术手段，比如数据压缩、列式存储，还是通过方法论，比如维度建模、存储健康分，都能够延缓数据增长的困境。

但最大的问题，还是人的问题，可以这么说，不是数仓岗位，或者是数据开发岗位，对于数据治理或者数据风险问题的敏感性，都是不足的。这些不足主要体现在三个方面：

全局层面

1、风险意识不强：一是数据治理通常偏事后分析，日常的生产与发布习惯非常随意；二是数据质量校验覆盖率不够，或者是数据问题识别不够准确；三是大多团队成员都是业务开发，对于基础治理动作投入有限。

2、治理方式不合理：数据治理通常面临奖惩不平衡的问题，例如做的不好只会惩罚，做的再好也不表扬；治理动作通常是周期性的、个别人参与的，无法激发个体的主观能动性。

业务层面

2、临时性任务：一些老的业务，因为维护人的变更，导致数据即使不再使用了，也没有人能够决定是否可以下线。

3、数据回刷频繁：在电商等场景下，数据回刷的诉求非常多，导致集群的计算资源一直满负荷运作。

开发层面

2、资源不足：没有时间或者只有很少的时间，能够用在资源治理上。

3、能力不足：由于建模能力或者规范问题，导致数据的相似计算、数据倾斜、简单加工、暴力扫描、参数不合理等问题非常突出。

因此，数据治理，首要在统一“人的共识”，建立“法制”流程。

0x01 分析数据治理的核心问题

既然要统一“人的共识”，那么我们就从“共性”的问题入手，逐步来分析解决的突破口。

作为数据开发，我们经常遇到的“共性”问题有哪些？我想，大概有三点：

1、找不到数据：为什么我们要强调建模的规范？是因为为了让其他人能够看到这张表在做什么。当公司规模不断扩大、数据依赖链路不断加深，如果上下游的规范存在差异，比如命名、注释与刷新周期，那么即便能够根据血缘找到上游的表，也因为看不懂数据是什么意思、怎么设计的，而无法使用，只能自己再做一遍。

2、不敢用数据：重复数据一直是数据治理中的大问题，因为相似的表名或者字段，在元数据中通常能找到一大堆，加工的口径各不相同，看到了也不敢用，只能自己再做一遍。

3、不让用数据：随着很多公司意识到机器成本的增长过快时，都会对数据的预算提出严格的要求，进而导致一些占用了过多资源的大业务，如何做新的需求成为难题。大家都在提要治理数据、降低存储计算资源，却很少有人来告诉你如何在有限规模下做数据的开发。

我们设想一个案例：指标A是公司的核心资产，但是因为客观的原因，需要修改计算规则，那么我们会碰到这么几类情况。

2、只需要修改对应的DWS表，但下游需要逐步排查影响范围，涉及Y个接口，Z个产品模块；

3、该指标在公司内有唯一的涵义和计算规则，数据只在单一接口上透出，这时候只需要修改固定的几张表。

尽管公司的业务通常非常复杂，但如果抽象的好，底层逻辑的修改，就不会对使用方产生过多的影响，避免无意义的数据整顿工作。

从这里例子中，我们能够整理一下一些常见的问题：

1、从数据生产的角度：公共层的建模要有一定的规范性，至少需要经过分析师或者是业务方的认可，不能随意建表；同时，数据的产出时间需要保证，对应的质量测试与监控要有机制；

2、从数据使用的角度：研发工具要能够统一起来，历史表要有下线机制。

别小看了研发工具统一，在业务高速增长的时候，技术方案非常多变，用的越灵活，未来的技术债务就可能越高。

数据资产依托于Hadoop生态，其治理成本非常高，尤其是非结构化的数据，占用存储计算量大，产出的价值又相对有限。过去我们主要针对的是存储治理，但随着任务量的增加，计算的治理也提上了日程。因而，从全局的角度出发，一家公司需要有自己统一的建模与评估方法，有统一的开发与运维平台，在统一开发规范与开发方式的基础上，才能谈有效的数据资产治理。

“书同文，车同轨，统一度量衡”，是数据治理的核心思路。

0x02 用数据来治理数据

统一共识，统一度量衡之后，我们就有了数据治理的“抓手”。更具体一些，就是当工作行为有了一定的标准化之后，就可以通过“数据指标”来进行一些衡量，从而看清楚数据资产的全局情况，以及需要改进的重点方向。

做用户增长的都知道建立指标体系的重要性，做数据治理的同样要有“用数据来治理数据”的意识。

那么思路具体怎么样呢？主要有两点，一个是数据模型本身的监控，一个是业务复杂性的监控。

数据模型的监控可以理解，但为什么要监控业务复杂性？是因为业务复杂性很大程度上影响了数据模型的复杂性和成本，因此同样需要监控。

先说数据模型的监控，简单讲，有四条策略：规范要好；复用率要高；使用率要高；依赖层级不过深。

规范要好：做开发的基本都知道，做事情要有基本的规范，比如表的命名，要能够清晰的看出是属于哪个业务域、服务哪个产品模块、是同步导出数据还是披露视图、刷新周期如何，等等，这些都需要通过名称来规范，因此当数据规范定好之后，就可以针对性的统计不符合规范的表，限期整改。

复用率要高：这一条是针对CDM层的。在维度建模理论中，CDM的主要作用就是提升数据的复用率，因此CDM（包括DWD、DWS和DIM）一定不是面向需求做的开发，而是针对业务过程做的统计。统计CDM层每张表的下游依赖数量，就能够有效的考核公共层的建设水平，少有人用的CDM是不合格的。

使用率要高：这一条是针对ODS层的。ODS通常存储了最多的数据，因此ODS数据如果被引用的不够多，那么通常它的业务都不是那么重要，那么ODS表的存储周期就可以适当的考虑缩减，并在引用数量与存储周期之间寻找一种平衡。当然，肯定有特殊的例子，但特殊不代表普遍情况。另外，有一些ADS表是直接引用ODS的，如果业务发展初期，这么做是可以考虑的，但如果是成熟业务，这就应该。区分的方法依旧是通过表的命名，来判断表述所属的业务域与产品，并与业务域的成熟度挂钩起来。

依赖层级不过深：这一条是针对ADS层的。最让数据人头疼的问题，莫过于数据层层向前追溯，发现链路极其之长，用都不敢用。因此ADS层自身的依赖深度，包括最大依赖深度、不同依赖深度的统计，能够看出ADS层建设的一些问题。

再说业务复杂性的监控，也是四条策略：总链路长度、总代码量、总成本预估、项目管理。业务复杂性监控的前提，是梳理核心的ADS产品出口表，整理清楚每个产品模块或者接口对应了哪些ADS表。

总链路长度：计算一个产品出口表从ODS到ADS的全路径长度，链路越长，存储和资源资源占用越多。

总代码量：计算一个产品出口表从ODS到ADS中涉及的代码总量是多少，代码量越高，代表计算资源消耗越多。

总成本预估：依据链路表的存储数据量与机器资源消耗，推断一个产品消耗的数据成本。

项目管理：从根源上治理需求多乱的情况，这里不展开说这个问题。

当然，随着对于数据的理解不断加深，我们还会做更多有价值的分析，比如分析每个SQL的写法是否合理，等等。但不论怎样，有了统计指标，就能够看清全局现状，就能够针对性的治理。

0xFF 数据治理的短中长期策略

就像任何方案都有“上中下”三策一样，解决问题同样要有“短中长”的策略。

短期方案着重点在于改善上述提到的统计指标，迅速将一些低级问题解决掉。因为一旦有了指标的概念，可以调动研发同学的主观能动性。

中期方案要整理数据的架构体系，包括建立完整规范制度和技术结构，通过方法论和文化的方式，来影响每一位小二。

长期通过技术创新的方式，实现自动任务优化，协助降低数据的维护管理工作量，例如最近比较热门的“云原生”概念。

但不论怎样的策略，都需要考虑历史债务的问题，以及如何不再新增债务。

完美的解决方案通常不存在，退而求其次是大多数人的选择。当技术无法解决问题时，不妨用另类思路去解决。

当然，广义的数据资产治理，要扩展到更多的方面去阐述，比如数据安全、比如数据孤岛问题，每一个都需要系统的理论来阐述。

但最后我想讲的是，这其实涉及到了择业的问题，企业效率的提升无非两点：降本与提效。提效可以通过数据分析的角度来解决，而降本就需要通过数据资产治理来推动了。择业的时候，如果仅仅是熟练使用工具，很容易被淘汰，而掌握了降本与提效的方法论，应对中年危机，就要更加的得心应手一些了。

-END-