中台论盛行之时，我曾看到过一篇介绍“大数据中台实践”的文章，结果用搜索引擎找到了一篇相似度高达百分之九十的多年前的“大数据平台实践”文章。这让人不禁猜测其实这篇“中台实践”文章，实际上就是将原来的“平台”用词替换为了“中台”，之后被再度发布出来。

到了去年，中台倡导者又宣布将“拆中台”。从“拆中台”的提出到现在差不多有大半年有余，行业对“中台”的争议更加明显，不同视角观点四起。现在很多企业都有给自己业务命名为“中台”，至于说真正的架构、设计、实施按照“中台”的模式去做还是只冠了一个名称却不得而知， 但是从目前的形势来看关于“中台”的讨论将会持续很久很久，并且中台也会在未来的发展中逐步渗透进传统行业的方方面面。

在这几年不同企业的实施、发展，中台的弊端也在逐渐凸显。

比如有业务方给中台提需求半个月却得不到回复，无奈只能自己上线，结果实施之后，中台来告状说重复造轮子浪费人力，埋怨这是信不过中台的表现。一些中小业务线想去做个创新也会遇到来自中台的各种阻碍，以中小业务线体量小不支持或不优先支持为由晾到一边。还有一些中小业务线赖以生存的、有价值的东西都被中台抢走了，但却没有被中台继续利用并发扬光大，反而让这些业务最后不了了之。

以前建立中台是为了集中炮火，结果这个炮弹全部落到自己的前台阵地上了。有些公司允许厮杀，前后台、中台与中台之间不是沉下心来去做职责内工作，而是在抢来抢去。所有新事物的发展必然有两面性，去芜存菁汰劣留良，更应该结合企业自己特色来实施。

花式的“数据中台”

中台的发展需要时间的验证，而数据中台的发展也随之起伏。数据中台随着中台的普及而更加普及， 但并没有遭遇“中台”的低谷，而是随着数字化转型得到了更好的推广，较之“中台”，企业普遍更为接受数据中台这个概念。倡导者提出“数据中台”这个词，但并没有其它更多具象化内容及落地实施的指引与帮助，反而这几年，其它行业企业、同行抛砖引玉在方法论、落地方案上增加了很多解释性概念、实例化的内容。很多业内人士对数据中台提出了很多的观点，解读很多，但基本都是对数据中台的广义与狭义的解读。

比如：

• “数据湖”是数据中台的底层或者是数据中台一定是构建在数据湖之上。
• 数据中台是解决是共享的问题。
• 数据中台就是一堆 API 的集合。
• 数据中台的能力成熟度模型。
• 数据中台的核心数据数据资产管理。
• 笔者记忆中还在某网站看到了一篇数据中台的发展史，尝试对数据中台做了一个分类，很多企业或者从业者也开始在外面讲数据中台的构建过程。
• ”数据中台“与”数据平台“之间的关系是什么，也是一直尝试划分一个比较明确的边界。
• 数据中台的建模方法是采用三范式、还是采用维度模型。
• 数字化转型数据中台是核心。
• 主要是 One data 的设计方法论。
• 数据中台的下一站是 AI 中台、算法中台等。
• 数据中台的组织架构是建设数据中台的第一步，数据中台组织一定是独立的部门，同时要避免与业务脱节，深入业务，要与业务目标绑定。
• 数据中台就是要解决业务口径不一致、计算逻辑不一致、数据来源不一致。
• 数据中台由于数据只能加工一次，强调数据的复用性，这就对数据的质量提出了更高的要求。

笔者调研过互联网企业、传统行业多家企业，其中部分互联网中的企业对“数据中台”这个词偏负面一点，一些中小型互联网企业、传统行业中大型企业对“数据中台”这个词还是比较感兴趣的。在 “数据中台”的实施中，不管是第三方实施或企业自建基本都是在通过自己理解的方法在实施。数据本身具备的天然特性就是一次采集、抽象公共总线并广泛使用、自身就带着共享与服务的特点恰恰又踩到了”中台”词的复用、服务的特点。

数据中台“在从牛市转为熊市的过程中，一篇文章《数据中台唱衰，企业数字化转型路在何方？（上、下）》写到数据中台项目失败谁之过，对其失败进行了较为深入细致的总结，也提到了“不忘初心、方得始终，回归数据中台的本质”，那么问题来了：数据中台的本质到底是什么？

“数据中台”真的"死了"吗？是"死了"， 死而不僵。

