1、为什么有的数据中台不能成功？
2、突然崛起的DataOps究竟是什么？
3、追求DataOps ， 为什么要回归第一性原理？
01为什么有的数据中台不能成功？数据中台成熟后 ， 会不会变成类似数据仓库和数据湖一样的数据基础架构 ， 可能是大多数人最为关心的问题 ， 但这对于数据中台的发展来说 ， 其实是一件好事 ， 原因在于它把问题收窄了 ， 回归到数据中台的产品本质上 ， 也就是基本面问题 。
和以往技术中间件不同的是 ， 虽然数据中台也承接底层数据和上层业务的中间层 ， 但它的价值更多地体现在与企业业务结合的能力矩阵维度 ， 而不是简单地做一些数据标准化和报表工具 。 所以这里就涉及到能用和好用的问题 ， 同时也是当下的主流问题：做一个能用的数据中台不难 ， 但要做到好用甚至说持续好用 ， 非常难 。
在滴普科技看来 ， “这和国内企业数字化的进程有关 ， 很多企业本身就有自己的一些信息系统 ， 大多数在数字化升级时 ， 都是基于现有基础改造 ， 而不是从0到1摸底建设 ， 这对于数据智能服务商挑战极高 。 ”背后的原因很简单 ， 一般来说 ， 传统信息系统往往建立在多个数据仓库之上 ， 而数据中台会使用数据湖来存储 ， 但根本问题是 ， 分割的数据层无法对核心业务流程进行全局还原和支持 ， 也无法实现数据驱动的全局决策和产品研发 。
前文提到的Twitter就是最好的例子 ， 在2011年以前 ， Twitter开发和发布产品的流程非常冗长 ， 产品经理需要到各个部门调研可以使用的数据 ， 并协调数据的生产化问题 。 在数据平台推行后 ， Twitter整个产品的开发和迭代流程从以月计改为以周计 ， 活跃用户数也从2011年不到1亿 ， 增长到2014年接近3亿 。 在当时Twitter大数据项目负责人看来 ， “这是架构上的胜利 。 ”
同理到现在的环境也是一样 ， 随着自助服务分析和机器学习的迅速发展 ， 公司里的管道数量也随着数据分析师、数据科学家、数据工程师以及数据使用者业务部门增多而增多 ， 问题的关键是 ， 几乎每一个都需要专门的数据集和数据访问权限才能产生内容 ， 而协调这些工具、技术和人员是一项巨大且耗费精力的工作 ， 特别是在规模庞大的开发团队里 ， 这也解释了为什么DataOps会发展起来 。
溯源企业数据平台项目的失败案例 ， 你会发现它们往往都有一些共性 ， 比如初期启动难 ， 得不到业务支持、很难把数据源规模化 ， 缺少对复杂源数据系统的管理手段、数据平台项目跟不上企业创新要求以及开发和运营成本极高 ， 无法正向反哺业务 。
以往的经验告诉我们 ， 很多时候 ， 一个高速发展的业务往往是因为早期架构设计的问题 ， 变得难以迭代 。 所以从这个角度看 ， 并不是数据平台的理念过时了 ， 而是数据中台的架构过时了 。 因为除了确定对于业务的价值外 ， 建设数据平台的根本性问题是技术架构的选择和设计 ， 但这相当于给一架高速行驶的列车更换引擎 ， 难度系数很高 。
02突然崛起的DataOps究竟是什么？前文我们提到 ， DataOps是硅谷公司在解决第三阶段问题时普遍采用的方法论 ， 同时也是数据中台建设必须参考的一个方法论 ， 这在一定程度上证明了DataOps的可行性 。 众所周知 ， 数据智能要解决的三大问题是数据处理、模型搭建及交付 ， 想要实现智能工程化或者大规模可持续的数据智能交付 ， 现在业内公认的模式运维解法是ModelOps ， 开发运维解法是DevOps ， 至于数据运维 ， 就是DataOps 。
【滴普科技：为什么说DataOps是数据中台的拐点？