要说最近企服圈什么最被关注，SaaS和数据中台想必是大多数人心里的答案。

前者商业模式已经被证明，Salesforce就是最好的例子，后者从刚出现时的火热，到被质疑跌落谷底只用了短短3、4年时间。这让很多人好奇，为什么在“数据价值已经被证明”和“企业数字化转型也成了多数CEO共识”的当下，大家对于数据中台的看法还会呈现两极分化，看好的人坚定认为数据中台是企业数字化转型的“解药”，看衰的人规劝同行不要上中台，它是鸡肋，是“毒药”。

归根结底，是因为业界对一个关键问题的看法还没有达成一致，即数据中台究竟是不是支撑企业数字化转型的最合理的数据基础架构？翻译一下就是，数据中台能不能满足企业数字化转型的最大公约数，或者说媒体老师们口中的最优解。

数据中台是一个“新物种”，但它的新仅仅停留在国内厂商的造词能力上，它诞生于国内，不懂技术的人容易被“中台”二字带偏，误以为它是一副万能药，在硅谷，其实也有一些知名独角兽公司有着和数据中台架构相类似的数据基础架构，但他们习惯把它叫作数据平台，而不是数据中台。

这里我们需要明确的是，所谓的“数据中台”，它只是一种叫法，就像“人工智能”一样，具体定义和内容往往需要根据要实现的目标和要解决的问题来确定。以Twitter为例，公司从2011年的300人，发展到2014年的4000人，大数据平台从80台服务器的单纯Hadoop集群，扩展到8000台服务器的核心数据处理平台，打从在很小规模时，Twitter就是一家数据驱动型的公司，而它管理的底层支撑，是一个全局共享的大数据平台。

图：Twitter大数据平台架构（来源：《云原生数据中台：架构、方法论与实践》）

这种平台型架构的好处是，Twitter在业务和组织快速扩张时，能做到统一数据规范、消除数据和应用孤岛。回到国内，多数企业在搭建数字化信息系统时，也就是在顶层设计的初期，并没有做到面向未来，所以一旦组织扩张速度过快，数据层面的浪费和组织层面的冗余也就随之而来，在这种情况下，企业往往盲目寄托于上数据中台，把包袱丢给数据智能服务提供商，但却忽略了自身的症结关键所在，所以难免越做越错。

一般来说，数据智能有3个发展阶段：大数据平台建设阶段、数据管理及应用阶段和数据能力中台化阶段。就目前来看，大部分企业的数据平台建设已经进行到一、二阶段，但要顺利过渡到第三阶段，就绕不开一个关键方法论的帮助——DataOps（数据运维），值得一提的是，它是很多硅谷公司在解决第三阶段问题时普遍采用的方法论。

DataOps由DevOps概念衍生而来，是基于元数据开发和部署数据分析应用的一种灵活敏捷的方法。“它让数据开发过程变得敏捷可控，这是眼下很多公司最头疼的事。对于大多数企业来说，数据在调整过程中容易缺少版本管理、缺少持续集成，甚至没有测试环节，整个过程都要靠人去做这件事情，他们就像是数据管道工，更别谈最终形成你想要的AI模型。”滴普科技FastData产品管理部总经理曾这样谈到，无独有偶，《数字化转型架构：方法论和云原生》一书中也明确提及，云原生应用平台的发展将经历DevOps—DataOps—AIOps的演进路径。为此，这篇文章我们将主要探讨：

1、为什么有的数据中台不能成功？

2、突然崛起的DataOps究竟是什么？

3、追求DataOps，为什么要回归第一性原理？

数据中台成熟后，会不会变成类似数据仓库和数据湖一样的数据基础架构，可能是大多数人最为关心的问题，但这对于数据中台的发展来说，其实是一件好事，原因在于它把问题收窄了，回归到数据中台的产品本质上，也就是基本面问题。

和以往技术中间件不同的是，虽然数据中台也承接底层数据和上层业务的中间层，但它的价值更多地体现在与企业业务结合的能力矩阵维度，而不是简单地做一些数据标准化和报表工具。所以这里就涉及到能用和好用的问题，同时也是当下的主流问题：做一个能用的数据中台不难，但要做到好用甚至说持续好用，非常难。

在滴普科技看来，“这和国内企业数字化的进程有关，很多企业本身就有自己的一些信息系统，大多数在数字化升级时，都是基于现有基础改造，而不是从0到1摸底建设，这对于数据智能服务商挑战极高。”背后的原因很简单，一般来说，传统信息系统往往建立在多个数据仓库之上，而数据中台会使用数据湖来存储，但根本问题是，分割的数据层无法对核心业务流程进行全局还原和支持，也无法实现数据驱动的全局决策和产品研发。

前文提到的Twitter就是最好的例子，在2011年以前，Twitter开发和发布产品的流程非常冗长，产品经理需要到各个部门调研可以使用的数据，并协调数据的生产化问题。在数据平台推行后，Twitter整个产品的开发和迭代流程从以月计改为以周计，活跃用户数也从2011年不到1亿，增长到2014年接近3亿。在当时Twitter大数据项目负责人看来，“这是架构上的胜利。”

同理到现在的环境也是一样，随着自助服务分析和机器学习的迅速发展，公司里的管道数量也随着数据分析师、数据科学家、数据工程师以及数据使用者业务部门增多而增多，问题的关键是，几乎每一个都需要专门的数据集和数据访问权限才能产生内容，而协调这些工具、技术和人员是一项巨大且耗费精力的工作，特别是在规模庞大的开发团队里，这也解释了为什么DataOps会发展起来。

