中台产品经理实战（3）：数据中心中台化案例

三爷茶馆 2023-07-21 09:45:32

一、中台化前的产品现状

在项目早期我们公司提供的服务就是在线酒店预订，这种业务模式的整个流程也不复杂，主要分为这几个环节：

BD进行拓店 -> 邀请酒店入驻平台 -> 平台上架 -> 用户下单 -> 分佣

重点来看第一个环节，BD拓店实际就是将线下的酒店住宿服务当做商品“进货”至公司的后台中，从而为后面整个服务奠定基础，这里也是整个业务的核心与数据唯一进口。

在这个环节中公司由BD与商务团队维护并积累的大量底层“商品”数据，而初期这些底层数据在数据库中，就是简单的以“Key=Value”形式进行存储。

产品经理，产品经理网站

存储字段截取

当经过一段时间的积累后，这种数据存储方式由于维度简单导致的结果，就是整个数据库的数据量在很短时间内出现猛增。

但是虽然看着每天都有“商品”数据入库，慢慢的我们却发现这些数据很多都是没有办法进行二次使用的，只能供特定的业务方进行独立使用。

具体来说，在公司内部我们通常会有多个业务团队，每个业务团队往往都会根据自己的业务需求在数据库中建立一张属于自己的数据库表（这里为了行文方便我们视作一个表），这些表的业务数据字段与定义方式都是按照业务方定制化进行的。

例如在当时，我们的酒店预订就分为两个业务团队：

非标住宿预定，也就是民宿；
标准酒店预定；

所以此时在后台我们有了两套业务数据体系，这些数据都是这两个业务方进行自主定义的。

二、挑战：业务线

这样的数据看似很寻常，目前很多企业也是这样对内部团队管理的。但是对于这种我称之为依托于前端统一团队的业务来说（两个业务方由统一的一群BD去进行扫街），我们实际上去做的就是将已经标准化了的数据（酒店录入数据）再次人为进行了割裂，变成了两个独立的业务数据库，如下图所示。

产品经理，产品经理网站

我们要知道很多企业平时日常所做的工作大多数都是在进行数据的迁移与整合，如：将用户行为数据与用户唯一标识数据结合，从而唯一确定分析这个用户的喜好。

那么也就意味着我们每破坏一次数据之间的关联性就意味着，为后期增加了一次需要进行反向操作，也就是将数据进行合并的工作负担。特别是我们将酒店天然性以业务墙进行了阻拦，更是破坏了数据的强关联性（同类数据）。

同时这样的数据也使得对于既属于民宿又属于标准酒店业务库中的数据成为总库的冗余数据，曾带来的一个很严重隐患，就是当民宿业务线的运营同学发现酒店名称发生改变并变更后，我们另一端的运营同学很难去即时发现并处理。此时在标准酒店业务端出现了多次用户下单后，该酒店因为店名与实际店名不统一，而旅客无法入住的情况，并多次投诉平台。

当然这只是若干次业务数据管理中的一个小小的缩影，正是因为这样的意外挑战出现，让我们对于现有的数据管理方式产生了要去进行变革的意图。

三、挑战2：创新业务

我们知道绝大多数互联网的产品本质就是以不同的展示形式、递进次序陈列出不同的数据，满足用户的信息需求。如新闻网站与今日头条都是在展示新闻数据，而陈列的次序一个是按编辑维度，一个是按读者的阅读习惯维度。

那么也就是说只要有了数据源，我们在这基础上就可以衍生出不同的产品。我们原公司业务也不例外，在我们收集了一段时间市场的酒店信息后我们就想着可以用这些数据来组织些新的产品，以此来满足不同细分市场人群。

如将酒店的基本信息数据（照片，介绍等）与第三方游记攻略类数据共享，提供数据输出服务。和想分析现有的数据的数据预测服务：根据不同地区的新增房源数据进行旅游真实热门景区排行。

这个时候面对之前分散的非标住宿预定与标准住宿预定两个独立业务，我们更想要看的两个业务线汇总后的全维度数据，而在现有条件下这个变得必须要逾越两个业务线的阻隔。

四、业务中台解决方案

面对这样的几个挑战，我们的选择就是利用中台去进行解决，此时中台1.0是这样构建的：

步骤1：中央集权

将酒店数据剥离各业务线团队，把酒店数据存储至独立的数据中心（也就是中台1.0）进行维护，打破各团队隔离，此时将原有的环节改为：

BD进行拓店 -> 邀请酒店入驻平台 -> 数据中心（新增） -> 平台上架 -> 用户下单 -> 分佣

而在新增数据中心进行统一维护后，面对各自团队的数据需求我们可以在数据中心划分为虚拟数据源用以进行支撑。

产品经理，产品经理网站

酒店数据与各个业务线生成的订单等数据都汇总到数据中心中，数据中心是整个企业的基础服务提供全局的数据。

步骤2：特异性管理

接下来让我们来分析下整个业务运作流程，在原有两个产品线的业务模式与创新产品的业务模式中，当我们以数据流转的整个视角来看，本质上这些业务就是下图所示的数据流。

产品经理，产品经理网站

不难发现，在这里作为数据源的提供方为业务方做了两个步骤的工作：

数据取用：根据业务方所要的数据范围提供数据（如：本次业务需要读取会员ID，会员姓名这两个字段）；
数据业务格式化：根据业务方所要的数据格式进行特定数据格式/顺序生成返回（如：业务方A返回数据格式：会员ID=“12311”+会员姓名=“张三”；业务方B返回数据格式：会员姓名->“张三”and会员ID->“12311”）。

对比这两个步骤的工作我们就能发现，第二个步骤实际上是原来整个后台支撑系统额外的工作的罪魁祸首。像上文提到的每次数据接口只能为一个业务方提供服务，这个接口由于数据返回格式是特定的所以具有很强的特异性，导致后台同学需要不断进行新的提供数据的接口的开发。对于不懂技术的同学，我们可以理解为后台同学在提供同样的信息而先后顺序不一样时，需要设计不同的传输通道。

大家可以看到这无疑就是巨大的浪费。大家可以回想下在自己的日常工作中这样的情况是不是也相当常见，例如：产品迭代中每次版本更新导致的需要重新设计接口（新旧产品就同一数据的不同封装形式的取用）；老版本数据接口与新版本的同一数据接口不同，需要分别维护。

所以当时我们是这样解决的，这两个步骤中第一个服务共性很高，很容易抽取成公共服务。我们就数据中心提供了一个标准的取数据接口，各个业务方只需要传输需要什么字段名称，我们的统一数据返回接口就把数据返回至业务方。这样在所有的版本中我们始终对同一批相同功能的接口进行维护（为了负载均衡），各个接口没有任何特异性都是标准的取数据接口，只根据请求内容进行内容返回，这样大大减少了开发量。

对第二步骤由于特异性特别高，我们将这种与业务强相关的东西下放到业务端，由业务方进行数据处理，加工成他们需要的组织形式再返回给客户方。

此时后台人员只需要开发面向数据源的数据输入接口，也就是将BD采集的数据进行清洗成为中台的原材料。此时数据中心也就是中台，将各个业务数据留存在这里，并提供统一的取数方法，前台业务人员根据需要去申请数据，将原来数据后台统一处理这一动作划分为：数据获取（中台）与数据业务端组合（前台）两部分。

而整个系统的架构也就变成了如下图的样子：

产品经理，产品经理网站