具体表现在：一些企业停止了大投入、高举高打的实施行为，团队从好几百人缩减到目前的十几号人；有的企业只剩下一个名字等待东山再起；还有一小部分企业仍在不声不响的继续努力着自身的建设与实施；甚至还有更奇葩的企业自己的数据中台部门内部还在构建更多小烟筒，比如数据中台内不同小团队都在做类似的报表工具、类似的统一数据查询接口、做类似的各种引擎等等。

当然也有一些数据中台不仅没有“死”而且实施得比较成功，这样的典型案例包括某服饰 K 项目、某母婴 M 项目。这两套案例总结实施也非常经典，做到了：管理层的指标监控驾驶舱、KPI 监控管理、传统的 BI 分析（报表分析、日常运营服务、当前业务链路的人货场以及电商化的分析）、店的人效、电商线上化的营销、精准、推荐，围绕上面应用场景的数据规范采集，打通日志、交易、售后等数据整合等。

这俩案例数据建设不管是用哪一种实施的方法论来落地，用到的技术、方法论都是 2009 ~2013 年左右的，其技术体系、架构是可以非常好的满足需求的。回归到本质，这个方向是否有过度包装、过度营销的嫌疑，除了本段提到的那些促成“数据中台”过度包装的原因外是否还有其它的因素呢？

“令人失望的原因还有哪些”

经历过一个疫情期，“数据中台”也像生了一场大病，变得无精打采。是什么原因导致的呢？作为一个实施者，在我看来，除了之前各种文章提到的数据中台实施的一些问题外，还有几个主要的行业性原因。

• “数据中台”概念是个篮子什么都往里装。

在还没有搞清楚数据中台是什么情况下，就开始按照自己的理解疯狂地往这个篮子塞各种概念，这种填鸭式导致的结果是把”数据中台“这个词撑到让更多人无法消化，尤其知乎、公众号中有大量的快消类内容文章对“数据中台”进行各种包装，不管含义、不管是否适用就直接往数据中台里面塞，但实施中就留下甲方乙方都难受至极的结果，或者是像是传出来的某某数据中台实施失败 (我总结过一些具体数据中台实施中问题案例，有机会再小范围分享)。

• 实施中遇到共性数据问题。

在很多文章、教材里会提到一些共性问题，比如说融合整个企业的全部数据、打通数据之间的隔阂屏蔽数据孤岛问题、数据标准与口径不一致的地方、统一数据规范的设计规范、解决数据口径不一致的问题、数据质量老大难的问题、元数据管理的问题、数据提供统一的出口与统一的入口问题。有很多类似的问题，不管是在十五年前、十年前、五年前、今天，数据中台、数据平台、数据仓库面临的问题基本上是一致的。有没有想过一个问题呢，十几年前的企业级数据仓库实施项目、数据平台建设项目、今天的数据中台实施，不管是在哪个阶段，很多实施中遇到的问题都是基本一致的。这么多年下来 DAMA 也一直在布道数据治理的方法论与认证等，但是遇到的问题还是一样的，多年反复出现而不能解决，虽然无趣，但还是得思考造成这些问题的核心要素是什么?

• 概念发展太快，信息量过载，不知道从何入手。

业内有这样一个现象，近年一些新入行的大数据从业者，看完市面好几本数据中台的书以及文章，感觉虽然似懂非懂却能谈得头头是道，但在落地时却表现得无从下手，或因实施中产生满天飞的各种问题最后被优化。2015 年以后从海量数据到大数据的变化特别迅速， 原有数据仓库、数据平台使用了 10 年、20 年积累下来各种知识体系，瞬间被互联网赋予新鲜的名词，后面的从业者面对这些变化新老内容一起的被动接受吸收、学习理解，却不容易吃透弄通。大数据这个领域本身专业术语非常多，进入到大数据领域的人会同时面对多个版本名词、含义、不同解释，理解起会变得较为困难，很多专有名词是需要机制上的理解与多次反复实践才能摸索出门道。不管在大数据领域工作多久接触到多少专有词汇，其核心是原有数据仓库、数据平台的内容基础上增加了很多介于互联网的特色或者新时代进步下赋予了新的含义，有的是扩充、有的是更加聚焦了。

• 讲“数据中台”的不知道怎么落地。

看过一些关于数据中台的培训视频、讲义，笔者对一些只强调大数据领域中概念却不指导如何具体实施的培训内容表示不敢苟同。希望在讲的时候带有一颗敬畏的心来做知识传播 。

