数据中台本身还是围绕数据服务来进行的，未来的操作系统，一定会越来越个性化，甚至系统可以根据对应的终端用户自行呈现符合该用户习惯的系统界面——AI中台的概念应运而生。企业对数据的利用有三个阶段：响应运营，响应业务，创造业务。数据中台解决的是响应业务的问题数据中台对一个企业，起着至关重要的作用。在数据中台这个称谓成型之前，各个企业也都在用不同的方式来尽可能地利用数据产生价值。只是在这个过程中，也不得不处理着数据带来的各种问题，比如各个业务系统经年累月以烟囱架构形式存在而导致的数据孤岛、数据隔离、数据不一致等等。因为这些问题实在是过于繁杂，企业开始建立数据团队，或者数据部分开始继续数据整顿工作，因此数据仓库、数据湖、主数据治理等一系列的工作职能应运而生。
本质上，这些工作都是因为业务需要不得不进行的一系列数据治理的动作，对于如何利用数据来发力，并没有形成一个强有力的底座。
有点像“头痛医头、脚痛医脚”：各个业务系统规范不一致了，于是开展了元数据治理;数据分析的时候数据关联不上了，于是不得不进行主数据治理。
(资料图)
在这种模式下，频繁出现的字眼是：共享。那么，到底共享的是什么？答案便是数据的服务。
这样的数据治理工作在进行了很多年后，数据中台这个概念逐渐有人提出了，阿里的《企业IT转型直到：阿里巴巴中台战略思想与架构实践》这本书更是把用中台战略把这个概念推向了一个极致。中台战略中，人们常说：大中台，小前台。中台战略，并不是搭建一个数据平台，但是中台的大部分服务都是围绕数据而生，更加巧妙的地方是中台战略让数据在数据平台和业务系统之间形成了一个良性的闭环。于是，数据和业务系统融为了一体。
(图1 数据中台所解决的问题)
过去，数据依赖于手工进行，没有软件;有了数据中台，以功能驱动，固定的数据输入，得到固定的数据输出，构建出能用的服务变得更快速、更加的标准化，解决了业务侧的“能用”问题。但是，如何以固定的输入，以产生更灵活多变的输出，提供比如个性化的服务，做到“好用”，数据中台并没有给出答案。
在建立了数据中台架构之后，我们逐步认识到，原来数据的价值并不只是个运营出个参考的分析报表，做一系列的预算。数据中台为大型企业数据利用最大化提供了一个初始的参照方向。当我们发现，深度学习、机器学习等等一系列技术开始在这个平台下施展拳脚的时候，我们可能已经清晰地认识到：中台并不是数据分析利用的终点。
常见的主数据、元数据治理就是发生在这个阶段，只是数据仓库将主数据和元数据治理进行了规范化。
响应运营是数据分析最直接也是最原始的诉求。没有谁不不会关心自己的用户留存率，没有谁不关心自己的营收额;出现了故障、如何分析定位，如何预测预防，运用数据分析自然不过。但是在运营分析过程中，也发现了另外一系列的问题，比如各个业务系统的数据存储格式、存储介质都不相同，在进行基本的运营分析的时候，无法流畅的进行。此时，不得不进行一系列的数据治理。
第二阶段：响应业务
数据分析停留在运营阶段的时候，对企业来讲最大的感受就是投入产出比不对称。这个问题在大数据爆发的时间点上，更为凸显。例如在今天的业务场景下，传统的数据仓库已经解决不了海量数据、异构数据等一系列问题，而大行其道的大数据分析技术，硬件要求高、学习门槛高。要实施一个大数据平台，成立一个大数据团队，这是一个不小的成本开销，更何况现在有不少数据分析团队要借助机器学习等手段，来对数据做分析来响应运营，这导致基础设施成本、整体门槛进一步提高。
于是像数据中台这样的思想就被提了出来：既然数据是从业务系统产生的，那么是否业务系统也需要数据分析结果呢?对于数据平台来说，数据平台本身提供两大能力：数据存储和数据计算的能力。那么业务系统的数据存储和数据计算能力是否可以剥离到数据平台，仅仅让业务系统很轻量的维护自己的业务流程操作?所以利用中台剥离了复杂的业务环境，再配合微服务等技术，一下子让人感受到了“数据服务的共享”。
而对业务场景来说，很多时候是需要数据服务的，例如用户的基本信息管理、用户的行为数据分析，这些数据不但可以暴露给业务系统使用，甚至可以直接丢给终端用户自行使用。
类似这种契合点，让数据平台变成了一个服务，提供给业务系统。
第三阶段：创造业务
业务不会总停滞不前，因为人的生活会改变，想要的体验会改变。过去，大家到视频平台看视频，利用通用的数据服务，不同的用户看到的视频推荐都是一样的;很快，我们就会发现根据用户的偏好，推荐个性化的视频几乎是必不可少的体验要求。然后，我们就开始思考：数据是否可以变成个性化服务提供给终端用户?这是一个非常简单、常见的例子。当这样的个性化数据服务越来越多之后，各种服务不断组合，就会创造出很多可能性，进而提供创新的个性化体验和新的业务模式，这就是数据服务用于创造业务的阶段。
虽然有了数据中台，但是当有大规模的、基于智能算法的数据服务需要落地实现时，依然会碰到以下挑战。
当智能服务成千上万的时候，如何管理、如何构建、如何高效维护，就会成为很大的麻烦。
如何对规模化的智能服务进行管理：当只是零星三两个智能服务的时候，通过手动人工管理等方式，不会有太大的问题;然则，
没有良好的工程实践来保证质量和流畅性：对于常规的应用软件开发我们有TDD、自动化测试、CI/CD等成熟的工程实践做保障;但是在智能服务这一块，无论是编程开发、还是服务构建，都没有成熟的工程实践，也没有良好的基础设施支撑，非常依赖于构建这个服务的数据工程师的个人能力，导致在实施过程中，问题难以复现，难于定位。
数据安全、治理和数据量不充分：数据中台的价值点，在于提供了数据的计算和存储的能力，但是在智能服务构建下，光有计算和存储还不够。治理到什么程度的数据，才能较好的支撑服务的构建?个性化的服务与数据安全冲突的时候，如何抉择?数据量不足导致算法模型泛化能力太差，怎么办?
(图3 创造业务阶段，数据中台面临的挑战)
从数据中台到AI中台
什么是AI中台？
对于这样的场景和服务，我们需要怎样的平台？整个软件开发架构和流程是否也都会相应重造？
数据中台本身还是围绕数据服务来进行的，而非围绕智能服务来进行的。未来的操作系统，一定会越来越个性化，甚至每一个人看到的登录界面都不一样，系统可以根据对应的终端用户自行呈现符合该用户习惯的系统界面。那么
回到创造业务的需求。以简单的销售业务为例，数据中台提供的服务本质如下图所示：
(图4 软件平台的业务模式)
这是目前最常见的软件平台的运作方式，开发人员开发出了对应的软件服务后，提供给终端用户使用，虽然会有销售售卖该服务。这种方式，好比是拿着一个锤子找钉子，而不是给钉子快速制作一把合适的锤子再去售卖。
能不能这样：将整个软件组装出来的服务，包装成个性化的产品一样去售卖，提供量身定做的服务?那么整个运营模式就变成：平台提供了一种快速构建智能服务的过程，服务售卖者利用这个平台，自己动手构建出服务，拿出去售卖，类似一个提供“智能业务服务的PaaS”。
(图5 引入AI中台的软件平台业务模式)
如果尝试给AI中台下个定义：
AI中台是一个用来构建大规模智能服务的基础设施，对企业需要的算法模型提供了分步构建和全生命周期管理的服务，让企业可以将自己的业务不断下沉为一个个算法模型，以达到复用、组合创新、规模化构建智能服务的目的。
借助一个平台，将软件的服务个性化的创造，这将是未来的发展趋势。在麦肯锡的分析报告中，我们可以看到，各个企业或者行业，都在第三个阶段做了不同的探索和努力。
首先，从基础设施角度，可以将数据中台智能化
所谓的智能化，是指将在数据中台进行的一系列的数据服务构建操作进行智能化实现，让数据的接入、存储、分析展现、训练、到构建管道(pipeline)都更加自动化。例如，对于通用的CI/CD来说，测试不过则会构建失败，那对于AI中台下，就要考虑一个推荐模型构建失败的条件是什么?答案可能是“本次模型的准确率低于上一次构建的准确率”的时候，CI应该被构建失败。在实践中，这可能是CI构建过程的维度之一，还会有很多其他指标和维度。我们就需要在现有的数据平台的CI中，实现并自动化这些指标和维度，使之更加智能化。
