你、我、他的中台 | 从数据中台到AI中台

本文先讲什么是数据中台、然后讲理想的数据中台的架构、再讲驾驭数据中台要懂的技术、并结合思维新地图判断数据中台会是下一个风口吗，最后讲从数据中台到AI中台是一种自然生长。

拿着旧地图是不可能找到新大陆的！

马云老师早些年在香港青年创业营上有公开说过DT，阿里巴巴也是较早构建数据中台的企业。但是马老师没说数据中台背后的目的和数据背后的力量。

本文笔者先讲什么是数据中台、然后讲理想的数据中台的架构、再讲驾驭数据中台要懂的技术、并结合思维新地图判断数据中台会是下一个风口吗？最后讲从数据中台到AI中台是一种自然生长。

一、什么是数据中台？

1. 中台概念的来源

美军在二战时，以军来为单位作战；到了越战时，以营为单位作战；到了中东战斗的时候，以7人或者11人的极小班排去作战，这是今天最灵活的军事组织，也是核心竞争力和打击能力最强的一个组织。而美军之所以能灵活作战，敢放这么小的团队到前方，是因为有非常强的导弹指挥系统，有非常强大的中台能力，能支持这样的小团队快速做判断，并且引领整个打击。

2. 商业中台的演化

随着阿里巴巴、华为的业务发展，平台业务线越来越多，例如：据笔者此前的一份调研，阿里巴巴旗下某中等BU（事业群），一年生产出来117款产品，顺利年终上线的有10几款，有社会知名度的有几款，被集团老板马老师记住的整个部门没有一款。

分析产生这种问题的原因是，100多条产品线实际领到的任务均是为了大BU淘系服务，且针对淘系广告相关的服务，例如围绕直通车、钻展等服务的产品，并没有调动研发创造产品的团队积极性。

所以阿里由美式中台演化到阿里组织中台，然后根据产品是长出来的而不是规划出来的随着阿里各个业务线数据的增长又由组织中台演化到数据中台，当然数据中台也不是阿里的最终目标。

3. 数据中台的广义定义

数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。 数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。

这些服务跟企业的业务有较强的关联性，是这个企业独有的且能复用的，它是企业业务和数据的沉淀，其不仅能降低重复建设、减少烟囱式协作的成本，上面的阿里巴巴100多个同系列产品同时服务一个淘系就属于烟囱式。

广义的数据中台包括了数据技术，比如对海量数据进行采集、计算、存储、加工的一系列技术集合，时下我们谈到的数据中台包括数据模型，算法服务，数据产品，数据管理等等 ，和企业的业务有较强的关联性，是企业独有的且能复用的，比如企业自建的2000个基础模型，300个融合模型，5万个标签。

数据中台广义上是企业业务和数据的沉淀，其不仅能降低重复建设，减少烟囱式协作的成本，也是差异化竞争优势所在。

二、理想的数据中台架构

我们都知道远洋运输中， 不论什么合法货物都能装进集装箱里，集装箱就是很好的架构，类似理想的数据中台架构如下图：

通过以上架构图，可以看出，数据中台模式有以下一些特点：

• 首先是对全域数据的吸收与存储，实现对企业中各业务类别数据的整合和集中化管理。
• 其次是按照规范化的数据架构（数据仓库规划、数据模型构建、指标定义规范等）统一研发数据，实现数据口径、数据模型标准化。
• 再次是建立业务需求驱动的几大数据体系，深度萃取数据价值。
• 最后是集成数据资产管理能力，从数据的运营、应用、管理、分析、可视化五方面统一管理数据资产。

三、数据中台需要懂的技术

1. 技术切入点是从构建数据仓库+各种数据平台的技术入手

数据仓库的构建如下图：

上图可见，最左侧数据源这点很好理解，但是很难办理实现。因为数据有个特点是每家的数据有每家的业务特征，但是这些特征难以团聚，即数据孤岛！

