现代数据栈：秽土重生？——从 SAP x Databricks 看数据世界的轮回

由 SAP 官宣与 Databricks 合作想开去。

现代数据栈（Modern Data Stack）曾一度是数据行业最炙手可热的概念。 Snowflake、Databricks、Fivetran、dbt……一众明星公司描绘出一个美好的未来：所有数据汇集到云端数据仓库，所有分析、BI 和 AI 应用直接连接仓库数据，再无数据孤岛，数据流转自由，一切井然有序。

但现实并没有这么美好。现代数据栈经历了一轮狂热，又在短短几年间迅速“陨落”。 各种数据工具层层叠叠，带来了更复杂的集成、更高昂的成本，甚至让数据孤岛问题变得更加严重。最终，在 AI 浪潮的冲击下，曾经喧嚣一时的“现代数据栈”变得无声无息。

然而，一切似乎正隐隐露出回归的迹象。SAP 最近宣布与 Databricks 合作推出 Business Data Cloud，强调“整合 SAP 和非 SAP 数据”，这一幕似曾相识，难道是“仓库原生（Warehouse-Native）”概念的回光返照？还是现代数据栈正在以另一种形式重获新生？

一、现代数据栈的起落：从希望到幻灭

回顾现代数据栈的兴起，它其实是对传统企业数据架构混乱的一次反叛。

在过去，每个企业应用都拥有自己的数据：

• Salesforce 有自己的客户列表

• Zendesk 同样

• Marketo、Jira、Stripe……各有各的版本

最终，一家公司可能拥有上百份不同的客户列表，数据团队每天的工作就是比对这些列表、发现冲突、填补空白，整个企业被这些“孤岛”所困。

现代数据栈承诺解决这个问题——“别再让每个应用维护自己的数据，把所有数据都放进云数据仓库！”

• 所有 SaaS 应用不再存储自己的客户列表，而是直接访问数据仓库中的“单一事实来源”。

• 所有企业分析、BI、机器学习，都基于这个“统一的数据库”进行计算。

这听起来是一个美好的愿景，但现实是，企业并不愿意放弃自己已有的复杂系统，迁移到一个单一的云端仓库。

• Salesforce、SAP 这些巨头软件的核心竞争力，就是它们的强大定制化能力。

• 让这些企业软件“仓库原生”，相当于让它们放弃数据控制权，这并不现实。

最终，现代数据栈成了一个巨大的“数据工具拼接游戏”，各种 ETL、数据集成、数据治理工具层层叠叠，把数据架构推向了新的复杂度巅峰。在 AI 浪潮到来后，市场对这些基础设施的耐心迅速耗尽，现代数据栈被冷落在角落。

二、数据的混乱，远超想象

现代数据栈没能彻底解决数据孤岛，但数据的混乱并非 SaaS 时代的新产物，它是整个信息化世界的底色。

哪怕是在微软这样全球头部的科技巨头，公司内部也搞不清楚到底有多少人在用 Office 365（O365，Office 的在线版）。

传闻中有一个 6000 行的脚本，可以计算出用户数，但从没人见过它成功运行。最后的解决方案一般也是拼凑几个 Excel 表格，勉强糊弄出一个答案。这听起来像 FTX（那家因财务混乱倒闭的加密交易所）吗？实际上，所谓“天下乌鸦一般黑”，每家公司都是 FTX，只是程度不同而已。

关于这一现象，流行 BI 工具 Mode 的创始人和首席分析官 Benn Stancil 在博客中联想到近期由金价波动带来的实物黄金运输大迁徙。为了从差价中套利，大量金块被塞进商业航班的货舱，正在城市上空不断往返。而一群金融圈的网红交易员，同时也在社交媒体上直播这场“黄金空运战”，甚至成了市场上的“必读资讯”。

数据行业与黄金市场，看似毫不相关的两个例子都在说明同一个事实：

“世界是个巨大的草台班子”这句话的含金量还在上升。

现代信息世界并不像它看起来那样“精密高效”，反而充满了混乱、漏洞和人为干预的空间。

本质上，数据和黄金的运作方式，都是一场表面上精密、实际混乱的游戏。数据并不是“自动流动的真相”，更像是一场精心维护的错觉，背后是无数个 Excel、ETL 作业、API 接口和“手动修正”。

