“用数据来治理数据”的具体思路是什么 ？

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

数据模型本身的监控

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

规范要好：

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

复用率要高：

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

使用率要高：

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

依赖层级不过深：

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

业务复杂性的监控

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

总链路长度：

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

总代码量：

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

总成本预估：

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

项目管理：

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

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