• ETL： ETL分别代表：抽取extraction、转换transformation、加载load。抽取（Extract）是从数据来源提取指定数据，数据是需要指定的。转换（Transform）是将数据转换为指定格式并进行数据清洗保证数据质量。加载（Load）是将转换过后的数据加载到目标数据仓库。
• DM： 数据集市可以理解为是一种“小型数据仓库”，一般面向部门、单个主题或特定应用，且之间互不影响。
• ODS： 全称是Operational Data Store，操作数据存储。存储各大业务型数据库ETL后的数据，是最接近数据源中数据的一层，主要目的是为了数据集中。总体上大多是按照源业务系统的分类方式而分类的，因此会具有鲜明的业务数据库的特征，甚至还具有一定的关系数据库中的数据范式的组织形式。但是不等同于原始数据，数据格式按照数仓要求统一，并经过简单的清洗。

2. 技术实操点

（1）实操数据存储

起源数据治理平台管理的数据存储范围包括：数据仓库中的Topic层和数据应用层，存储方式包括：Hive、MySQL、Kylin、Palo、ES、Druid。

如下图所示：

上图所示的这些数据存储中的数据的加工过程，由数据开发工程师负责，具体采用哪种存储介质，由数据开发工程师综合所需数据存储空间、查询效率、模型的组织形式等因素决定。但后续的使用维护都由起源数据治理平台管理，管理方式是通过管理这些数据表的元数据信息和查询实现。

数据存储托管之后，数据表元数据信息变更监控、表数据生产（存储空间、生产状态及完成时间）监控、表数据波动（同环比等）监控以及表的使用（模型的构建及查询效率等）监控及评估，都由起源数据治理平台自动完成，所有信息的变动都会自动周知对应的负责人，保证数据应用的安全和稳定。

（2）实操元数据管理

元数据信息宏观上包括两大部分：业务元数据信息和数据元数据信息。

• 其中业务元数据信息包括：指标业务定义、维度的业务定义等；
• 数据元数据信息包括：数据表元数据信息、模型元数据信息、维表与维度的绑定关系、数据模型字段与指标的绑定关系。

起源平台为了实现元数据信息的管理，设计了四个模块实现，分别是：数据表管理模块、模型管理模块、指标管理模块、维度管理模块。元数据管理是起源数据治理平台的核心，起源平台就是通过控制好元数据，来驱动数据的生产和消费。

（3）实操数据表管理模块

数据表管理模块管理了数据库信息和数据表信息，其中数据库信息包括数据库链接信息，数据库信息维护后，起源数据治理平台自动获取对应库中表的元数据信息。

数据表信息包括：表的元数据信息（引擎、字段等）、表类型（维表或事实表）、表的使用情况（是否被模型使用）、表对应的ETL、表的负责人、表的推荐度、描述信息、表的监控配置及报警历史、以及样例数据等。上述这些信息为业务用户提供指导，为模型管理提供数据支持，为数据表和数据的稳定提供监控和预警。

（4）实操维度管理模块

维度管理模块包括基础信息和技术信息，对应着不同人员维护。其中基础信息对应维度的业务信息，由业务管理人员维护，包括维度名称、业务定义、业务分类。技术信息对应维度的数据信息，由数据开发工程师维护，包括是否有维表（是枚举维度还是有独立的维表）、是否是日期维、对应code英文名称和中文名称、对应name英文名称和中文名称。

如果维度有维表，则需要和对应的维度表绑定，设置code和name对应的字段；如果维度是枚举维，则需要填写对应的code和name。维度的统一管理，有利于以后数据表的标准化，也方便用户的查看。

（5）指标管理模块

指标管理模块核心包括基础信息和技术信息管理，衍生信息包括关联指标、关联应用管理。基础信息对应的就是指标的业务信息，由业务人员填写，主要包括指标名称、业务分类、统计频率、精度、单位、指标类型、指标定义、计算逻辑、分析方法、影响因素、分析维度等信息；基础信息中还有一个比较重要的部分是监控配置，主要是配置指标的有效波动范围区间、同环比波动区间等，监控指标数据的正常运行。

技术信息构成比较复杂，包括数据类型、指标代码，但是核心部分是指标与模型的绑定关系，通过使用演进形成了当前系统两类绑定关系：绑定物理模型和构建虚拟模型。

