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

数据中台的解耦，图片来自艾瑞研究院

如何构建一个优秀的公共数据层呢，一共分五步。

01

接管 ODS 层，控制数据源头。

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

数仓基础架构图

因此，数据中台团队必须全面接管 ODS 层数据，可以从业务系统的源数据库权限入手，确保数据从业务系统产生后进入数据仓库时，只能在数据中台保持一份。

此外，把控 ODS 层表的数据必须和数据源的表结构、表记录数一致，高度无损，对于 ODS 层表可采用 ODS_业务系统数据库名_业务系统数据库表名 的方式命名。

02

划分主题域、拆分业务维度，构建总线矩阵

主题域是业务过程的抽象集合。例如，库存的仓储管理过程有入库、存放、出库、配送、签收等，这些都是业务过程，抽象出来的主题域就是仓储域。

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

待主题域划分好后，就要开始构建总线矩阵，需要明确每个主题域下的业务过程有哪些可拆分的维度。（如表 1）

表 1:总线矩阵

03

构建一致性维度。

例如，售后团队的投诉工单数量有针对地区的维度，而配送团队的配送延迟也有针对地区的维度。

当拆分因为配送延迟导致的投诉增加，但是两个地区的维度包含内容不一致，最终会导致一些地区没办法分析。

因此，我们需要构建全局一致性的维表，确保维表只存一份。

维度统一的最大的难点在于维度属性（如果维度是商品，那么商品类别、商品品牌、商品尺寸等商品的属性，称为维度属性）的整合。

那么，是不是所有维度属性都要整合到一个大的维表中？具体情况需要具体分析：

• 公共维度属性与特有维度属性拆成两个维表。

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

• 产出时间相差较大的维度属性拆分成单独的维表。

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

除此以外，更新频繁的和变化缓慢，访问频繁的和访问较少等不同情景，都可需要将维表拆分。

对于维表的规范化命名，建议用 DIM_主题域_描述_分表规则 方式。

关于“分表规则”，例如，一个表存储几千亿行的记录实在是太大了，所以需要把一个表切割成很多小的分区，每天或者每周，随着任务被调度，会生成一个分区。

常见的分表策略如下：

表 2:分表策略

紧接着，事实表整合。事实表整合的核心是统计粒度必须保持一致，不同统计粒度的数据不能出现在同一个事实表中。

事实表整合

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

统计粒度不同，无法合并

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

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

统计粒度一致，需要合并

除此之外，还应该考虑将不全的数据补齐。对于 ODS 层直接被引用产出 DWS/ADS/DM 层的任务，通过血缘，找到任务清单，逐个进行拆解。

没有 ODS 对应的 DWD 的，应该生成 DWD 表，对于已经存在的，应该迁移任务，使用 DWD 层表。DWD/DWS/ADS/DM 的命名规则适合采用 层次_主题_子主题_内容描述_分表规则 的命名方式。

04

模型开发。

模型设计完成后，进入模型开发阶段，此阶段应该注意：

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

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

• 任务名称与跟表名一致，方便查找和关联；

• 对数据实现生命周期的管理。对于 ODS 和 DWD，一般尽可能保留所有历史数据，对于 DWS/ADS/DM 需要设置生命周期，可以保留 7-30 天不等。

05

最后，应用迁移。

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

综上，我们可以初步实现小数仓数据模型的整合，从而搭建数据中台的数据模型。

总之，建设数据中台不是一蹴而就的，它的建设往往是滚雪球的方式，随着一个个应用的迁移，中台的数据也越来越多，发挥的价值越来越大。

从数据模型的设计层面，我们逐步将分散、杂乱、烟囱式的小数仓整合成了可复用、可共享的数据中台。

那么，只要交付数据足够快，用户就会满意吗？答案肯定不是的，速度快只是其中一个方面，而另一方面是保证数据质量，这也是评估数据中台建设最重要的维度之一。关于数据质量的介绍请见下文。