建设数据中台本质就是构建企业的公共数据层，把原先分散的、烟囱式的、杂乱的小数仓，合并成一个可共享、可复用的数据中台。
数据中台的解耦，图片来自艾瑞研究院
如何构建一个优秀的公共数据层呢，一共分五步。
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最后，应用迁移。
这个过程的核心是要注意数据的比对，确保数据的完全一致，然后进行应用迁移，删除旧的数据表。
综上，我们可以初步实现小数仓数据模型的整合，从而搭建数据中台的数据模型。
总之，建设数据中台不是一蹴而就的，它的建设往往是滚雪球的方式，随着一个个应用的迁移，中台的数据也越来越多，发挥的价值越来越大。
从数据模型的设计层面，我们逐步将分散、杂乱、烟囱式的小数仓整合成了可复用、可共享的数据中台。
那么，只要交付数据足够快，用户就会满意吗？答案肯定不是的，速度快只是其中一个方面，而另一方面是保证数据质量，这也是评估数据中台建设最重要的维度之一。关于数据质量的介绍请见下文。