• 绑定物理模型是指标与模型管理中的物理模型字段绑定，并配置对应的计算公式，或还包含一些额外的高级配置，如二次计算、模型过滤条件等；
• 创建虚拟模型是通过已有指标和其对应的物理模型，具体步骤首先配置已有指标的计算方式或指标维度的过滤，然后选择指标已绑定的物理模型，形成一个虚拟模型，虚拟模型的分析维度就是所选指标基础模型的公共维度。

从以上实操来看，产品、运营、技术、业务人员是相互配合完成数据中台的实操，当然了在这里如果某一个岗位人员的技能和经验丰富一些，不排除以人身兼多职的可能。更多相关实操知识点可以参考笔者的书籍《AI赋能：AI重新定义产品经理》。

四、数据中台会成为下一个风口吗？

数据中台会不会成为下一个风口，首先笔者本人不赞成风口轮，更支持一个事物长期的价格是由其本质的价值决定的观点。其次目前的数据中台从产品上看是融合了各种数据源，经过ETL技术处理供给给有限的纯商业变现目的。再则数据中台的各个技术模块日趋成熟，稀缺的是数据的吸取和数据的资产变现模式。

所以，一方面看数据中台是刚刚兴起，这股兴起即使是技术团队也是兴起不久，例如：笔者早些时候在一所名校的CS技术群里讨论过数据中台，然后再过一段时间是产品开始讨论，然后就会是运营讨论，随后市场销售也会跟上。

下图为笔者早期在技术群里讨论数据中台技术图：

数据中台的技术有原来的，也有创新的，但是整体比较成熟，剩下的是在业务切入方式上，例如：架构齐全，但是数据值缺失、数据孤岛等等情况才是现实问题。不论数据中台是不是下一个风口，数据中台的产品都将运行下去，尤其是数据中台的思维理念是：“数据共享”。这样美好的理念值得人人都需要一个数据中台。

五、数据中台与AI中台

AI 中台是一个用来构建大规模智能服务的基础设施，对企业需要的算法模型提供了分步构建和全生命周期管理的服务，让企业可以将自己的业务不断下沉为一个个算法模型，以达到复用、组合创新、规模化构建智能服务的目的。

从数据中台演进到 AI 中台！

从 AI 中台落地实施的方式来看，AI 中台可以是数据中台的进一步延伸，从数据中台一步一步演进过去。

首先，从基础设施角度，可以将数据中台智能化所谓的智能化，是指将在数据中台进行的一系列的数据服务构建操作进行智能化实现，让数据的接入、存储、分析展现、训练、到构建管道（pipeline）都更加自动化。

例如：对于通用的 CI/CD 来说，测试不过则会构建失败，那对于 AI 中台下，就要考虑一个推荐模型构建失败的条件是什么？

答案可能是“本次模型的准确率低于上一次构建的准确率”的时候，CI 应该被构建失败。

在实践中，这可能是 CI 构建过程的维度之一，还会有很多其他指标和维度。我们就需要在现有的数据平台的 CI 中，实现并自动化这些指标和维度，使之更加智能化。更多AI应用案例可见笔者新书《AI赋能：AI重新定义产品经理》。

其次，对于我们可想而知数据中台使从来不是目的，数据中台的目的是将数据变成数字资产。这种资产如果仅仅用来租赁，肯定不如智能的应用价值更高，这也是从数据中台到AI中台的第二点原因。

第三、目前的数据中台的终端应用以直接2C以产生刚性的订单为主。而我们并不确定这个推荐是否由数据中台的引擎发挥了人性的作用，而智能应用层直接面向终端，怎么利用元数据等功能，组合各自不同模型提供的服务，构建出组合效应的创新服务才能更懂用户的人性。

总结

不论数据中台会不会是下一个风口！不论业务、运营、技术和产品，如何讨论的中台多么热门，也不用管多少大佬提及过。你只需要懂中台中该掌握的思维、技术、实操。然后明白我们开头的那句话：拿着旧地图是不可能找到新大陆的！你就能做出智能中台。

下次继续分享智能中台实操案例。

#专栏作家

连诗路，公众号：LineLian。人人都是产品经理专栏作家，《产品进化论：AI+时代产品经理的思维方法》一书作者，前阿里产品专家，希望与创业者多多交流。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: