数据中台实战入门篇：双中台战略

中台是什么？

中台是阿里提出，在2015年年中的时候，他去参观了一家芬兰的游戏公司，叫做Supercell。

这家公司名字你也许不熟悉，但是他们开发的游戏你可能玩过，比如《部落冲突》。这家公司一年光是利润就有15亿美金，不过员工人数非常少，只有不到200个人，而且公司里每一个开发游戏的小团队，都只有六七个人而已。

这么小规模的团队，怎么做成了这么大的业务呢？

其中一个原因是他们把游戏开发过程中，要用的一些通用的游戏素材和算法整理出来，把这些作为工具提供给所有的小团队。同一套工具，可以支持好几个小团队研发游戏。这种管理方式，就是一个“中台”的模型。

中台又分为业务中台和数据中台。业务中台承载公司所有的通用业务，将一切业务数据化。数据中台则基于业务产生的数据反哺业务，将一切数据业务化。

业务中台是什么？

业务中台简单来讲，就是企业级功能复用平台，比如：淘宝下面有很多电商产品有toB、有toC其实他们用到的账号系统、交易系统、营销系统等，这些大模块都是通用的。如果每个团队都重新开发一套系统就是对资源的严重浪费。因此，有专门的团队负责开发这些通用的系统，再赋能给每个产品线，这样既做到资源的最大化重复利用，又可以将每条产品线的数据沉淀在一起。

数据中台是什么？

同样的如果每条产品线都配备数据分析、开发相关人员又是一种资源的浪费。

数据中台要做四个方面的工作分别是“采集”、“存储”、“打通”、“使用”。采集就是要采集各条业务线的业务数据、日志数据、用户行为数据等有用的数据。

存储就是要用更加科学的方式存储数据，一般采用三层建模的方式，让收集上来的数据形成公司的数据资产。打通就是要打通用户的行为数据和用户的业务数据，如电商用户的浏览、点击行为和用户的支付业务数据，就要做到打通。使用就是就打通的数据赋能业务人员、领导层进行决策，做到数据反哺业务。

业务中台、数据中台有什么关系？

其实没有什么必然的关系，公司有业务中台的话，数据中台的工作会好做很多。因为业务中台已经使业务数据存储到了一个地方，这样就不用再对每个产品线，沟通成本会大大降低。没有业务中台的公司也可以搭建数据中台，只不过多么一步要从各条业务线采集数据。所以，有了业务中台，数据中台的搭建会事半功倍。

什么公司适合搭建中台？

公司内有多条产品线，各个产品线之间有很多可以复用的功能。初创公司是不适合搭建中台的，因为中台是比较重的模式，有比较高的人力成本，初创公司前期还是更加专注你的业务。

业务中台总体架构

最底层是数据存储层，根据公司业务量的大小，选择合适的数据库存储。上面一层就是业务中台最核心的地方了包括n个中心，是可以扩展的，企业级的能力复用平台就体现在这里，业务中台会把所有通用的一个个的开发部署好，提供给各个产品线使用。

下面简单介绍一下用户、商品、交易、支付、营销中心让大家有个概念。

1）用户中心

互联网产品都会有用户的概念，用户模块有很多通用的模块能够复用，比如：注册、登陆、账号的管理，用户基础信息的管理等。

那些偏业务的信息不会存储到业务中台，还是会分散在各个应用。大家可以想一下，以前每一个产品线都需要开发登陆、注册这些功能，其实是对资源的严重浪费，现在只用各个产品线与中台对接起来就能实现同样的功能，还是提高了不少效率。

2）商品中心

拿我们公司的三条产品线举个例子：

环贸快版是为设计师提供打版服务的平台，就是商品的生产环节，要记录商品从设计到生产的全部信息。亿订是一个B2B的交易平台，为终端门店提供货源。要记录商品的上架、销售、售后信息。富运通则是一个物流平台，要记录商品的物流信息。我们把商品从生产、销售、运输的过程都汇聚在一起，就十分有基于以后数据中台的数据分析。

3）交易中心

任何有支付的产品都需要用到订单，包括：订单的生成，也就是用户提交订单的过程。

订单的状态管理，每个产品线的状态是不一样的，比如电商产品用户刚提交订单状态就是未支付、支付完成后就要修改成已经支付状态，当供应商发货完状态变成已发货、当用户确认自己收到的商品没有问题，那状态最终变为已完成。

环贸快版是一开始就是设计师提交需求，接下来就会有n家生产方报价，此时状态就边为已经报价。当设计师选择完一个供应商打版后就变成了生产中，生产完成后就再把版样发给了设计师，整个流程才结束。

4）支付中心

支付中心几乎是任何互联网中心都需要的模块，因为要想盈利必须要有线上的支付环节。要处理各个支付渠道的对接，比如：支付宝、微信、银联等支付方式。还要处理支付后的对账，一个一个订单用户应该支付多少钱，app应该抽多少钱，供应商应该分多少钱，有一套对账的逻辑在每天的检查，保证账目是平的。

5）营销中心

比如：我们做一个优惠券的活动，该怎么发券、领券、用券等都是通用的。

我们做一场h5的活动，该选择那些人做活动？以什么方式？推送、短信、公众号、电话等方式触达等等这些也都是通用的模块。营销中心和数据中台就联系比较紧密，怎么选择用户做活动是数据中台基于规则算好的，当活动完成后，数据中台再基于活动产生的数据做自动化的活动效果分析。

数据中台架构

数据采集层

每条业务线都会产生一定的业务数据，比如：电商产品如用户的加购数据、收藏数据、下单数据等随着用户量的增大会越来越多，这些数据大部分是存在业务中台。

还有用户的浏览行为、点击行为，这些行为会做相应的埋点，一般会以日志文件的形式存储。无论是业务数据库的数据还是日志文件的数据，我们都需要把它们抽取到数据中台做统一的存放。一般数据工程师会用用一些比较成熟的数据同步工具，将业务库的数据实时同步到数据中台，将离线日志数据以T-1的形式抽取过来，整合到一起。

数据计算层

数据抽取过来后，一般是按照原来的格式进行存储，面对海量的数据采用传统的存储方式是不行的。

业界一般采用分层存储的方式包括：操作数据层（Operational Data Store, ODS）、 明细数据层（Data WarehouseDetail, DWD）、汇总数据层（Data Warehouse Summary, DWS）和应用数据层（Application Data Store, ADS），可以将数据更高效、更科学的组织。

另外，为了保证数据指标的准确性，从指标的定义、业务口径、技术口径、指标的计算需要有一套严格的规范来定义，数据中台产品、开发都参考这套规范来工作，这样就能更大程度的保证数据的准确性。

数据服务层

数据已经被整合计算好了，怎么给产品和应用使用呢？

一般以接口的形式对外服务，开发人员将计算好的数据根据需要封装成一个一个的接口服务于数据产品以及各个产品线使用。对于简单的数据查询，复杂的数据查询如用户画像，和基于实时的数据查询，都可以通过接口的方式提供相应的服务。

数据应用层

数据产品分为几种：对内、对用户、对商家。

对内一般是公司的运营人员和领导，运营人员关注更多是明细数据，比如：电商产品的活跃用户持续性降低，我们如何提供数据支撑他们找出原因，领导层更关注的是一些大盘数据。

比如：公司近一年各个产品线的运营情况等，适合做一些大屏类的产品。针对用户我们也可以做一些创新，典型的比如说商品的推荐，让货找人而不是人找货，这样会有更好的用户体验。对商家的话可以提供一些数据服务，电商产品比如基于销售数据的流行趋势、行情，店铺的数据报告等。