数据中台演进之AI中台

数据中台

数据中台对一个企业，起着至关重要的作用，在数据中台这个称谓成型之前，各个企业分别都在用不同的方式来尽可能的利用数据产生的价值，同时也处理着数据带来的问题。例如各个业务系统以烟囱架构形式存在，长期以往导致数据孤岛，数据隔离，数据一致性等一系列的问题，那么当我们需要充分利用数据的时候，就不得不去考虑怎么解决这些问题。于是各个企业分别形成数据团队或者数据部分开始继续数据整顿工作，数据仓库，数据湖，主数据治理等一系列的工作应运而生。

本质上，这些工作都是因为业务需要不得不进行的一系列数据治理的动作，对于如何利用数据来发力，并没有形成一个强有力的底座。有点像头痛医头，脚痛医脚，各个业务系统规范不一致了，于是开展了元数据治理，数据分析的时候数据关联不上了，于是不得不进行主数据治理。

在进行了很多年的数据工作之后，数据中台这个概念逐渐有人提出了，可能阿里的《企业IT转型之道：阿里巴巴中台战略思想与架构实践》这本书，把这个概念推向了一个高度，似乎定下了一个参考答案。中台战略我们常说：大中台，小前台，在这种模式下非常频繁出现的字眼是：共享。那么共享到底共享的是什么？共享的便是数据的服务。中台战略并不是搭建一个数据平台，但是中台的大部分服务都是围绕数据而生，更加巧妙的地方是中台战略让数据在数据平台和业务系统之间形成了一个良性的闭环。于是，数据和业务系统融为了一体。

上图是一个浓缩的描述，可以看到，数据中台在业务侧解决的还是能用的问题，只是有了数据中台后，我们构建出能用的服务变得更快速，更加的标准化，但是在好用方面，数据中台相对乏力。

因此在中台架构之后我们逐步认识到，原来数据的价值并不只是个运营出个参考的分析报表，做一系列的预算。数据中台为大型企业数据利用最大化提供了一个参考的案例。常说的深度学习，机器学习等等一系列技术在这个平台上似乎找到了一个发力点，开始在这里施展拳脚。

但是，中台并不是数据分析利用的终点，仔细看数据分析的历程，可以归纳发现数据利用大概有如下三个阶段：

第一阶段：响应运营

响应运营是数据分析最直接也是最原始的需求，没有谁会不关心自己的用户留存率，没有谁会不关心自己的营收额。同时对于出现故障，预测分析，同样也是非常重要的事情。但是在运营分析过程中，发现一系列的问题，例如各个业务系统的数据存储格式，存储介质都不相同，那么在进行基本的运营分析的时候则无法流畅的进行，不得不进行一系列的数据治理。常见的主数据，元数据就是发生在这个阶段，只是数据仓库将主数据和元数据治理进行了规范化。

第二阶段：响应业务

数据分析停留在运营阶段的时候，对企业来讲最大的感受就是投入产出比不对称，这个问题在大数据爆发的时间点更为凸显。例如在今天的业务场景下，传统的数据仓库已经解决不了海量数据，异构数据等一系列问题，而大行其道的大数据分析技术，门槛高，硬件需求高。要实施一个大数据平台，成立一个大数据团队，并不是一个小成本的开销，更何况现在有不少数据分析团队会通过机器学习等手段去对数据做分析来响应运营，这就加剧了成本和门槛的进一步提高。

于是像数据中台这样的思想就被提了出来，既然数据是从业务系统产生的，那么是否业务系统也需要数据分析结果呢？对于数据平台来说，数据平台本身提供两大能力：数据存储和数据计算的能力。那么业务系统的数据存储和数据计算能力是否可以剥离到数据平台，仅仅让业务系统很轻量的维护自己的业务流程操作？所以中台剥离的复杂的业务环境，再配合微服务等技术，一下子让人感受一个词：共享。

而对业务场景来说，很多时候是需要数据的服务的，例如用户的基本信息管理，用户的行为数据分析，这些数据不但可以暴露给业务系统使用，甚至可以直接丢给终端用户自行使用，而这种契合点，让数据平台变成了一个服务，提供给业务系统，而对终端用户来说，自己消费自己数据的同时也在继续产生数据，这样数据就形成了闭环。

第三阶段：创造业务

业务不会总停滞不前，因为人的生活会改变，想要的体验会改变，所以业务系统的功能会跟着改变，当我们发现数据可以逐步变成通用服务提供给业务系统的时候，就会思考，数据是否可以变成个性化服务提供给终端用户？例如不一样的得到不一样的推荐？这是一个非常简单的例子。但是当越来越多这样的服务之后，组合创造的可能性会变高，组合带来的个性化体验会更好，这就是数据服务的创造业务的阶段。

数据中台之AI中台

数据中台解决的是第二阶段的问题，对第三阶段对问题并没有特别好的支撑，因为数据中台本身还是围绕数据服务来进行的，而非围绕智能服务来进行的。举个例子，从未来来讲，系统一定会越来越个性化，甚至每一个人看到的登陆界面都不一样，系统可以根据对应的终端用户自行生产出符合该用户习惯的系统界面。那么对于这样的场景和服务产生，我们需要怎样的平台来诞生，我们的整个软件开发架构和流程是否都会重造？

