数据中台实战(06)-数据模型无法复用，归根结底还是设计问题

谁借莪１个温暖的怀抱￠ 2024-02-25 04:37 14阅读 0赞

指标比喻成一棵树的果实，模型就是这棵大树的躯干，想果实好，须让树干粗壮。

### 1 痛点 ###

分析师一般结合业务做数分（需用大量数据），通过报表服务于业务部门运营。但数据中台构建前，分析师经常发现自己没有可复用的数据，不得不使用原始数据进行清洗、加工、计算指标。

由于他们非技术出身，SQL较差，多层嵌套，不择手段，资源消耗大，造成队列阻塞，影响其他数仓任务，引起数据开发不满。数据开发要求收回分析师的原始数据读取权限，分析师又抱怨数仓数据不完善，要啥没啥，一个需求经常等一周半月。分析师与数据开发矛盾开始！

#### 矛盾根源 ####

数据模型无法复用，烟囱式数据开发，每次遇到新需求，从原始数据重新计算，自然耗时。要解决这矛盾，要搞清数据模型设计成啥样。

### 2 好的数据模型设计 ###

俩表格是基于元数据中心提供的血缘信息，分别对大数据平台上运行的任务和分析查询（Ad-hoc）进行的统计。

##### 表1：离线调度任务/表统计 #####

![41c524789dfb424fb1828ef47597263f.png][]

看表1。表1中有2547张未识别分层的表，占总表6049的40%，基本无法复用。

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

##### 表2：一周内Ad-hoc 查询统计 #####

![8e01cbaf49f34980aca9ffe7a62f9b9a.png][]

已识别的分层的查询中，ODS：DWD：DWS：ADS的命中的查询分别是892：1008：152：305，37.8%查询直接命中ODS层原始数据，说明DWD、DWS、ADS层数据建设缺失严重。尤其ADS、DWS，查询越底层的表，就导致查询扫描数据量越大，查询时间越长，查询资源消耗也越大，数据使用人满意度也低。

##### 数仓分层架构图 #####

方便回忆数据模型分层的设计架构：

![09e96b9589e54b0ba56231ae11262e3e.png][]

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

经过分析，似乎找到理想的数仓模型设计应具备因素：“数据模型可复用，完善且规范”。

完善度：

*  DWD：跨层引用率
 *  DWS/ADS/DM：汇总数据查询比例

复用度：

*  DWD/DWS : 模型引用系数

规范度：

*  有多少表没有主题域、业务过程归属
 *  模型命名不规范
 *  字段命名不规范

总结，好的数仓设计标准：数据比较富完善、数据复用性强、规范性强。

#### 2.1 如何衡量完善度 ####

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

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

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

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

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

这和跨层引用率不同，汇总查询比例不可能100%，但值越高说明上层数据建设越完善，对数据使用人，查询速度和成本会减少，用得更爽。

#### 2.2 如何衡量复用度 ####

数据中台模型设计核心：追求模型的复用和共享，通过元数据中心的数据血缘图，可见：

*  较差模型设计，自下而上一条线
    
    ![791c2bae9424b93a35b96e4ccf34c05c.png][]
 *  理想模型设计，交织的发散型结构
    
    ![c31286e14dd30b8e66dda44d3a672344.png][]

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

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

如一张DWD层表被5张DWS层表引用，这DWD层表的引用系数就是5，若把所有DWD层表（有下游表的）引用系数取平均值，则为DWD层表平均模型引用系数，根据经验：

*  低于2较差
 *  3以上较好

#### 2.3 如何衡量规范度 ####

表1超过40%表无分层信息，模型设计层面显然不规范。看表有无分层，还要看有无归属到主题域（如交易域）。若无归属的主题域，就难找到这张表，也无法复用。

要看表的命名如stock，看到这表，知道属哪个主题域、业务过程？全量数据的表，还是每天增量数据？通过表名获取信息有限。一个规范的表命名应包括：

*  主题域
 *  分层
 *  表是全量快照，还是增量
 *  等信息

若表A中用户ID命名UserID，表B中用户ID命名ID，就会困扰使用者：这是一个玩意？所以我们要求相同的字段在不同模型中，它的命名须一致。

#### 2.4 如何吸收经验？ ####

*  可拿这些指标去评估自己的数仓现状
 *  制订一些针对性改进计划，如消灭这些不规范命名的表，把主题域覆盖的表比例提高到90%
 *  尝试完一段时间的模型重构和优化后，再拿这些指标测测是否真变好。很多数据开发向上级汇报工作时，喜欢用重构多少模型说明工作成果，老大想这些重构到底对数据建设有啥帮助？有无量化指标？

