兄台聊“中台”

封面

什么是中台？

最近“中台”这个概念还是比较火，正好笔者也负责了一个数据化的项目（可以美其名曰数据中台建设项目），在这里也聊聊自己的看法，文中有书推荐。

从开发的角度说，我们知道一般开发分为前台和后台，还有平台等，但这都是技术角度的划分，当然还有很早的其他概念，比如lass，pass，sass；以及华为曾经提出过的“项目，产品，技术”开发模式。这些其实都和“中台”的思想有异曲同工之处。

对于“中台”，个人认为它首先是一种解决方案，是业务发展到一定阶段而必须诞生的产物。但是和技术上的后台又有什么区别呢？

这里引用（已经烂大街的故事）“美军作战阵型”的演变历程的故事：美军在二战时，以军为单位作战；越战时，以营为单位作战；而到了中东战斗时，则以7人或者11人的极小班排作战了，因为当时有了“强大的军事指挥中台”这样的解决方案。

这里强调了“军事”，也就是说这一套方案拿到其它领域去可能不适用了，虽然底层也用了雷达，卫星，气象，战场数据分析、数据存储、分布式、算法模型等通用能力的支撑。

中台具有业务特性。这也是区别与我们前面说到的这些技术概念的关键之处。

除了业务特性，个人认为它具备几个特点：可复用、可共用、可迭代、面向未来。

为什么需要中台？

我们从它的几个特性来简单聊聊。

可复用

想要支撑业务的快速迭代，新产品的构建必须要求中台服务拿来即用。而不是重头“造轮子”。

可共用

这个是中台中比较关键的一个点，可共用就要求中台的建设以及服务是跨组织和部门的，以前各个部门各自为政独自做信息化建设的模式就得打破。

阿里在之前有个组织叫共享事业部，现在应该归入了中台事业群。它的作用就是抽象出天猫、淘宝，聚划算，支付宝等顶级业务的共性业务（比如：用户中心、订单中心、支付中心、认证中心、日志中心，类目管理，推荐等等），并从其中剥离出来放在共享事业部中进行迭代和维护。你天猫、淘宝，聚划算，支付宝就不要重复搞了。

这在很多企业实际上面临的是组织结构的调整，共性服务不可能在某一个业务部门去做，必须整合或者重新成立组织。

可迭代

有了可复用和可共用这两个特性之后，自然而然的要求中台要长期迭代，因为业务特性决定了，服务必须随业务变化而变化，而不是求“稳定”。不管是你的数据模型、服务接口都得随业务去做改变。

面向未来

这个其实是一个战略特性，中台战略对很多企业来说是“功在当代，利在千秋”，当前很多企业构建中台之后，短期实际上并不会发挥太大作用，而且耗资巨大（阿里的一套飞天私有云，上来就是几十台机器的集群，几千万的成本），但是有了中台的框架，构建了业务服务标准、数据标准、中台运营标准，只需要慢慢将应用接入中台即可。这是一个“培养、驯服”的过程。不光是能力的转换，也是思维的提升，要求组织里所有人都有“资产化”的观念。

接下来聊聊我在参与数据中台项目建设中的一些总结。

这里先推荐几本书大家可以看看。两本讲中台，一本讲中台中的元数据建设。

不喜可直接跳过。

数据中台 元数据

聊聊数据中台

从中台的特性上来说，数据中台的建设必须从业务出发，取之于业务，用之于业务，随业务迭代。

正好笔者也参与了相关项目，可以说说我关于数据中台一些建设思考。一个企业或组织数据中台的建设个人认为需要以下几个步骤：

数据中台结构

数据汇聚

这一步只是将各个异构数据源汇集到数据中台的统一数据源中，和我们常说的ETL的区别是，这里没有T（转换）的过程，只有抽取和加载。因为这个时候我们还不知道业务的转化规则，只是先将数据都汇聚过来。可能中间会初略的有些数据过滤。

这个时候中台中的数据结构其实和外部数据的数据结构完全一致。只不过字段类型、长度、表命名根据中台选项有了统一的规则。

这一步形成的数据也叫做 “贴源数据” 。

数据标准制定

