在数据中台构建之前，分析师经常发现自己没有可以复用的数据集，不得不使用原始数据依次进行数据的清洗、加工、计算指标。

重复进行原始数据的清洗加工

由于业务部门的分析师大多是非技术出身，写的SQL可能比较差，多层嵌套对后台的计算和调度资源消耗非常大，造成队列阻塞，影响其他数仓任务，导致开发不满。

开发可能会取消分析师的原始数据读取权限，如果想取数，需要单独和开发沟通。

那么这会严重影响分析师的工作效率，分析师会抱怨开发提供的数据不完善、速度慢，一个需求经常要等一周甚至半个月。

以上场景矛盾的根源在于数据模型无法复用。数据开发是烟囱式的，每次遇到新的需求，都从原始数据重新计算，非常耗时且浪费资源。

01

“好”的数据模型是啥样？

在这里，我们先区分业务系统中的数据模型和数仓中的数据模型的不同（如下表）。

数据中台的数据模型是整合数仓的数据模型得到的，我们需要重点关注如何诊断当前数仓中数据模型的问题以及如何搭建数据中台可复用的数据模型。

回忆背景篇中关于数仓的分层设计，我们知道当前主流数仓分成以下4个层级：

下面的两张表是基于元数据中心提供的血缘信息，分别统计大数据平台上正在运行任务和即席查询。

即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。

表2中有2547张未识别分层的表，占总表的40%，它们基本没办法复用。

在已识别分层的读表任务中，ODS : DWD : DWS : ADS的读取任务分别是1072 : 545 : 187 : 433，直接读取ODS层任务占这四层任务总和的47.9%，这说明有大量任务都是基于原始数据加工，中间模型复用性很差。

在已识别的分层的查询中，表2中ODS : DWD : DWS : ADS的命中查询分别是892 : 1008 : 152 : 305，有37.8%的查询直接命中ODS层原始数据，说明 DWD、DWS、ADS 层数据建设缺失严重。

尤其是ADS和DWS，查询越底层的表，就会导致查询扫描的数据量会越大，查询时间会越长，查询的资源消耗也越大，使用数据的人满意度会降低。

进一步对ODS层被读取的704张表进行分解，发现有382张表的下游产出是DWS，ADS，尤其是ADS达到了323张表，占ODS 层表的比例45.8%，说明有大量ODS层表被进行物理深加工。

通过上面的分析，我们似乎已经找到了理想数据模型设计具备的要素：可复用、够完善、守规范。

那么，如何具体地度量这三个要素呢？

02复用度

数据中台数据模型设计的核心是实现模型的复用与共享。

通过元数据中心的数据血缘图，可以看到，一个比较差的模型设计，自下而上是一条线。而一个理想的数据模型设计，它应该是交织的发散型结构。

复用度可用模型引用系数衡量：引用系数越高，数据模型的复用性越好。

模型引用系数=被读取模型直接产出下游模型的数量

比如一张DWD层表被5张 DWS 层表引用，这张DWD层表的引用系数就是 5，如果把所有DWD层表（有下游表的）引用系数取平均值，则为DWD层表平均模型引用系数；从经验上看，一般低于2比较差，3以上相对比较好。

一种提升数据模型复用度且提升响应速度的策略，是在数据源和数据使用之间增加缓存层。缓存层中存放复用度较高的数据模型，以及这些数据模型所携带的数据。

分析师或业务人员根据需求查询数据时，如果是常用的数据模型，便不必再进行从源数据中取数、清洗、拼接等重复动作，从缓存中直接导入数据模型即可，大大提升复用数据模型的前端响应速度。

03

完善度

衡量DWD层是否完善，需要确认ODS层有多少表被 DWS/ADS/DM 层引用。

如果DWD以上的层引用的越多，就说明更多的任务是基于原始数据进行深度聚合计算的，明细数据没有积累，无法被复用，数据清洗、标准化、集成存在重复开发。

因此，可以用跨层引用率指标衡量DWD的完善度。

跨层引用率=ODS层直接被DWS,ADS,DM层引用的表数量/所有活跃的ODS层表。

跨层引用率越低越好，因为在数据中台模型设计规范中，不允许出现跨层引用，ODS 层数据只能被DWD引用。

针对DWS/ADS/DM层完善度，主要看汇总数据能直接满足多少查询需求（也就是用汇总层数据的查询比例衡量）。

如果汇总数据无法满足需求，使用数据的人就必须使用明细数据，甚至是原始数据。

汇总数据查询比例=DWS/ADS/DM层的有效查询/所有有效查询。

汇总数据查询比例越高，说明上层的数据建设越完善，对于使用数据的人来说，查询速度变快、性能提升。

04规范度

规范度其实没有特别明确的量化指标，主要根据数据表命名或归属主题域是否正确等情景，进行定性判断。

表2：各层表状态统计

例如，在表2中，有超过40%的表都没有分层信息，在数据模型设计中，这显然不规范。

除了确定表有没有分层，还要看它有没有归属到正确的主题域（例如交易域）。如果没有归属主题域，就很难找到这张表，也无法复用。

其次，我们需要看表的命名。一个规范的表命名应该包括主题域、分层、表是全量快照，还是增量等信息。

除此之外，如果在表A中用户ID的命名是UserID，在表B中用户ID命名是ID，就会对使用者造成困扰，这到底是不是一个表。

因此，我们要求相同的字段在不同的模型中，它的命名必须是一致的。

05我们进行一个简短的总结：

要想得到一个“好”的数据模型，首先，我们可以统计未规范表的数量（可仿照表2），诊断数据模型现状。

然后，制订一些针对性的改进计划，例如把这些不规范命名的表消灭掉，把主题域覆盖的表比例提高到90%以上。

在进行一段时间的模型重构和优化后，再拿着这些指标去评估是否有所改善。

很多数据开发在向上级汇报工作时，喜欢用重构了多少模型说明工作成果，很多老板会想，这些重构到底对数据建设有多少帮助？有没有一些量化的指标可以衡量？

因此，我们需要着重考虑是否真的改善了？以及如何证明真的改善了，而不是强调优化了多少模型。

假设当前我们已经对数仓中的数据模型做好评估和改进了，那么，我们需要怎么做才能让它变成一个数据中台呢？下一篇文章我们继续讨论。

如果喜欢麦聪的文章，记得点赞、收藏加关注嗷；关注+私信可获得超好用的数据中台产品安装包。