现在知道啥是好的数仓设计，可目前已存大量烟囱式开发，咋才能让它变成数据中台？

### 3 从烟囱式小数仓到共享的数据中台 ###

建设数据中台，本质就是构建企业的公共数据层，把原分散、烟囱式、杂乱小数仓，合并成可共享复用的数据中台。

#### 3.1 接管ODS层，控制源头 ####

ODS是业务数据入数据中台的第一站，所有数据加工的源头。控住源头才能根本避免重复的数据体系。

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

ODS层表的数据须和数据源的表结构、表记录数一致，高度无损，对ODS层表的命名方式：

ODS_业务系统数据库名_业务系统数据库表名

如ods\_warehous\_stock。

#### 3.2 划分主题域，构建总线矩阵 ####

主题域是业务过程的抽象集。业务过程是企业经营过程中一个个不可拆分的行为事件，如仓储管理有入库、出库、发货、签收，都是业务过程，抽象出的主题域就是仓储域。

##### 表3：电商业务的主题域划分 #####

![0ad2cd6f6075407fb9915913a353732e.png][]

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

主题域划后，开始构建总线矩阵，明确每个主题域下的业务过程的分析维度，如：

##### 表4 交易域的总线矩阵 #####

![b3c2b04931394dbb9466aaaebef2490a.png][]

#### 3.3 构建一致性维度 ####

*  售后团队的投诉工单数量有针对地区的分析维度
 *  而配送团队的配送延迟也有针对地区的分析维度

想分析因配送延迟导致的投诉增加，但两个地区的分析维度包含内容不一致，最终导致一些地区没办法分析。所以构建全局一致性的维表，确保维表只存一份。

维度统一的最大难题：维度属性（若维度是商品，则为商品类别、商品品牌、商品尺寸等商品属性）的整合。是否所有维度属性都要整合到一个大的维表中，也不见得。

*  公共维度属性与特有维度属性拆成两个维表。自营平台通常也有一些第三方商家入驻，但数量少。大部分商品都无店铺属性，就不建议将店铺和商品的其他维度属性，如商品类别、品牌设计成一个维表
 *  产出时间相差大的维度属性拆分单独的维表，如有些维度属性产出时间在凌晨2点，有些维度属性产出时间在凌晨6点，那2点和6点就可拆成两个维表，确保核心维表尽早产出
 *  维表稳定性产出考虑，可将更新频繁的和变化缓慢的进行拆分，访问频繁的和访问较少的维表拆分

对于维表的规范化命名，建议：

DIM_主题域_描述_分表规则

\*\*分表可理解：\*\*一个表存储几千亿行记录实在太大，所以要把一个表切割成很多小的分区，每天或每周，随任务被调度，会生成一个分区。

##### 常见分区规则 #####

<table> 
 <thead> 
  <tr> 
   <th>分表策略</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>DD</td> 
   <td>每天分区中保留的是历史至今的全量数据，根据业务使用场景制定例行清理策略</td> 
  </tr> 
  <tr> 
   <td>DI</td> 
   <td>每天分区中保留的是当日的增量数据，可以是汇总数据也可以是明细数据，一般永久保留</td> 
  </tr> 
  <tr> 
   <td>WD</td> 
   <td>每周的分区中保留的是历史至今的全量数据，根据业务使用场景制定例行清理策略</td> 
  </tr> 
  <tr> 
   <td>WI</td> 
   <td>每周的分区中保留的是对应周的增量数据，可以是汇总数据也可以是明细数据，一般永久保留</td> 
  </tr> 
  <tr> 
   <td>MI</td> 
   <td>每月的分区中保留的是对应月份的整个月的增量数据，可以是汇总数据也可以是明细数据，一般永久保留</td> 
  </tr> 
  <tr> 
   <td>MD</td> 
   <td>每月的分区中保留的是历史至今的全量数据，根据业务使用场景制定例行清理策略</td> 
  </tr> 
  <tr> 
   <td>ND</td> 
   <td>死表或者不定期更新的全量表</td> 
  </tr> 
 </tbody> 
</table>

#### 3.4 事实表整合 ####

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

##### 案例 #####

![5635414aa83147d08e66fb5e3b58864d.png][]

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

![b8b6c21894234618a426e6d849d6a7fb.png][]

仓储部门、供应链部门都有的库存明细表，因为仓储部门的统计粒度是商品加仓库，而供应链部门的只有商品，所以原则上两个表是不能合并，而是应该独立存在。

