数据模型无法复用？归根到底谁来“背锅”？

摘要：通过本文的学习你将收货一些实实在在的干货，尤其对于数仓的小伙伴而言，我相信会有一些新的的认识。本文主要内容包括：

    

    1、什么才是好的数据模型

    2、如何衡量模型的完善度、复用度、规范度

    3、如何实现数据共享

引言

上篇文章咱们一起讨论了如何管理指标从快手的指标规范出发聊一聊如何管理杂乱的数据指标，如果把指标比喻成一棵树上的果实，那me模型就是这棵大树的躯干，想让果实结的好，必须让树干变得粗壮。

首先来举个栗子（这可是真实场景奥）：

大多数公司的分析师会结合业务做一些数据分析，通过报表的方式服务于业务部门的运营。但在公司数据建设初期，分析师经常发现自己没有可以复用的数据，不得不每次使用原始数据进行加工、计算指标。

由于很多分析师并不是技术出身，所以SQL写起来比较随性，导致资源消耗较大，然后引起一系列不必要的麻烦...

这些问题根源还是在于数据模型无法复用，数据开发是烟囱式的，每次遇到新的需求，都要从原始数据进行清洗、计算。要解决这个问题，我们要思考的就是数据模型应该设计成什么样子。引出：数据模型无法复用，归根到底还是设计的问题。那么，如何设计好的模型呢，咱们慢慢聊。

数据模型设计之好坏

下面咱们来看一组数据，这两个表格是基于元数据提供的血缘信息，分别对大数据平台上运行的任务和分析查询（Ad-hoc）进行的统计。

下面是数仓分层架构图，方便咱回忆数据分层的设计架构：

首先来看图1。图1 中有2547 张未识别分层的表，占总表 6049 的 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 层表被进行物理深加工。

通过上面的分析，我们似乎已经找到了一个理想的数仓模型设计应该具备的因素，那就是“数据模型可复用，完善且规范”。

OK，那me如何衡量模型的完善度、复用度和规范度呢？下面咱慢慢聊~

数据模型的衡量指标

第一、如何衡量模型的完善度：

DWD 层完善度：衡量 DWD 层是否完善，最好看 ODS 层有多少表被 DWS/ADS/DM 层引用。因为 DWD 以上的层引用的越多，就说明越多的任务是基于原始数据进行深度聚合计算的，明细数据没有积累，无法被复用，数据清洗、格式化、集成存在重复开发。因此，提出用跨层引用率指标衡量 DWD 的完善度。

跨层引用率：ODS 层直接被 DWS/ADS/DM 层引用的表，占所有 ODS 层表（仅统计活跃表）比例。

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

DWS/ADS/DM 层完善度：考核汇总数据的完善度，我认为主要看汇总数据能直接满足多少查询需求（也就是用汇总层数据的查询比例衡量）。如果汇总数据无法满足需求，使用数据的人就必须使用明细数据，甚至是原始数据。

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

要明确的是，这个跟跨层引用率不同，汇总查询比例不可能做到 100%，但值越高，说明上层的数据建设越完善，对于使用数据的人来说，查询速度和成本会减少，用起来会更爽。

第二、如何衡量模型的复用度：

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

用模型引用系数作为指标，衡量数据中台模型设计的复用度。引用系数越高，说明数仓的复用性越好。

模型引用系数：一个模型被读取，直接产出下游模型的平均数量。

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

第三、如何衡量模型规范度：

表 1 中，超过 40% 的表都没有分层信息，在模型设计层面，这显然是不规范的。除了看这个表有没有分层，还要看它有没有归属到主题域（例如交易域）如果没有归属主题域，就很难找到这张表，也无法复用。

其次，你要看表的命名。拿 stock 这个命名为例，当你看到这个表时，知道它是哪个主题域、业务过程？是全量数据的表，还是每天的增量数据？总的来说，通过这个表名获取的信息太有限了。一个规范的表命名应该包括主题域、分层、表是全量快照，还是增量等信息。

除此之外，如果在表 A 中用户 ID 的命名是 UserID，在表 B 中用户 ID 命名是 ID，就会对使用者造成困扰，这到底是不是一个东西。所以我们要求相同的字段在不同的模型中，它的命名必须是一致的。

讲了这么多，要如何吸收经验呢？在这里，提几点建议：

可以拿着这些指标去评估一下，自己的数仓现状如何。

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

在尝试完一段时间的模型重构和优化后，再拿着这些指标去测一测是不是真的变好了。

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

有上面的知识，就可以轻松应对这个问题了。

现在你知道什么是好的数仓设计了，可目前已经存在了大量烟囱式开发，具体怎么做才能让它变成一个数据中台呢？

OK，咱们继续慢慢聊~

数据共享

数据共享的本质是从烟囱式的小数仓到企业级的、共享的数据中台。如何实现呢，下面提几个建议，仅供参考。

第一、接管 ODS 层，控制源头

ODS 是业务数据进入数据中台的第一站，是所有数据加工的源头，控制住源头，才能从根本上防止一个重复的数据体系的出现。

数据中台团队必须明确职责，全面接管 ODS 层数据，从业务系统的源数据库权限入手，确保数据从业务系统产生后进入数据仓库时，只能在数据中台保持一份。这个可以跟业务系统数据库管理者达成一致，只有中台团队的账号才能同步数据。

