1.2 双中台实战案例
笔者所在公司是一家做服装批发业务的互联网公司，接下来笔者以所在公司搭建的中台项目为实战案例解析一下中台的架构。
如图1-2所示，笔者公司主要有三条产品线，分别是打版服务、电商服务、快递/物流服务。
图1-2 笔者所在公司的中台架构
打版服务主要是给原创设计师提供服装打版、生产的平台。设计师有打版需求则可以在打版平台上选择合适的供应商先进行打版，如果设计师觉得工厂提供的服装样版还可以，就可以把自己设计的服装上架到电商产品线去销售，如果该服装在电商平台上获得市场认可，就可以集单大批量生产，集单生产可以大大降低生产成本。平台的供应商在大批量生产服装后就可以用快递/物流服务把衣服发货给采购商。电商服务的用户和销售数据能直接引导打版平台的业务；在服装被生产出来后，又可以用快递/物流服务运输给采购商。我们公司的角色就是搭建一个产业互联网的平台，从服装的生产到销售，再到运输都无缝地连接起来，从而打通服装产业的上下游。这三条产品线的无缝连接是靠底层的业务中台和数据中台来支撑的。每条产品线都会用到用户、支付、营销活动等模块，业务中台把这些功能进行模块化封装，使各条产品线都能更快地搭建自己的基础功能，做到一切业务数据化；数据中台对各条产品线的核心数据进行回收，通过销售数据反哺生产和供应链，这样就做到了“一切数据业务化，通过数据赋能业务”。
1.2.1 业务中台架构
先来看一下业务中台的架构，如图1-3所示。
图1-3 业务中台架构
业务中台的底层是数据存储层，可以根据公司业务量的大小，选择合适的数据库存储。
再往上一层就是业务中台的核心部分，其包括多个“中心”，是可以扩展的。作为中心化的能力复用平台，业务中台的特点就体现在这里，其把所有的通用模块单独开发和部署好，提供给各条产品线，各条产品线可以插拔式地使用。下面简单介绍一下业务中台的一些通用模块：用户中心、商品中心、交易中心、支付中心、营销中心。
（1）用户中心。用户中心（或称用户模块）是每个互联网产品都会用到的，只是每个互联网产品的用户类型不一样。比如注册、登录、账号的管理、用户基础信息的管理等这些通用功能的数据会被存储于业务中台中，但是那些偏业务的十分个性化的数据则不会，还是会被分散存储在各个应用中。我们可以想一下，以前每条产品线都需要开发登录、注册这些功能，其实是对资源的严重浪费，现在只要让各条产品线与中台对接起来就能实现同样的功能，这样就大大提高了开发效率。
（2）商品中心。笔者公司的三条产品线（打版服务、电商服务、快递/物流服务）都围绕着商品运转。打版服务会记录商品从设计到生产的全部信息；电商服务会记录商品的上架、销售、售后信息；快递/物流服务则会记录商品的运输信息。商品中心汇集了商品生命周期的所有信息。因为商品的数据都汇聚在一起，也就十分有利于数据中台的数据分析工作。
（3）交易中心。交易中心主要与订单的生成和状态管理相关。对于不同的产品线，状态管理是不一样的。在电商服务产品线中，当电商产品用户刚提交订单时，订单状态变为“未支付”；支付完成后，订单状态就要修改成“已经支付”；当供应商发货完毕时，订单状态就变成“已发货”；当用户确认自己收到的商品没有问题时，订单状态最终变为“已完成”。在打版服务产品线中，最开始设计师会提交需求，接下来就会有多家生产厂家报价，此时商品状态就是“已经报价”；在设计师选择一个生产厂家打版后，商品状态就变成“生产中”；直到生产厂家完成打版并把版样发给了设计师，整个流程才结束。
（4）支付中心。支付中心也是几乎所有互联网产品都需要的模块，因为互联网产品要想盈利就必须要有线上支付环节。支付中心需要处理各个支付渠道的对接（比如支持支付宝、微信、银联等支付方式），还要处理支付后的对账——每个订单用户应该支付多少钱、平台方应该抽取多少钱、供应商应该分多少钱，需要一套十分严谨的对账逻辑保证各条产品线的账目是平的。
（5）营销中心。比如公司要做一个发放优惠券的营销活动，那么该活动的发券、领券、用券等环节都可以采用通用的模块。另外，应该选择哪些人做活动、以什么方式（如推送、短信、公众号、电话等）触达，这些环节也都可以采用通用的模块。营销中心和数据中台联系得比较紧密，比如“如何选择用户做活动”就可以通过数据中台基于规则推算出来，而且在活动完成后，数据中台可以基于活动产生的数据做自动化的活动效果分析。
1.2.2 数据中台架构
接下来我们看一下数据中台的架构，如图1-4所示。
图1-4 数据中台架构
从下往上看，第一层是数据采集层。企业内每条产品线都会产生一定数量的业务数据，比如电商服务产品线的用户的加购（即将商品加入购物车）数据、收藏数据、下单数据等随着用户量的增大会越来越多，这些数据大部分被存储于业务数据库中；还有用户的浏览行为、点击行为，这些行为会做相应的埋点，产生的数据一般会以日志文件的形式存储。无论是业务数据库的数据还是日志文件的数据，我们都需要把它们抽取到数据中台中做统一的存放。一般数据工程师会用一些比较成熟的数据同步工具，将业务数据库的数据实时同步到数据中台，同时将离线日志数据以“T-1”的形式抽取过来，整合到一起。
第二层是数据计算层。数据中台要同步企业内多条产品线的数据，数据量相对来说是比较大的。海量的数据采用传统的存储方式是不合理的。业界一般采用分层建模的方式来存储海量数据。数据的分层主要包括操作数据层（Operational Data Store，ODS）、维度数据层（Dimension，DIM）、明细数据层（Data Warehouse Detail，DWD）、汇总数据层（Data Warehouse Summary，DWS）和应用数据层（Application Data Store，ADS）等，通过分层建模可以令数据获得更高效、更科学的组织和存储。另外，为了保证数据指标的准确性和无歧义性，企业内部的数据指标需要通过一套严格的数据指标规范来管理，包括指标的定义、指标的业务口径、指标的技术口径、指标的计算周期和计算方式等。数据中台的产品人员、开发人员都要参考这套规范来工作，这样就能更大程度地保证数据的准确性和无歧义性。
第三层是数据服务层。数据经过整合计算后，如何被调取和使用呢？数据中台一般以接口的形式对外提供服务，开发人员将计算好的数据根据需求封装成一个个的接口，提供给数据产品和各条产品线调用。
第四层是数据应用层。数据产品分为几种：针对内部的数据产品、针对用户的数据产品、针对商家的数据产品。针对内部的数据产品一般用于服务公司的产品/运营人员和领导层。产品/运营人员更关注明细数据，比如，如果电商产品的活跃用户持续减少，数据中台如何通过数据帮助他们找出原因；领导层更关注大盘数据，比如根据公司近一年各条产品线的运营情况决定是否开发大屏类产品。针对用户的数据产品可以基于数据中台整合后的数据开发一些创新应用，比如个性化商品推荐，让“货找人”而不是“人找货”，提高了人货匹配的概率，同时也提高了用户的下单概率。针对商家的数据产品可以基于数据中台为商家提供数据服务，比如电商产品基于销售数据制作关于流行趋势、行情、店铺的数据报告等。