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