溯源企业数据平台项目的失败案例，你会发现它们往往都有一些共性，比如初期启动难，得不到业务支持、很难把数据源规模化，缺少对复杂源数据系统的管理手段、数据平台项目跟不上企业创新要求以及开发和运营成本极高，无法正向反哺业务。

以往的经验告诉我们，很多时候，一个高速发展的业务往往是因为早期架构设计的问题，变得难以迭代。所以从这个角度看，并不是数据平台的理念过时了，而是数据中台的架构过时了。因为除了确定对于业务的价值外，建设数据平台的根本性问题是技术架构的选择和设计，但这相当于给一架高速行驶的列车更换引擎，难度系数很高。

前文我们提到，DataOps是硅谷公司在解决第三阶段问题时普遍采用的方法论，同时也是数据中台建设必须参考的一个方法论，这在一定程度上证明了DataOps的可行性。众所周知，数据智能要解决的三大问题是数据处理、模型搭建及交付，想要实现智能工程化或者大规模可持续的数据智能交付，现在业内公认的模式运维解法是ModelOps，开发运维解法是DevOps，至于数据运维，就是DataOps。

在2018年Gartner发布的《数据管理技术成熟度曲线》报告中，DataOps概念被首次提出。

维基百科对DataOps的定义是一种面向流程的自动化方法，由分析和数据团队使用，旨在提高数据分析的质量并缩短数据分析的周期，简而言之，就是提供一整套工具和方法论，让数据应用的开发和管理更加高效。但Gartner也指出，DataOps虽然可以降低数据分析的门槛，但并不会让数据分析变成一项简单的工作，与DevOps的落地一样，实施成功的数据项目也需要做大量的工作，比如深入了解数据和业务的关系、树立良好的数据使用规范等。

图：Gartner对DataOps的定位（来源：Gartner官方）

就像前文我们所提到的，DataOps的诞生并不是偶然，IBM商业价值研究院曾有过一份研究：数据科学家往往需要花费大量时间准备、验证和清理数据源，然后才能使用这些数据源训练数据模型，因此他们只能用少得可怜的一点点时间，去设计用于将数据转化为价值的AI模型。据估计，AI部署过程中有80%的工作都用于准备数据。

如果从第一性原理出发，你会发现DataOps与数据中台需要解决的问题其实是相类似的，它们都希望能更快、更好地实现数据价值，实现数字化运营，但两者侧重点却有所不同。

前者强调的是数据应用的开发和运维效率提升，类似于DevOps解放了开发人员的生产力，后者强调的是数据统一管理和避免重复造轮子，是对数据能力的抽象、共享以及复用。

上升到产品原教旨主义层面，如果说数据中台强调的是战略层次的布局，即必须有一个中台来承担所有数据能力的管理和使用，那么，DataOps强调的就是战术维度的优化，即如何让各个开发和使用实际数据应用的人员更加高效，换句话说，数据中台只是粗线条地描述了最终目标，而DataOps提供了一条更加精细化的最佳路径。

图：DataOps架构（来源：Diving into DataOps: The Underbelly of Modern Data Pipelines韦恩·埃克森）

当然，这和DataOps的架构有关。按照技术层面的解释，DataOps重点放在了数据中心，为用户提供了一系列数据工具，并通过人员协作与流程管控的模式，实现持续的数据科学模型部署，这可以通俗理解成“编排”，同时也是DataOps核心灵魂所在，因为一个好的编排工具意味着它能协调数据开发项目的4个组成部分，包括代码，数据，技术和基础架构。

因此，在云智能时代，DataOps是面向5G多云复杂部署数据处理的有效手段，也极有可能成为数据中台的发展拐点。

DataOps的优势显而易见，比如它能改善数据管理者和数据消费者角色之间的沟通，让双方处于同一页面上；整合整个企业的数据流，并通过数据管道自动化降低运营成本；通过良好的监控，保证可靠性和可观察性。

滴普科技方面认为，“拥有更强大的数据管理能力，是面向未来的架构关键特征。以当下主流的分析型数据库湖仓一体为例，想要完成湖仓一体的最终建设，则必然要经历以下三个阶段：数据入湖——数据治理和质量——DataOps。”

图：DataOps开发流程（来源：滴普科技官方）

但这并不意味着它是一副万能药。

就像前文所述，虽然DataOps可以降低数据分析的门槛，但不会让数据分析变成一项简单的工作。与DevOps相类似，DataOps的使用与发展，也是一个需要有正确工具和正确思维加持的持续过程，它的目标是用正确的方式实现数据智能项目落地，解放数据的功能属性，形成生产力。

在数字化浪潮里，企业数据平台要想成功落地，是双向选择和奔赴的过程，就像种一棵树，你不能头天种下了，第二天就希望它能变成木材，而是观察它的底部究竟在不在生长。

在2018年IBM和Forrester Consulting联合发布的报告《数字化转型的深层实质》中，数字化转型的任务由3个主要系统承担：SoE（System of Engagement，行动系统）、SoI（System of Insight，洞察系统）以及SoR（System of Record，记录系统）。SoR主要把系统需要的数据记录下来，SoI负责从数据中发现洞见，而SoE负责根据洞见来引导行动，虽然数字化转型的模型可能有多种表现方式，但你会发现，它的主要功能和建设内容还是绕不开这三个方面。

延续到客户视角来看，他们往往希望厂商能提供完整数据平台的搭建以及端到端的技术能力，并提供相关行业的知识和洞察，但这通常会牵涉很多赛道，从数据存储、数据处理、数据整合、到数据治理、人工智能、机器学习，再到最终的BI，而这些赛道的技术差异是很大的，所以对于数据智能服务玩家来说，需要用第一性原理思考问题：有所为，有所不为。