从CI/CD的角度来讲，我们的CI/CD保障了我们的软件输出按照既有的设定测试结果方向靠齐，那么在个性化服务下，我们应该构建怎样的pipeline来管理和发布这些模型？这和工业4.0提出的智能制造非常类似，早期我们通过流水线的形式让各种不一样的业务，不一样的软件通过一种统一的流水线的方式运作，但是在智能制造的前提下我们期望为每一个不一样的终端用户提供不一样的服务，那么统一的流水线是否依旧适用？

AI中台便是数据中台的进一步延伸，也是为了解决上面的问题，让数据利用达到第三个阶段：创造业务。既然有创造业务就有售卖业务，如下图所示：

可以看到，上图是目前最常见的软件平台的运作方式，开发人员开发出了对应的软件服务后，提供给终端用户使用，虽然会有销售售卖该服务，但是更多的是拿着一个锤子找钉子，而不是给钉子快速制作一把合适的锤子再去售卖。

AI中台尝试提供一种能力，来达到这样一个效果：

将整个软件组装出来的服务，如同个性化的产品一样去售卖，这样的服务就是量身定做的，非你莫属的。那么整个运营模式就变成了，AI平台提供了一种快速构建智能服务的过程，服务售卖者将自己动手做出来的服务拿出去售卖，这个和paas平台非常相似，但是paas提供的是一个业务无关性的售卖机制。借助一个平台，将软件的服务个性化的创造，这可能是未来的发展趋势。

通过下图可以看到，各个企业或者行业，都在第三个阶段做了不同的探索和努力：

但是又各自遇到不同的问题，总结起来发现在落地过程中，通常存在以下问题或者挑战：

从数据中台的演进

AI中台不是一蹴而就的，也许达到最终的效果有非常长的路要走，但是我们可以考虑逐步的演进过去，首先的步骤就是可以将数据中台智能化，所谓的智能化是指将在数据中台进行的一系列的数据服务构建操作，更加的智能化，从数据的接入，存储，分析展现，训练，到pipeline都更加智能化。例如对于通用的CI/CD来说，test不过则会构建失败，那么决定一个推荐模型构建失败的条件是什么？显然现有的CI/CD并不能很好的为此服务。

其次，对于中台使用者来说，目前基于数据中台的一个智能服务模型开发来说，流程如下：

基本类似于一个横向的烟囱架构，带来的问题比较明显，因为黑盒的原因导致目前对一个模型的工作进行拆分的时候，都不是特别的顺畅，当然因为目前大部分业务场景依旧以流程为主，没有太多的智能服务，所以一系列的问题并没有明显的被暴露出来：

• 借助于现有数据平台手工进行数据操作
• 烟囱架构开发，对人员能力要求高
• 环节无法有效拆分，响应周期慢
• 智能场景规模化，管理复杂
• 训练，部署，发布依赖于手工部署缺乏有效的流水线
• 和数据平台孤立，缺乏统一的数据服务接口
• 基础设施隔离，无法动态进行资源的分配和管理

从一个好的体系来讲，AI中台是借助数据中台的能力，但是具备构建智能服务的能力，AI中台尝试解决如下的问题：

• 和数据平台结合，利用数据平台的能力作为数据支撑，最大化的发挥数据平台的价值
• 拆分服务构建环节，智能服务开发流程化，快速响应业务需求
• 利用元数据管理方式，提供统一的标准格式，场景可以多人协同配合开发
• 基础设施共享化，模型的训练和发布与数据平台有效绑定，服务的构建自动化
• 统一的元数据管理系统，模型的全生命周期可管理
• 通用AI能力平台化，降低人员要求，提升协作效率

所以就要求我们对服务构建的过程进行如下拆分：

首先需要从基础设施层面进行集成，常规的数据中台依赖于大量的CPU和内存，而相反，机器学习模型对GPU的依赖反而更高，但是又不能脱离数据中台，因为它依旧需要利用数据中台的存储和计算能力来处理大量的数据，所以如何通过一个接口，一个调度器，一个pipeline来集成整个工作流，就成了需要考量的事情了。

从整个大的来讲，AI中台至少应该分为一下几个层级：

在数据中台的基础上扩展对GPU级别资源的管理和整合能力，调度层提供统一的任务，服务，智能CI/CD等服务，对AI平台来讲，提供的能力聚焦在：利用算法，模型，框架如何动态和快速的组装和产生出能支持创新的服务上。

结尾

AI中台是数据中台在业务上的演进，是系统服务的重组的过程，因素还是那些因素，就像工业4.0里面的螺丝钉还是那些螺丝钉，但是每个螺丝钉都被打上了个性化的标签。不过，被打了标签的钉子，还是原来的钉子吗？这是个问题，但是在落地实施过程中，我能够发现，虽然以AI中台进行落地实施，但是实际的这个过程，却是“持续智能”的一种体现，关于“持续智能”，则是在AI落地的核心思想，后续再做重点分享。

文/ThoughtWorks白发川

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见