三、SAP x Databricks：重生，还是回光返照？

如今，SAP 宣布与 Databricks 合作，推出 Business Data Cloud，目标是打破 SAP 生态内部的数据孤岛，同时支持非 SAP 数据的整合。

这一模式很有意思，它并没有复活现代数据栈最初的“仓库原生”理念，而是试图换一个思路：

• 不是让所有应用都依赖数据仓库，而是让 SAP 生态的所有数据采用通用格式，使 Databricks 能够直接读取。

• 换句话说，现代数据栈可能不是建立在“统一的数据仓库”上，而是建立在“统一的数据格式”上。

如果 SAP x Databricks 真的做到了这一点，未来的数据架构可能不再是“所有数据归一”，而是“数据格式归一”：

• BI 工具可以直接连接 SAP 数据，而无需复杂的数据迁移。

• 营销工具可以直接访问 Stripe 的账单数据，而不用单独同步数据库。

• AI 代理（AI Agents）可以直接读取 CRM 数据，而无需依赖 API 调用。

这是不是现代数据栈的回归？某种程度上，是的。 但它与几年前的“仓库原生”模式有所不同，它更像是

在数据存储的底层打通，而不是强行迁移一切数据到云端。

四、关注数据本身，跳过繁琐的“栈”——TapData 的方式

现代数据栈的兴起和衰落，揭示了一个关键问题：大多数数据架构的复杂性，来源于工具层的堆叠，而不是数据本身的需求。

从最初的 ETL 到 ELT，再到 Fivetran、dbt、Snowflake，行业在“怎么存数据、怎么转换数据、怎么分析数据”上耗费了无数精力，但最终企业仍然面临数据孤岛、数据延迟、治理困难等老问题。

眼下，这个行业正在试图用数据格式归一来改善数据流动，但更直接的方法是：跳过对“数据栈”的过度关注，直接连接数据本身。 这正是 TapData 的思路之一。

为什么数据架构应该更关注“数据本身”？

• 业务部门和 IT 团队需要的是实时、准确的数据，而不是管理一堆复杂的同步流程。

• 数据仓库、湖仓一体、实时计算……本质上只是数据存储和分析的不同方式，数据如何流动才是更核心的问题。

• 现代企业的数据生态不仅仅是 SAP、Snowflake、Databricks 这些“大块头”，它们还要处理大量非结构化数据、IoT 数据、第三方 API 数据，这些数据不能全都“仓库化”。

TapData：直接连接底层数据，打破“栈”的束缚

TapData 不是在数据仓库或数据湖之上再叠加工具，而是专注于数据流动本身。

• 实时数据集成：连接 MongoDB、MySQL、Kafka 等多种异构数据源，更关注底层数据库的数据，做到毫秒级延迟的数据同步，避免数据孤岛。

• 数据即服务（DaaS）：让不同应用无需迁移数据，而是直接查询和消费数据，类似 SAP x Databricks 试图做的“格式归一”，但更灵活。

• 低代码 & 自动化：减少企业管理 ETL/ELT 流程的负担，让数据流动像 API 一样简单。

数据行业的下一个轮回：让数据自由流动，而不是堆积更多工具

现代数据栈试图通过“工具整合”解决数据孤岛问题，结果却制造了更多的数据复杂性。让数据格式更统一，让数据流动更自由——数据栈的进化方向，不是更多的层，而是更直接的连接。

现代数据栈的重生，不应该是曾经的“仓库原生”那一套，而是真正关注数据本身，让数据流动变得简单、实时、可用。

五、结语：底层数据，才是关键

现代数据栈的教训在于：

• 数据架构不能靠“炫酷的新概念”来解决，而是必须真正理解企业数据流动的需求。

• 孤岛是客观存在的，数据系统不会自动变得整洁。

• 现代化数据工具的成功与否，取决于能否真正降低数据整理的成本，而不是让企业再多买几个工具。

SAP x Databricks 的合作，或许预示着现代数据栈的某种回归。但这次，它必须更贴近现实，而不是再次陷入工具堆叠的陷阱。数据行业，注定在混乱与秩序之间反复轮回。