近一年提倡数字化转型，有的企业可以一步到位数字化，有的企业则需要经历从信息化再到数据化的过程，企业自身业务现状、数据化现状处在不同阶段，遇到复杂的专业以及过度营销，或许前期感觉很高到上，中期地气不足，后期就难受。大数据这个领域有个特点就是专业词汇很多，让接触者感觉高大上的同时理解起来更加困难，但真实情况是数据中台、数据产品、Bi 分析这几年在各媒体、培训机构的充斥下认知的门槛变得很低，从认知到上手来做的门槛也变得很低。但是从能做变成做好，从做好变成架构与设计好，却不是一件能一蹴而就的事情。入门的门槛在逐渐的降低，但是天花板却变得更高，从而对从业者提出了更好的技术要求。

把行业上所有的数据中台 & 平台拿出来，百分之九十多项目都是介于失败或中间阶段，成功或评价好的没几个。当然这个也不能绝对说明什么，我也相信在业内有做的非常好的案例，可能是不愿意出来分享 。当然，对于评估数据项目优劣的评判标准，后面再做详细拆解。

在充斥着知识快消的当今时代，透传出一种行业的浮躁，每一个新的概念下必然会有一群失败的实践者，我们可以轻松的刺破浪尖上的泡沫但是挡不住任性的浮躁心理。

唯一性定理解析狭义的“数据中台”

再次引用本系列第一篇广义与狭义数据中台内容：

数据中台"这个词是从互联网大型企业的中台这个概念中提炼与逐步演进的，并逐步走进传统企业与大家的眼中。数据中台在数字化转型中承担的角色、职能以及投入产出还需要在实践中进一步去演进与变革。目前在行业上对数据中台的引用已经变的更好广泛，自然含义也有不同。既有广义、也有狭义。

广义上的数据中台就是一个什么都能装的篮子，除了原有数据平台内的技术框架、应用场景、其它的或许跟大数据一点边的场景、数据内容、框架都会往里装，以及站在更高的组织结构上去思考数据的全局化、统一化、一致化的设计与实施，强调复用性、共享式的服务。

狭义中的数据中台就是定义在一个大数据技术平台（存储、计算、开发工具、可视化、数据管理、大数据运维管理等），在原有的数据仓库以及升级后的数据平台的责任范围。

去年数据中台在行业内刚流行起来的时候自己遵循第一性原理，横向来看数据平台、狭义的数据中台的内在关系并进行合理性的比较。自己是从数据源的类型、计算与存储、数据内容的组织、数据资产管理、应用场景与价值来做横向的比较（严谨性还需要进一步整理）：

可能有人会提出，这里为什么没有提到组织结构的保障，数据中台不是说必须得有强力的组织上的保障吗？在后面文章会稍微展开解释，需要组织上保障的数据中台的前因后果。为什么数据中台提组织结构是感觉非常合理的，大数据天然的特性就是带着中台的一些概念关键词属性，比如共享、复用、平台化，数据本身其具备的天然特性就是一次采集、抽象公共总线并广泛使用、自身就带着共享与服务的特点恰恰又踩到了”中台”词的复用、服务的特点。

除了这个比较之外还有一个独特的地方，在数据模型上因为数据中台面对的业务线复杂度、数据使用者的复杂度均有所增加， 自然在数据模型中关于公共主题领域的设计会更加侧重一些，就是数据的复用性的问题。

如果要学习数据中台，必须了解从数据仓库到数据中台的发展历史，才能理清现在迎面扑来的各种专有名词及其含义，以及背后产生变化的原因。例如在一些非常成熟的数据平台因业务的需要是通过 API 或服务的方式为业务提供各种数据化场景（数据服务、总线、推送、订阅类常规的方式是受到业务对数据的场景化诉求驱动）。目前提到的指标统一、维度统一、编码统一、指标落地统一拆解构建统一在数据的企业级实施中数据总线设计的必须设计的，但今天受到事物、认知、复杂业务视角、组织环境、环境的发展的影响，在之前的基础概念上进行大胆的创新与变革。业内有套非常牛逼的 OneData 方法论，其包含的统一模型设计、统一 id、统一服务以及其他统一视角的建设。在后面一片文章也会尝试从自己的理解的角度来分享一下对这套方法论的建设观点与思考。

免责申明：

本文系转载，版权归原作者所有，如若侵权请联系我们进行删除！