ODS 层表的数据必须和数据源的表结构、表记录数一致，高度无损，对于 ODS 层表的命名采用 ODS_ 业务系统数据库名 _ 业务系统数据库表名方式，比如ods_warehous_stock，warehous 是业务系统数据库名，stock 是该库下面的表名。

第二、划分主题域，构建总线矩阵

主题域是业务过程的抽象集合。可能这么讲，稍微有点儿抽象，但其实业务过程就是企业经营过程中一个个不可拆分的行为事件，比如仓储管理里面有入库、出库、发货、签收，都是业务过程，抽象出来的主题域就是仓储域。

主题域划分要尽量涵盖所有业务需求，保持相对稳定性，还具备一定的扩展性（新加入一个主题域，不影响已经划分的主题域的表）。

主题域划分好以后，就要开始构建总线矩阵，明确每个主题域下的业务过程有哪些分析维度，举个例子：

第三、构建一致性维度

售后团队的投诉工单数量有针对地区的分析维度，而配送团队的配送延迟也有针对地区的分析维度，你想分析因为配送延迟导致的投诉增加，但是两个地区的分析维度包含内容不一致，最终会导致一些地区没办法分析。所以我们构建全局一致性的维表，确保维表只存一份。

维度统一的最大的难题在于维度属性（如果维度是商品，那么商品类别、商品品牌、商品尺寸等商品的属性，我们称为维度属性）的整合。是不是所有维度属性都要整合到一个大的维表中，也不见得，下面提几个建议：

公共维度属性与特有维度属性拆成两个维表。在自营平台中，通常也会有一些第三方的商家入驻，但是数量很少。大部分商品其实都没有店铺的属性，这种情况，就不建议将店铺和商品的其他维度属性，比如商品类别、品牌设计成一个维表。

产出时间相差较大的维度属性拆分单独的维表，比如有些维度属性产出时间在凌晨 2点，有些维度属性产出时间在凌晨 6 点，那 2 点和 6 点的就可以拆成两个维表，确保核心维表尽早产出。

出于维表稳定性产出的考虑，你可以将更新频繁的和变化缓慢的进行拆分，访问频繁的和访问较少的维表进行拆分。

对于维表的规范化命名，建议用“DIM_ 主题域 _ 描述 _ 分表规则”方式。分表可以这样理解：一个表存储几千亿行记录实在是太大了，所以需要把一个表切割成很多小的分区，每天或者每周，随着任务被调度，会生成一个分区。

第四、事实表整合

事实表整合遵循的最基本的一个原则是，统计粒度必须保持一致，不同统计粒度的数据不能出现在同一个事实表中。来看一个例子：

在数据中台构建前，供应链部门、仓储部门和市场部门都有一些重复的事实表，我们需要将这些重复的内容进行去除，按照交易域和仓储域，主题域的方式进行整合。

对于市场部门和供应链部门的两张下单明细表，因为统计粒度都是订单级别，都归属于交易域下的下单业务过程，所以可以合并为一张事实表。

除此之外，还应该考虑将不全的数据补齐。对于 ODS 层直接被引用产出 DWS/ADS/DM层的任务，通过血缘，找到任务清单，逐个进行拆解。没有 ODS 对应的 DWD 的，应该生成 DWD 表，对于已经存在的，应该迁移任务，使用 DWD 层表。

DWD/DWS/ADS/DM 的命名规则适合采用“[层次][主题][子主题][内容描述][分表规则]”的命名方式。

第五、模型开发

模型设计完成后，就进入模型开发阶段，需要注意的点：

1. 所有任务都必须严格配置任务依赖，如果没有配置任务依赖，会导致前一个任务没有正常产出数据的情况下，后一个任务被调度起来，基于错误的数据空跑，浪费资源，同时增加了排查故障的复杂度；

2. 任务中创建的临时表，在任务结束前应该删除，如果不删除，会发现有大量的临时表存在，占用空间；

3. 任务名称最好跟表名一致，方便查找和关联；

4. 生命周期的管理，对于 ODS 和 DWD，一般尽可能保留所有历史数据，对于DWS/ADS/DM 需要设置生命周期，7～30 天不等；

5. DWD 层表宜采用压缩的方式存储，可用 lzo 压缩

第六、应用迁移

最后一步就是应用的迁移，这个过程的核心是要注意数据的比对，确保数据的完全一致，然后进行应用迁移，删除老的数据表。

总的来说，建设数据中台不是一口气就能吃成一个胖子，它的建设往往是滚雪球的方式，随着一个个应用的迁移，中台的数据也越来越丰满，发挥的价值也越来越大。

写在最后

本文和大家分享了模型的设计，是不是学习到了一二呀。从确立设计目标，到通过一系列步骤，将一个个分散的、杂乱的、烟囱式的小数仓逐步规整到一个可复用、可共享的数据中台，最后通过产品化的方式实现系统化的管理。这是不是每个数仓工程师都应该为之努力的呢~

数仓\中台建设是一个时间稍长的工程，但建成之后，对研发的效率提升非常明显。所以呀，各位小伙伴，收集好知识就大干一场吧，不然怎么知道自己的边界在哪儿呢~淦~