数据仓库的治理总是乱糟糟？不如换个思路吧！

数据仓库的治理总是乱糟糟？不如换个思路吧！

目前整个行业通常的模型治理方法，是规定一种建模规范，大家在编码的过程中各自遵守。

当业务开始变得模糊不清的时候，再专门抽调时间，来做人工治理。就像黄河一样，流沙清理了一次又一次，但上游还是会冲下新的流沙。

数仓的假设既然都是采用的维度建模，那么其设计思想必然是自下而上的进行建设，与架构进行类比，也就是先做好子模块，最后做顶层设计。
但如果设计者不熟悉对应的领域模型，一旦业务上发生了变动，一张核心表动辄几百张的引用，会让重构的工作变得困难无比。
比如模型的健康分，看看你的存储成本有多少、计算成本有多少、生命周期是不是合理、代码规范有没有避免全表扫描，等等。但这些工作只能发现一些常规的问题，也依然需要进行人工治理，不仅效率上没有得到提高，每天推送的邮件也会让你产生心烦。
投入多少人，投入多少时间，终归是解决了一时的问题，而非长远。

因此，换个思路考虑问题，当业务高速发展时，数仓势必要跟着跑，不然业务都跪了，数仓又有何用。但业务通常不会一直处于高速发展的阶段，就像长跑一样，总有跑跑停停的时候，因此如果我们遵循一定的做事方法，流程上多一点步骤，那么就会极大的延缓数仓治理的问题。
即不追求长久的问题解决，而以一段时间内的稳定为目标，比如一年。当业务已经发展到比较稳定的阶段，再回过头来做治理，既能够避免因为业务变动而影响模型重构，也可以节省大家的精力和压力，就不失为一种解决思路了。
完美的解决方案通常不存在，退而求其次是大多数人的选择。当技术无法解决问题时，不妨用另类思路去解决。