![2e6eece535cd41d0b80bec4f154735f3.png][]

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

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

![57c99595bddb453899878f4607580e34.png][]

DWD/DWS/ADS/DM命名规则：

[层次][主题][子主题][内容描述][分表规则]

#### 3.5 模型开发 ####

模型设计完成后，进入模型开发：

1.  所有任务严格配置任务依赖，若未配置任务依赖，会导致前一个任务没有正常产出数据，后一个任务被调度，基于错误的数据空跑，浪费资源，加大排障复杂度
2.  任务中创建的临时表，在任务结束前应删除，如不删，会发现有大量临时表占用空间
3.  任务名称最好和表名一致，方便查找关联
4.  生命周期的管理
    
    1.  ODS和DWD，尽可能保留所有历史数据
    2.  DWS/ADS/DM设置生命周期，7～30天
5.  DWD层表宜采用压缩的方式存储，可用lzo压缩

#### 3.6 应用迁移 ####

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

建设数据中台不是一口吃胖，往往滚雪球，随一个个应用迁移，中台数据也越来越丰满，价值越来越大。

### 4 数仓建模工具EasyDesign ###

这些步骤离不开好工具，为规范化数据模型设计，研发EasyDesign的模型设计产品，让这些流程实现系统化管理。了解如何设计这工具或选用工具时考虑的功能。

![c9625d31713e4d288ffdfa19cb12fd8c.png][]

EasyDesign构建于元数据中心之上，通过API调用元数据中心的数据血缘接口，结合数仓模型设计的指标，给出模型设计度量。

![8c4859b71bdb40079c59b4175a26f260.png][]

EasyDesign按主题域、业务过程、分层的方式管理所有的模型。

![b22837bcbafa4078b10076414a20074f.png][]

还提供维度、度量和字段基础字典的管理，同时具备模型设计审批流程的控制。

### 5 总结 ###

本文详细讲解数据中台的模型设计。从确立设计目标，到通过一系列步骤，将一个个分散杂乱、烟囱式小数仓逐步规整到一个可复用共享的数据中台，最后通过产品化实现系统化的管理。

*  完善度、复用度和规范度构成衡量数据中台模型设计的度量体系，可助你评估数仓设计好坏
 *  维度设计是维度建模的灵魂，也是数据中台模型设计的基础，维度设计的核心是构建一致性维度
 *  事实表的统计粒度须保持一致，不同统计粒度的数据不能出现在同一事实表

数据中台构建需半年一年，但数据中台建成后，研发效率提升明显。电商业务，中台构建后相比构建前，数据需求平均交付时间从一周缩到3天内，需求响应速度提升，为企业运营效果提升提供数据支撑。

通过数据中台构建，企业数据研发效率也大幅提升。

![51b8850737614c66927030ec6619791a.png][]

[41c524789dfb424fb1828ef47597263f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/6062d4e0549847a8825ccf84adf81fbc.png
[8e01cbaf49f34980aca9ffe7a62f9b9a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/10af34976e264c318b89bfad406012e8.png
[09e96b9589e54b0ba56231ae11262e3e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/9ec0d76339ff462caaf3e184eaedb122.png
[791c2bae9424b93a35b96e4ccf34c05c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/b301f7e8ae6f40869fc5d0ab750c79b6.png
[c31286e14dd30b8e66dda44d3a672344.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/87901af5c65245c7b3e4e3e7fa43154d.png
[0ad2cd6f6075407fb9915913a353732e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/73a63f03c172427ab650c03e25072b65.png
[b3c2b04931394dbb9466aaaebef2490a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/69122dd298d74ecfad7371fc3342927c.png
[5635414aa83147d08e66fb5e3b58864d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/002384f5bce3417ea48625963a9853d2.png
[b8b6c21894234618a426e6d849d6a7fb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/6e9ac36b02864e82ab5dd3dea54e1b63.png
[2e6eece535cd41d0b80bec4f154735f3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/c2afec726b014102ac5a1a3256eb58de.png
[57c99595bddb453899878f4607580e34.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/2c8eab47b25f4ccbb9c151f6c0bddc5f.png
[c9625d31713e4d288ffdfa19cb12fd8c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/515935b9d6f34d02973a4354175185ce.png
[8c4859b71bdb40079c59b4175a26f260.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/172da138fb824a079e4f7e5f39aaa76c.png
[b22837bcbafa4078b10076414a20074f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/2aebc5e48a5e46888d89dddabd27b8f2.png
[51b8850737614c66927030ec6619791a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/25/106d2a4a98f14b6b8f5e8b4ebed03150.png