数据仓库【模型好坏】

引言

        数据仓库的好坏分为内部评价标准和外部评价标准。数据仓库既不能闭门造车，也不能完全跟着业务需求走，好的数据仓库模型一定是将数仓模型跟业务需求很好的兼容结合，适合我们自己的才是最好的。数据仓库相比运营、分析以及产品是距离业务比较远的，很难产生立竿见影的效果，我们怎么评价工作的效能。

评价方面

1.  外部需求方：用户的满意度。
   1. 数据仓库对上服务企业领导支持数据决策，对下支持日常运营、分析业务问题。
   2. 好的数据仓库不仅能提供完整的数据指标体系，更是可以发现业务问题，提供解决思路。
2. 内部建设方：数据比较丰富完善、数据复用性强、规范性强
   1. 完善度：包括DWD、DWS、ADS层。跨层引用率：看DWD层是否完善，就看ODS层有多少表被DWS/ADS层引用。DWD以上的层引用的越多，就说明越多的任务是基于原始数据进行深度聚合计算的，明细数据没有积累，无法被复用，数据清洗、格式化、集成存在重复开发；汇总数据查询比例：考核汇总数据的完善度，主要看汇总数据能直接满足多少查询需求，如果汇总数据无法满足需求，使用数据的人就必须使用明细数据甚至原始数据。
   2. 复用度：数仓模型涉及的核心是追求模型的复用和共享，引用系数越高，说明数仓的复用性越好。
   3. 建模是否高内聚低耦合：业务上将相近或者相关的数据按照主题进行聚拢，方便查询和应用；
   4. 核心模型和扩展模型分离：根据用户的访问，将高频访问跟低频访问或者个性化的数据进行拆分，减少互相之间的影响；
   5. 命名清洗可理解：任务、表的命名需要清晰规范、一致，便于理解，字段指标命名同名同义；
   6. 公共逻辑下沉并且单一：多次处理的逻辑尽量下沉至公共层，一次性处理可以减少计算资源浪费，保证数据口径统一。减少ODS层数据表的访问率，好的数据模型是可以直接从dwd标准层进行支持分析的。公共层的下游依赖的统计；
   7. 成本与性能平衡：适当的数据冗余可以减少表之间的jion，减少shuffle，但是也不要过度冗余增加存储成本跟维护成本，控制计算时间、计算资源以及存储成本；
   8. 数据产出及时、稳定：处理逻辑不变，不同时间多次运行要保证数据的结果一致。保证日常任务时效产出；
   9. 规范度：主题域归属、分层信息、脚本任务以及表命名规范，字段指标命名统一规范（建立统一词根词素库）；
   10. 健壮性：业务快速迭代的情况下不会影响底层模型，业务系统新增或者变动对上层做到无感知迭代；

        一个好的数据仓库模型，对内做到降本增效，对外可以快速响应业务需求，支持数据决策，能够反应问题，找到原因，提出对策，跟进业务并且可以改善业务，加大出数据驱动的动力，体现数据资产价值。 

 延伸：如何量化数据仓库效能

1. 文档沉淀：需求文档、设计文档、开发文档、数据自测报告文档的数据以及文档相关UV；
2. 支持项目：支持立项项目数量，临时数据分析需求个数；
3. 数据仓库各层表的访问Pv、Uv：数仓建设前后，ods跟dw层表的搜索量、查询量变化；
4. 支持业务：提供数据分析次数、发现业务问题次数，解决业务痛点个数、改善业务流程个数；
5. 降本增效统计：数据仓库开发前后，存储成本、计算成本以及人力成本对比，工作效率的提升。