一、数仓模型优化-如何判断一个数据模型的好坏
1.完善度
汇总数据能直接满足多少查询需求，即应用层访问汇总层数据的查询比例
跨层引用率：ODS层直接被DWS/ADS/DM层引用的表，占所有ODS层表比例
可以快速响应业务方的需求
比较好的模型，使用方式是可以直接从该模型获取所有想要的数据的，如果DWS,ADS,DM层直接引用ODS层的表比例太大，即跨层引用率太高，则该模型不是最优，可以继续优化
2.复用度
模型引用系数：模型被读取并产出下游模型的平均数量
3.规范度
主题域归属
分层信息
脚本及任务命名规范
表命名符合规范(清晰、一致，见名知意)
字段命名是依赖于词根
4.稳定性
能否保证日常的sla（时效保障）
5.扩展性
新增加的模型是否和老的模型出现冲突，增加新的模型，在老模型上增加字段，能否可行
6.准确性&一致性
输出的指标数据质量能够保证
7.健壮性
业务快速更新迭代的情况下不会太影响底层模型
8.底成本
计算时间成本
计算资源成本
存储成本
总结
完善度，复用度，规范度基本上是需要了解业务，然后根据元数据信息去做统计分析的
稳定性，低成本是需要对任务进行优化，比如sql调优等
准确性和一致性是需要一套质量管理系统及指标一致性管理方案的，包括数据源，口径和指标管理平台等
二、聊一聊数据仓库的 KPI 怎么定
0x01 思考角度
首先，要明确的一点是数据最终是要服务于业务的！但是，数据仓库一般又不直接对接于业务，而更多地对接数据分析系统、用户画像系统和推荐或广告系统等。因此不容易用业务指标来衡量数据仓库的效果。
那么我们可以换一个角度，从数据仓库要解决的问题来考虑。简单地讲，数据仓库要做的是提高数据能力、提高数据分析效率、提高数据质量的。
那么，怎样既体现了服务业务，又体现了提高了整体的数据服务能力呢？这就是下面要讨论的 KPI 怎么定。
0x02 怎样定 KPI
定 KPI 在某种程度上也可以理解为工作的评价标准。对于数据建设来讲，我们可以从工作内容是否可量化的角度来考虑。
个人认为真正价值最高的是那部分不可量化或者不容易量化的工作内容。这些工作可以是：
- 一、数据仓库整体的设计（比如主题设计、通用维度的设计、数据分层的设计）；
- 二、数据规范的设计（比如说表和字段命名规范、Sql 编写规范）。
对于这部分内容，居士建议可以通过写文档的形式体现，最终统计出这些工作带来的效果（KPI 之一）：
- 比如说需要写多少和数据仓库设计相关的文档
- 有哪些业务相关的表将会按照你的设计来卡发
- 优化了多少数据分析的流程
上面的内容更多的像是品牌影响力，不容易体现具体的工作产出。我们聊一下相对容易量化的工作内容。比如说中间表对业务方的支持情况，解决了多少业务的痛点，提高了多少的数据质量等等。
具体到点的话，大致可以总结出下面的一些内容（KPI 之二）：
- 将要解决哪些业务问题（多少业务、多少报表用了你的中间表）
- 将会替换多少原始表的使用频率（比如数据分析查询你的表的次数，以前都是查原始日志的）
- 将要解决了多少数据口径不一致，数据质量的问题（可以加上告警，统计出来提前发现了多少数据问题）
0x03 举个栗子
上面列了一些居士大致思考的一些点，在具体写 KPI 的时候，可以从中选三四条。
举个简单的栗子，仅供参考：
- 完成数据仓库的设计，包括主题设计、数据分层和表字段命名等内容，完成10篇以上 Wiki
- 完成店铺主题相关的中间表的设计和开发，满足90%的数据分析需求。
- 完成基本的数据监控功能，能够监控关键数据的数据迟到、掉零、环比等内容。
大致解释一下，根据上面的栗子，在半年后做工作汇报的时候可以大致这样写：
- 已完成数据仓库设计相关文档的编写，总计25篇 Wiki，总阅读量10w。
- 已完成店铺主题相关的中间表的设计和开发，共计15张中间表，日均访问次数400次，占店铺主题相关总任务数的98%。
- 完成基本的数据监控功能，共计监控380张业务表，提前发现了14起数据异常。
0xFF 总结
上面就是数据仓库相关的 KPI 该怎么定的内容，具体的内容要和现实的业务情况相结合，因此本文仅起到抛砖引玉的作用，希望读者朋友们看后能有一些启发。
不足之处多多指出，一起交流进步。