中台实战(19):数据中台搭建方法论集合(上)

在上一篇文章《中台实战(18):大厂数据中台的通俗化解读》中,我们已经将数据中台的概念做了深入的剖析,接下来我会花两篇文章的篇幅为大家讲解数据中台建设的完整方法论。

中台实战(19):数据中台搭建方法论集合(上)

1、数据中台预建设

看过我的新书《中台产品经理宝典》的朋友们,应该很熟悉我在搭建中台里梳理了一个完整的MSS建设方法论。

其中有一个重要环节,称之为业务标准化(Standard),也就是我们需要先对当前业务有一个标准化定义,将公司内部不同业务线的业务流程梳理并合并为一套全公司通用的SOP,在此基础上去建设中台。

这就好比我们要进行大楼建设,如果没有一个稳定的地基,上层建筑就无法稳定下来,建设出的中台也会出现各种需求不符合,业务线不愿对接的现象。

那么在数据中台建设时也有同样的环节要去完成,我们称之为数据中台预建设。

具体来说数据中台的预建设分为两个步骤:

(1)标准化:完成对同一事物的统一描述

例如:统一不同事业线之间的指标口径,如财务指标中A业务线使用毛利,B业务线使用税后毛利作为业务线利润统计,这里在财务角度来看就是不统一的,需要进行统一。

(2)中心化:数据权限上升至企业层面

我们知道,之所以会出现在公司内部对同一事物的描述不同,其本质原因是因为各个业务线根据自己的需要去定义了具体的业务对象与数据存储规则。

例如我们以A,B两条业务线的会员数据来看:

A业务线定义会员存储表:

中台实战(19):数据中台搭建方法论集合(上)

B业务线定义会员存储表:

中台实战(19):数据中台搭建方法论集合(上)

从这两张表中我们可以直观的发现如下差异:

(1)A业务线的会员存储字段为4个,B业务线的会员存储字段为5个,因此也就是会员对象定义在本质上就有所不同;

(2)在会员活跃统计上,A业务线关注用户的访问时间,因此在数据库表中记录了上一次访问时间,B路线更关注用户的消费转化,因此记录的是最后消费时间。此时如果作为数据中台想要统计全公司会员的活跃情况,因为A,B业务线的会员活跃概念是完全不同的,这两者数据也就无法直接使用。

所以针对上述情况,为了避免各业务线的自主定义,因此在数据中台中通常会将数据权限进行拆分分离:

  • 控制权限:拥有对数据上层应用提供数据源的权利;
  • 读写权限:拥有数据读取与写入的权利;

据此我们也得到了有了数据中台后分层数据体系下的不同权限内容:

中台实战(19):数据中台搭建方法论集合(上)

从图中可以看到业务线只有数据读/写权限,无独立控制权限,通过这样的设计我们就实现了数据中心化,也就是由中台具体向上层应用提供数据。

在业务线内部,每个业务线可以根据自己的需要去定义数据应用,例如像上面的例子中定义自己的会员存储字段以及会员活跃定义。

但是一旦进入上层应用,如公司级BI报表统计时,由数据中台,根据各个业务线推送至此的业务数据进行重新计算。

从而确保各个业务线的数据是使用相同的标准、算法计算得出的相同结论。

2、全局数据设计

完成了预建设之后,也就是我们打完了地基,接下来需要做的就是全局数据设计。

所谓全局数据设计,实际上就是去确定我们的数据域是什么?也就是我们的整个数据需求边界是什么,我们需要为哪些业务对象设立指标进行监控。

一般来说数据中台的数据域管理可以分为如下两步:

(1)定义公司内部的统一主题:如会员,订单,商品等;

(2)完成数据归类:将属于该主题的数据都归类至该数据域中。

在我们定义完数据域,如商品域、订单域后,我们就可以在数据仓库中定义标准的数据堆,每一个数据对存储一个业务的数据域子集,以便将各个业务的原始数据都堆积在这里。

中台实战(19):数据中台搭建方法论集合(上)

只有这样建设后,我们才能实现上一步的为上层应用提供数据时有原料可以重新计算。

3、方案设计

在完成前面的“基建”后,数据中台的方案设计就可以被定义出来了,具体来说一个通用的数据中台可以拆解为三步走建设方法:

(1)业务数据集中维护管理

(2)数据标准化加工(统一计算口径)

(3)企业级数据应用创建

至此我们的上篇,数据中台预建设篇就完成了。在下一篇文章中,我们将重点来谈数据中台的三步走方案具体设计内容。

本文由 新媒体之家 作者: 三爷茶馆 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
1

发表评论