数据都汇聚过来之后是杂乱无章的，无法为业务提供支撑，这个时候就需要按照不同的业务域要求去分析数据标准。这是最难的一个步骤，不同的业务域需要懂业务的人出来梳理。从业务流程，数据流，梳理业务对象（如：主数据，基础数据等），逻辑对象。最终形象物理模型构建标准。

模型创建

在有了数据标准之后，就要按照数据标准来构建物理模型，一般指的是数据库表或者其他数据存储的业务对象结构。

数仓建设

这一步其实就是ETL中的T的部分，根据标准构建数据转换规则，并根据数据频率构建调度任务，完成数据从“贴源数据库”向标准库的转换。

这一步形成了“业务标准数据库”也可叫“数仓”。其按业务域划分，基础库则通用。

数据开发

实际上有了数仓之后，已经可作为业务开发的基础库来使用了，通过构建标准服务来为上层应用提供支持。

这里的数据开发特指我们说的大数据分析、机器学习或者挖掘等业务开发。基于特定的模型算法产出数据产品，为上层业务或者组织提供决策支持。如：推荐、用户画像、智能识别等能力。

这一步可形成“产品库”。

数据服务

当我们有了标准数据数据，也有了数据产品之后，必须通过服务才能让上层业务和组织享受到数据的价值。对于服务的构建可根据企业体量和业务系统技术架构的不同进行选型，如：http，消息队列、界面集成、数据共享等方式。

数据运营

数据运营是数据中台持续发展的关键之处，其作用是持续的组织（或者强制）大家按照规则使用和贡献数据，并收集业务迭代需求。

很多企业由于缺少运营，导致中台逐渐走向不可用，最后新业务很可能绕过中台“自立门户”。最后导致花大成本的建设变成面子工程和领导演示工程。

这里面必不可少的几个运营过程：

1）元数据管理

我们常说元数据是数据的数据，也就是告知使用者和贡献者：中台有什么数据、能提供什么样式的服务、能接入什么数据等等。可以认为是开发者所说的“契约”。

元数据管理需要一个单独的系统来进行元数据采集和维护，并需及时体现数据的真实状态。就如同我们代码注释，代码变了，注释没变，是啥后果。

元数据的修改要形成版本。通过元数据的不同版本信息来进行数据的追溯，审计，变化情况的体现。

元数据从大类上一般包括数据元数据、服务元数据等。

这里主要说下数据元数据。

数据元数据可通过不同的“元-元数据”维度来进行定义，可分为两大类：技术性元数据和管理性元数据。也可按企业需求细分成不同的粒度。如下：

技术性元数据：

用来定义字段的语义，如：

字段中文名、英文名、类型、取值范围，关联的字典、数据来源，关联关系、归属资源目录、数据标签等。

管理性元数据：

用来定义后期管理（授权、问责等）所需的元数据：

如：权限类（密级、授权者、权限声明，作用域）、数据负责人、归属业务域，关联的数据标准、更新频率、数据的版本等。

2）权限验证

主要用在服务调用的拦截验证，或者服务调用前的授权验证。需提前在服务管理处进行授权登记。

3）质量管理

有两种方式进行数据的质量管理，一是强校验：数据只能通过统一且唯一的服务接口写入，在写入的时候进行校验，这对写入服务要求较高。二是弱校验：数据不一定通过唯一的入口写入，只是定期根据元数据校验规则去校验，并查找问题。

这一步需要定期生成质量审核报告，有问题追责，并改善。

4）安全管理

这里的安全主要考虑的是数据的涉密管理。除了服务授权，还要制定数据脱密规则，访问审批流程和办法等。

5）数据需求管理

用于管理数据使用者的数据使用需求。用户可以在服务中心采用“购物”的方式获取需要的数据，对于达不到需求的情况，在这提出需求，一般是一个申请单。

6）趋势分析

分析数据的健康状况，如：数据增量是否波动异常、服务访问趋势、热点数据等等。用于及时掌握数据变化情况，及时进行扩容和服务性能调整等。

7）数据可视化

这个你懂的，一般就是给领导演示和外界参观用的。整体体现中间建设的成果，用大数据看板，通过各种炫酷的图形化视图呈现，有一定的宣（xu）传成（gou）成分。

~完~

中台的建设要敢于打破组织边界，技术和业务并行，打好持久战，不忘安全。欢迎大家一起讨论！

感谢阅读。扫码或长按可关注。

公众号