数据仓库的治理一塌糊涂，没有管理好数据，最后都会怎么样( 二 ) |0x00老大难的数仓治理“年年数据要治

根据这些建模方法，我们就可以愉快的进行ADS层的业务开发了。
|0x02 事中：方法掌握了建模方法，不代表可以发挥创造力，就像谷歌编码规范一样，有很多的Tips要贯彻强调：

不仅表名设计要有规范，字段命名也要有规范，指标如果不能根据命名猜出大概的涵义，那么设计上就是失败的；
善于利用分区、临时表等方法，降低表的依赖层级；
扩展字段按照key-value的形式进行存储，虽然get_json_object慢，但它很简洁；
小数精度要用Decimal ，而不是会出问题的Double；
每个任务都要进行摸底，解决会产生数据倾斜的地方，常见于Join的空值问题。

文章插图
|0xFF 事后：检测数据问题的检测是一门大学问。
通常而言，检测有三种方式：基于统计；基于自动规则；基于价值衡量。
基于统计：因为前文提到了，我们能够根据规范进行编码，因此我们便可以清晰的统计， ODS/DWD/DWS/ADS层各有多少张表，每个业务域有多少张表，每张表的引用次数是多少，产品出口的ADS表到最底下的ODS表依赖层级有多深，基于这些统计，我们便可以对整个数仓的建设情况有一个大体的了解。
如果某个数据域表数量过多，或者某个DWD表下游太多，或者ADS到ODS的层级过深，大家便可以根据具体的情况进行治理。这种方法有一个好处：简单，做几张BI报表便可以完成，但问题便是，即便知道了具体问题，治理起来也是一件棘手的问题。
基于自动规则：既然提到了，基于统计，我们能够掌握大体的情况，那么有没有方法进行更细化的分析，提供解决的指导思路呢？这便是基于自动规则的检测方法。

文章插图
例如，我们可以检测重复开发的表有哪些，通过表名相似性/字段相似性/数据量相似性等，估算两两之间的相似情况，如果相似程度90%以上，通常它们是可以合并的。
再者，我们可以使用更高阶的算法，比如计算两张表的主键与上下游引用，如果主键相似，且上下游表高度重合，那么这样的两张表也是可以合并的。准确来讲，自动规则，体现了我们对于数仓模型的理解程度。
基于价值衡量：治理也要有优先级，优先治理高价值的场景，或者寻找低价值的重构点，都是投入侧重点的最重要因素。比如， A表只有一个下游，占用了1TB的空间，而B表有1000个下游，占用了1GB的空间，是不是意味着B表价值远大于A表？
不见得，只要下游的收益，大于存储这些数据的成本，就是有用的。因此只根据收益和成本，来衡量数据表的价值，容易产生极端。这里如果有算法的同学能够接入，做一些类似于C-V模型的公式，找出异常点，就能够相对准确的衡量价值。但这一点目前比较难以实现。
最后提一下工具的重要性。数据治理有一个很棘手的问题，我们发现了有问题的表，如何进行纠正？比如字段不同了要废弃，比如命名不规范要重新改，那么如果下游依赖过多，又涉及权限问题，基本上就算是无药可救的状态了。
这时候开发一个插件，能够同步Hive解决命名问题，同步下游修改字段命名，以及将表的权限复制到新表中，就很有用。