维度建模--如何设计事实表与维表 以及如何评估数仓模型

事实表有哪些特性

• 相对于维表增长快、状态变化频繁
• 每一个业务动作事件都可以作为一个事实，比如下单、付款发货
• 包含外键、关联相关维度
• 包含度量值

事实表设计方法

• 区分/选择业务执行过程（比如商品域包括发布、上架、下架、重发 日志域包括曝光、浏览、单击 交易域包括下单、支付、发货、确认收获）
• 声明粒度（维度属性组合表示细节程度）选择最细粒度
• 确认维度 以事实表粒度，确定维度主键，描述业务过程环境信息
• 确认事实 选择与业务过程相关的所有度量，粒度与声明的最细粒度一致
• 冗余维度 提高下游使用效率，不必要的join关联

事实表分类

1. 事务事实表 当天发生了才会有记录，不能更改（流水表）
2. 周期快照事实表

纬度表的设计

维度：看待事实的角度，与事实表相关联
举个栗子：对于订单表来说可以分为时间角度，地域角度，品牌角度，商品种类
维度分类：
退化维度
缓慢变化未

评估数仓模型标准

1.能够覆盖尽可能多的业务场景
2.通过元数据的数据血缘可以查看到各个层级活跃表数量和读写数量，读表任务数。通过读表任务书可以看出各个任务层的读取率，如果ods的读取率超过百分之40代表中间层的复用性很差
3.从分层查询次数可以看出资源消耗程度

如何做到完善度的判断标准

衡量dwd是否完善

衡量dwd是否完善，最好是看ods层有多少表被dws和ads引用，若引用的越多说明越多任务是基于dwd进行深度汇总计算的，且明细表已经做了数据清洗、格式化清洗。就避免了从ods中重复处理
可以用跨层引用率来衡量dwd的完善度
跨层引用率=ods直接被下游层引用的表数量/所有ods层经常被访问的表的比例
ods跨层引用率越低越好，在数仓模型设计规范中，我们要求不允许出现跨层引用，ods层数量只能被dwd引用

考察dws/ads层完善度

主要看汇总数据直接满足多少查询的需求，
汇总数据查询比例=dws/ads层的查询量/所有查询量
数值越高越完善，说明上层的数据建设越完善，对于使用数据的人来说，查询速度和成本也会减少

如何评估模型的复用度
数仓模型的设计追求复用性
引出模型引用系数指一个模型被读取直接产出下游模型的平均数量
系数越高说明复用性越好
举个栗子：一张订单dwd层被6张dws层表引用，这张dwd层的表引用系数就是6，如果把所有的dwd层引用系数取平均值，低于2是比较差，3相对是一个比较好的经验值

衡量规范度

通过血缘关系追踪，40%的表没有分层信息，说明数仓模型设计不规范
除了看有没有分层外，还要看它有没有归属到主题域
如果没有归属到主题域，就很难定位这张表，也就无法复用及管理他的生命周期。定位排查都是隐患。

时效稳定性

数仓任务是否能够按时生成按时推送，数据的延迟时长是H+1，T+1或者其他
所以从任务的时效，以及数据查询时间都是很好的评估点
从etl任务开始，记录和消耗时间
结合调度系统etl成功失败的分析，统计相应任务的成功失败次数
单独对某些类型的etl任务做实时采集记录，长时间没有收到任务做相应的告警处理

准确性/一致性

准确性：通过监控检测数据的准确性
一致性：有余计算口径或者开发人员的不同容易造成不同结果，因而要统一指标口径