更新时间：2024-12-21 21:01:11
数仓开发
244 数仓治理是一个非常棘手的问题，通常需要跟着业务需求快速发展。可能存在数据分散在不同团队或者团队之间研发规范不一致的情况。从维度模型来约束规范的工作来看，“模型”的治理难度大于“架构”。
目前行业通常的模型治理方法是规定一种建模规范，然后各自按照规范进行编码。当业务变得模糊不清时，再抽调时间进行人工治理。这种方法就像清理黄河的流沙一样，虽然可以清理一次又一次，但上游仍然会冲下新的流沙。
因此，考虑换个思路来解决问题。当业务高速发展时，数仓必须跟着发展，否则数仓就没有意义了。但是业务通常不会一直处于高速发展阶段，就像长跑一样，总会有跑跑停停的时候。所以如果我们遵循一定的做事方法，多一些流程步骤，就可以大大延缓数仓治理的问题。
换句话说，不要追求长期的问题解决，而是以一段时间内的稳定为目标，比如一年。当业务发展到比较稳定的阶段时，再来进行治理，既可以避免因业务变动而影响模型重构，也能节省精力和压力。
完美的解决方案通常是不存在的，所以当技术无法解决问题时，可以尝试一些另类思路去解决。
数仓的指导思想是以维度建模为基础，根据业务域和数据域设计主题模型，构建一致性的维度和事实。
具体建模方法如下：首先了解数据的统计周期，是增量同步还是全量同步，并根据预估的数据量设计ODS。其次，大致了解业务域的划分情况，将一类不可拆分的行为作为一类，例如支付、搜索等。然后根据这些业务过程，构建最明细粒度的事实表（DWD）。基于DWD，可以根据主题对象进行数据建模，构建公共粒度的汇总指标事实表。同时定义一致性的维度（DIM），通常是静态信息，动态可变属性应放到DWD中。
掌握了维度建模的核心思想后，每位研发同学都可以开始进行维度建模了。
掌握建模方法并不意味着可以发挥创造力，就像谷歌编码规范一样，有很多的Tips要遵循：
表名和字段命名要有规范，指标命名应能推测出大概的涵义；善于利用分区、临时表等方法降低表的依赖层级；扩展字段应以key-value形式存储，虽然get_json_object操作慢，但简洁；小数精度应使用Decimal而不是Double，避免问题；对每个任务进行摸底，解决可能产生数据倾斜的地方，常见于Join的空值问题。
数据问题的检测是一个复杂的过程。
通常有三种检测方式：基于统计、基于自动规则和基于价值衡量。
基于统计可以统计ODS/DWD/DWS/ADS层的表数量、业务域的表数量以及每张表的引用次数等，从而了解数仓建设情况。
基于自动规则可以检测重复开发的表，估算表之间的相似程度，推测是否可以合并。还可以计算表的主键和上下游引用，判断是否可以合并。这种方法需要对数仓模型有较深的理解。
基于价值衡量可以根据收益和成本对数据表的价值进行衡量，优先治理高价值的场景或者寻找低价值的重构点。这种方法需要考虑收益和成本的平衡。
最后提到了工具的重要性，例如FineDataLink可以帮助解决数据表命名、字段命名和权限问题，加速企业数据集成。选择合适的工具需要结合实际情况，目前市场占有率较高的产品是帆软ETL软件——FineDataLink。
我们专注高端建站，小程序开发、软件系统定制开发、BUG修复、物联网开发、各类API接口对接开发等。十余年开发经验，每一个项目承诺做到满意为止，多一次对比，一定让您多一份收获！
