参考文章：数据模型无法复用，归根结底还是设计问题
前言：
我们在日常工作当中，经常会被领导或者同事问及，数仓很重要我知道，但是你怎么评价数仓的好与坏？所以本文我们针对数仓中的模型篇进行分析，通过一系列的指标来合理的评估数仓模型的好坏，由于作者认知有限，欢迎同行批评指正。
前提：
数据平台、数据门户和即席查询的日志数据收集，及相关的血缘关系解析。如果没有这些收集到的元数据支撑，则相对困难。
数据准备：
1.我们基于收集到的日志解析数据创建临时表，report_key 表示目标表，dep_tbl_name 表示依赖的源表
表1
2.按下表统计输出模型中相关数据
表2
3.按下表统计HUE中即席查询的相关数据
1.数仓的广度
顾名思义，这里的广度就是指数仓建设的完善度，业务覆盖越完整，越能满足业务的需求，利于业务方的使用。
DWD（明细层） 层完善度：
这里引入一个指标：跨层引用率 ，即dws adl直接引用ods表的数据，而不是通过dwd相关清洗表。
计算口径：调度作业里，dws和adl两个分层中，引用了ods的作业数/全部作业数的占比，比例越高，则完善度越差，说明dwd层的支撑性不好
计算逻辑：
select
concat(round(count(distinct if(dep_tbl_name like 'ods%',report_key,null))/count(distinct report_key)*100,2),'%')
from temp.tmp_xhl_depend
where prod_line<>'AD-HOC' and report_key not like 'dwd%' and report_key not like 'dim%'
结果明显很高，这说明我们的dwd表完善度不高，因为有76%的汇总层作业引用了ods原始表的数据。
但我们进一步分析可以发现，这种结果可能又2种原因；1.DWD完善度不够，只能用ODS表；2.也有可能是因为存在DWD表，但是相关下游并未引用，结合我司实际，发现大量引用ods的表和作业为数据门户来源，也就是分析师的报表，看来数仓的中间表推广还任重道远啊，，，
DWS/ADS/DM（由于我们没有设置独立的集市，宽表统一存放于DM层，这里不包含DM） 层完善度 :
这里引入一个指标：汇总查询占比 ，即dws adl在所有的即席查询中，占全部查询需求的百分比。
汇总查询比例不可能做到 100%，但值越高，说明上层的数据建设越完善，对于使用数据的人来说，查询速度和成本会大大降低，远优于基于ods和明细的重复性查询。这里就笼统的基于表3进行统计占比即可。
2.数仓的深度
数仓的深度，是指数仓调度的数据依赖链路，原则上不应该链路过深，因链路太深不利于日常的维护和问题查询，因不好统计，这里不作为统计指标，在具体数仓项目的实施时，如发现链路较长的作业，可及时干预调整。
3.规范度
模型的规范度是数仓建设的一个考核点，但是不太好量化。比如表命名是否符合分层
1.正式表命名规范：层次+业务域名称+数据域名称+自定义表名+刷新周期 eg：dwd_xxx_usr_ base_info_df
2.临时表命名规范 tmp+目标表名
3.业务域命名规范 云记账：cab(cloud account book) 卡牛:kn 爵士卡：jcard 随手记(待遗弃)：ssj
4.主题域命名规范 记账：jz 日志: log
5.刷新周期规范 按天:d , 按周:w, 按月:m
6.存储策略规范 增量 i 全量 f
7.所有表都是分区表
字段命名是否统一？所有的命名字符是否均来源于词根库等，具体如何评价，建议开发相应的脚本对表命名进行打散匹配。统计非规范表数量。
并纳入到整体评价里，分配适当的权重，作为一个考核指标。
4.复用度
这里引入一个指标：模型引用系数：一个模型被读取，直接产出下游模型的平均数量.
比如一张 DWD 层表被 5 张 DWS 层表引用，这张 DWD 层表的引用系数就是5，如果把所有 DWD 层表（有下游表的）引用系数取平均值，则为 DWD 层表平均模型引用系数，一般低于 2 比较差，3 以上相对比较好（经验值）。所以，假如这里我们没有血缘关系做支持，就无法得出相关指标去衡量复用度
计算逻辑：
select avg(rely_cnt) from (select dep_tbl_name,count(distinct report_key) as rely_cnt from temp.tmp_xhl_depend where report_key like 'dwd%' or report_key like 'dim%' group by dep_tbl_name) t;
网友评论