最近,朋友圈被"数据中台倒掉"的言论刷屏。有文章称《数据中台即将消亡,取而代之的是数智基建》,《Gartner分析:中国数智基建将取代传统数据中台》。这些观点引发了广泛讨论,但我认为其中不乏扯谈之处,这里给出我的思考和看法,大家耐心看完。
一、"数据中台消亡论"的由来
关于数据中台消亡的文章,多数引用了Gartner的一份报告。该报告是2023年发布的中国数据分析和人工智能技术成熟度报告。Gartner分析师在报告中将数据中台置于"泡沫破裂低谷期"。
主要观点包括:
1、技术问题:数据中台的传统架构和技术可能迅速过时。
2、效益问题:数据中台建设和维护成本高昂,但效益不够明显。
3、架构问题:数据中台的集中化难以应对不断变化的业务需求。
然而,也有反驳的声音。例如,彭总在《美国公司叨逼叨,中国公司自乱阵脚—论数据中台的“倒掉”》一文中提出:
1、数据中台已进入决策层视野,多个省市的"十四五"规划都提到了数据中台(比如调研中大家都提到了70%企业在建数据中台,其中一半属于跟风,但这个数字反倒佐证了数据中台在国内得到了很大发展)。
2、数据中台概念本身具有深远意义,可以衔接前台业务和后台技术,推动组织和架构优化(这让我想到了当年大数据刚出来的时候提到的蜜蜂模型:蜜蜂的效益主要不是自己酿的蜂蜜,而是传粉对农业的贡献)。
3、外国分析师对中国情况了解有限,连翻译都自相矛盾,咱们就没必要跟风,妄自菲薄了。
二、数据中台概念的演变
理性讨论数据中台,首先需要在定义上达成共识,否则争议就没有意义。让我们回顾一下数据中台概念的演变:
2015年 - 阿里巴巴的初步定义
最早提出"大中台,小前台"概念。数据中台是可复用、快速迭代、支撑多样化业务需求的通用技术组件。它提供标准化数据服务,实现数据共享和价值最大化。
2017年- 腾讯等对定义的拓展
将数据中台定义为一个整合企业数据资源的平台,通过标准化数据治理和服务,提升数据的共享与复用能力,数据中台还提供全链路的数据支持,覆盖数据采集、管理、分析和应用的各个环节。
类似的,百度将数据中台定义为一个集数据采集、存储、计算、分析为一体的平台,旨在帮助企业实现数据的统一管理和智能化应用。
可以看到,从这个时候开始,数据中台已经把数据仓库的内容也一起打包进来了,这个也好理解,毕竟要做数据变现,概念越大越好。
2019年- 华为对定义的数智化衍生
将数据中台的定义扩展至云计算、大数据和人工智能的结合,认为数据中台是企业数据的统一管理与应用平台,旨在打通数据孤岛,提升数据的共享和智能化分析能力。它通过结合云计算、大数据和人工智能技术,帮助企业实现数据驱动的业务决策和运营优化。数据中台还强调全流程的数据治理,推动企业的智能化转型。
2020年 - 专家学者的标准化定义
随着数据中台的广泛应用和实践,专家学者开始对其进行标准化定义。数据中台被定义为一个集中化的数据处理和服务平台,主要包括数据采集、存储、计算、分析、管理等功能模块。它为企业提供数据治理和数据能力的封装,帮助企业构建基于数据的业务创新和优化能力。
2021年 - 数据中台的行业应用深化
各行业逐步将数据中台应用于数字化转型的核心架构中,行业专家提出,数据中台的定义不仅仅是技术平台,更多是一种企业管理模式的变革工具。通过数据中台,企业可以将数据资源转化为生产力,优化决策流程,提升运营效率。
2022年 - 国家政策推动数据中台发展
国家在数字经济和数据治理方面的政策推动下,数据中台的概念进一步扩展到政府、公共事业等领域。此时的数据中台被定义为推动数字经济发展的核心引擎,帮助各行业实现数据资产化,提升数据价值。
从这个时间线可以看出,数据中台的概念随着时间推移不断扩展,已经远远超出了最初的定义范畴,现在更多体现的是一种数据驱动业务的生态体系,离阿里当初提出的概念,完全不是一个物种了。
三、辩证理解数据中台的概念
既然我们要对数据中台的概念达成共识,就要回归数据中台的初心,回归那个第一性原理,即它当初到底是为了解决什么特殊的问题而存在的,这个解决方案以前是没有的,或者存在改进的空间。
比如针对数据汇聚问题,数据仓库这种解决方案20年前就存在,后来发现数据汇聚不是简单的技术问题,又叠加了数据治理来保驾护航,但数据汇聚本身不应成为数据中台的内容。但我们当前关于数据中台的大多定义,都会把数据汇聚纳入了数据中台的范畴,但数据汇聚明显是后台的东西。
这种做法也不能理解,谁都希望搭顺风车,而且的确也带来了积极的影响,比如在概念上,数据要素融合融通得到了普遍认可,在商业上,数据仓库以数据中台的名义卖了不少。但生意归生意,我们不能把搭车的当成了真的数据中台,忘了那个中台的初心。
我个人比较认同阿里当初提出"大中台,小前台“时候的定义:数据中台是"一套可复用、可快速迭代、可支撑前台多样化业务需求的通用技术组件和能力"。它旨在提供标准化的数据服务,实现数据的共享和价值最大化。
我也比较认可史凯在《火热的数据中台对企业的价值是什么?》一文中对数据中台的进一步诠释,即数据中台一定是直接对接业务的,为业务而生,API是最主要的技术呈现方式,其中提到:
“数据仓库也好,传统的数据平台也好,其出发点应该说更是一个支撑性的技术系统,即一定要去考虑我有什么数据,然后我才能干什么,因此特别强调数据质量和元数据管理,而数据中台的第一出发点可不是数据,而是业务,一开始不用看你系统里面有什么数据,而是去解决你的业务问题需要什么样的数据服务?”
自己也曾经撰文多篇提到了自己对数据中台的理解,特别是《超越平台,数据中台的业务化、服务化及开放化!》、《数据中台是什么,不是什么,就这么拨乱反正吧 by 傅一平》这两篇文章。我也尝试给出过数据中台的一个定义,即“数据中台是支持多个前台业务且具备业务属性的共性数据能力体系” ,其包括了四方面的核心特征:
1、数据中台必须直接支撑前端业务,没有消费者调用的就不是中台,这意味着数据中台是先有业务再有数据服务。
2、数据中台提供的数据服务可以复用共享,可以以组件方式编排,往往以标准化产品形式出现,如API。
3、为了保障前面2个,需要建立与之配套的组织、制度、流程、平台等等,但不要泛化。
4、数据中台为业务而生,因此数据中台都是定制化的,凡是贩卖标准化数据中台的,大都是在卖数据仓库,数据湖或者其它,当然这些都有用,但不要鸠占鹊巢。
三、数据中台真的"倒掉"了吗?
如果我们对数据中台的本质无法达成共识,必然会导致巨大的争议,这种争议主要源于以下一些原因:
1、定义不同
Gartner认为数据中台要倒,但腾信、百度、华为不会认为数据中台要倒,因为他们宣传中的数据中台包括了企业的统一的数据基础设施,这个怎么可能消亡?也许大家都知道怎么回事,但不发声就会被流量带节奏。
2、错误认知
很多企业认为数据中台不给力,因为发现数据中台创造的业务价值不大,但其实别人给他建的不是真正的数据中台,而是传统的数据仓库和数据湖,这种技术驱动的平台不大可能达到数据中台的业务高度,数据中台被莫须有了。
3、能力不足
不少企业对数据中台很悲观,其实问题出在自己身上。因为数据中台要建好,不仅仅是技术问题,更是涉及到企业数据文化的建设、业务部门的充分参与、素质较高的数据团队的构建等等,而且还是个长期迭代的过程,但这些企业并不具备,总想快快快,有钱就要速胜。
4、时机未到
不少企业的规模不大,业务模式比较简单,听了几个数据中台的故事就开始想着一步到位,但其实这些企业当前阶段并不需要数据中台,应该老老实实的先把报表系统和数据仓库整明白了再说。
我发现,一个新技术只要出现了沉淀,编排这些高级词汇,大多意味着只有在规模足够大、业务复杂性足够高的企业中才能产生正向收益。但很多业务简单的企业还是会去用,认为用大炮打蚊子虽然有点浪费,但架不住先进啊,但他们其实连架设大炮的力气都没有。
5、跟风炒作
某大厂“中台倒掉”了,正好可以借力一波Gartner的曲线进行炒作,顺便推销下新概念,流量和热点都有了。
可以看到,很多关于数据中台的口诛笔伐实际搞错了对象,明明建的不是数据中台,却把失败归咎于数据中台。明明是自己的认知、能力和时机没到,建不出合格的数据中台,还是把失败归咎于数据中台。
Gartner认为调研到了真实情况,然后说数据中台要消亡了,这是结果成败论,他们可能对数据中台的理解出现了偏差,并且错误的选择了本不该入围的调研对象。
彭总更多是从宏观层面来理解数据中台,数据中台一定程度是数字化转型的象征,不希望这个国内提出的数据中台的概念由于一个老外的2023年的曲线引来如此大的唱衰舆论,进而影响大家数字化转型的信心。
现在,让我们回归阿里关于中台最初的定义,对我提出的那个数据中台的狭义定义能形成共识,那么,这个真正的数据中台是否也”倒掉“了呢?阿里作为数据中台的正主,不是在拆中台吗,难道这不是正在消亡的体现吗?
这里给出我的三个看法:
1、数据中台的核心理念不会消亡
它本质是围绕业务目标进行组件能力的沉淀共享复用,加速业务创新和响应能力,并创建一套机制来保证健康运营,这是大道。这一点与领域驱动设计(DDD)、微服务等理念一脉相承,但没人会说DDD、微服务会消亡。
2、数据中台的挫折归于一个“大”字
数据中台建设过程中受传统数据仓库、数据湖的影响太大(或者说是路径依赖),过于强调集中化运营,无论是平台、工具还是组织,这对数据源简单、业务不复杂、响应要求不太高的企业能够适用,但一旦企业规模和复杂度上去了,这种集中化的数据中台建设模式很容易造成单点的瓶颈。
当初阿里去参观Supercell 的时候,可能过于关注其共性能力抽象部分,而忽视了规模对最后效果的影响。
Supercell 是个小游戏公司,才200人,业务模式太单一,跟阿里天壤之别,数据中台到底是延续数据仓库集中化的模式,还是参考微服务的分布式模式,这个尺度边界在哪里,是需要研究的。
阿里的一刀切和强势文化可能造成了中台灵活性的困境。现在它的中台拆了,更多应该理解为迭代提升,而不是放弃。我们更多应该看到阿里在中台探索方面积极进步的一面,而不是去唱衰中台。
阿里的“拆中台”对所有尝试集中化运营数据中台的企业给出了提醒,在激烈的市场竞争环境下,你的数据中台真的能应对灵活性、敏捷性的挑战吗?你是鼓励领域主动有为,还是让领域成为一个纯粹的执行者?
3、数据中台会逐步向分布式演进
数据中台从来没定义过一定是集中化的,非集中化的数据中台跟微服务一样,也可以是中台式的存在,我认为数据中台的建设模式应该根据企业的大小和发展阶段确定,分布式的数据中台会提上日程。阿里拆了中台后,并不是万事大吉,因为分拆后的各个领域的数据中台需要考虑协同的问题,这是需要全局治理的,而全局治理的核心问题就是能否自动化,否则全局治理会导致僵化。
我一直有个观点,未来OLTP和OLAP是要融合的,但如何融合,一直缺少方案。数据网格给了我很大的启示,就是DDD领域驱动的设计不仅适用于操作型系统,也适用于分析型系统,离数据、业务最近的人,应该去建设领域数据中台。
未来的数据中台应该是领域自治的,同时通过一个自动化的治理平台进行统一政策和规则的拉通,这些政策和规则应该被代码化,就像服务网格一样。同时要实现数据分析基础设施的共享,各个领域团队不仅要去建功能,还要基于这些基础设施进行领域数据产品的快速打造。
在运营上,要确保数据中台中的每一个数据产品都应该有消费者,否则就不应该存在,这跟数据仓库完全不同,这才是既集中、也分散的理想化的面向业务的数据中台。
天下大势,合久必分,分久必合,这是规律,没有倒掉之说。但何时分,何时合,考验着每个企业的功力,在这方面,我们还有很多的工作要做。
为中台正名 | 数字化转型真谛是连接和开放,没中台和API还真不行
阿里宣布史上最大调整:加强敏捷,做薄中台,“大中台” 将何去何从?
点击左下角“阅读原文”查看更多精彩文章,公众号推送规则变了,如果您想及时收到推送,麻烦右下角点个在看或者把本号置顶!