当AI吞噬软件，数据正在成为企业唯一的护城河

作者 | 关涛、苏郡城

审校 | 李文朋

编者按：近日编者获悉，国内领先的数据平台公司“云器科技”完成 B 轮融资，其聚焦在亚洲市场，产品战略对标 Databricks。随 AI 持续火热，全球数据基础设施市场也正经历一场范式转移。本文将对比国内外数据领域技术发展，深度拆解 AI 时代数据平台必须要完成的进化之路。

当大模型成为通用商品，资金正疯狂涌向唯一的非标资产——数据

2026 年初，全球科技界正经历一场前所未有的范式转移。AI 三要素（算法、算力、数据）中，算法与算力正在快速商品化。算法层面，大模型加速标准化，逐步成为通用的“超级大脑”；算力层面，AI 数据中心的规模化建设使算力供给日益充足。二者获取门槛大幅降低，但也日趋同质。

全球具备基础模型研发能力的企业不超过 10 家，AI 芯片厂商更是屈指可数。对绝大多数企业而言，其私有高质量数据正在成为企业竞争力唯一的护城河。

资本市场已率先捕捉到这一趋势，AI 数据基础设施成为投资热点。一个标志性事件是，在一级市场中，Databricks 估值约增长 2.7 倍；ClickHouse 估值约增长 3 倍。

资本市场对 Databricks 和类似技术栈的追捧，本质上是对 “Data + AI” 这一轮新增长飞轮的押注，数据作为核心生产要素的地位已无可撼动。但现实是，大多数企业的数据体系没准备好迎接 AI，没有做到基础设施的 AI 就绪（AI-Ready）。

过去二十年，企业建设了数据中台、数仓和治理体系，但在 AI 真正落地时发现，许多数据资产 “用不上”。根本原因在于，传统数据平台是为 SQL 设计的，擅长处理 Filter（过滤）、Aggregation（聚合）、Join（连接）等确定性计算，数据必须结构化。

但企业 80% 以上的数据是文档、音视频、聊天记录、会议纪要等 “非结构化数据”。这些数据长期躺在各个系统中，被称为 “暗数据”（Dark Data）。

更关键的是访问模式的改变。人类分析师习惯于看日报、周报，容忍 T+1 的数据延迟，且查询模式多为 “全量扫描” 后的聚合指标。

而 Agent 的访问模式完全不同：它们可能在秒级发起成千上万次查询，要求毫秒级的响应，且查询方式多为基于语义的 “精准检索”（Vector Search）。

这种高频、低延迟、基于语义的机器交互需求，彻底击穿了传统 Lambda 架构的性能与成本底线。如果沿用老架构，每一次 Agent 的思考都可能触发昂贵的全表扫描，导致算力成本指数级上升。

1 当前数据基建支持 AI 就绪的两个结构性障碍

企业这些年在数据建设上投入不少，数据中台、数仓、治理体系都搭了，但许多数据资产“缺失”“用不上”“用不好”的问题，主要出在两个地方。

架构的熵增： Lambda 架构的“一致性难题”是通向 AI 实时决策的巨额债务，且注定无法解决。

过去十年，为了同时支持实时和离线，行业普遍采用 Lambda 架构：批处理一套，流处理一套。这一选择由彼时的业务需求与技术条件共同决定。

Lambda 架构的数据平台受到“数据不可能三角”限制——你无法同时获得数据的实时性、低成本和高查询性能；只能三者取其二。通常，批处理面向成本和复杂查询优化，流处理面向解决实时性优化，两套系统各司其职。

（图：典型的 Lambda 架构）

痼疾也很明显，如两套系统的数据很难对齐。同一个指标，批处理通过复杂的 ETL 处理和计算形成的指标，与流计算不一定对得上。

所以说 Lambda 架构下的“数据一致性”基本是美好愿望，需要巨大的运维成本，潜在制约了数据业务整合和发展。另外还有维护成本高，运维复杂等问题。

BI 时代这个问题勉强能忍，但 AI 时代忍不了了。

传统数据库扫描一张结构化数据表，成本可能几分钱；同样的数据如果送给大模型做推理，成本可能几百块，差距在 10 万倍量级。

且 Agent 要求新数据尽快就绪可召回，因此 AI 时代要求引擎同时满足数据不可能三角的三个顶点（新鲜度、低成本、Readiness）。这意味着“有问题就全量重跑”的兜底方案彻底失效——你必须精确知道哪些数据变了，只处理增量。

但 Lambda 架构的数据平台，天然做不到这一点。因为基于多套系统、多套逻辑、多套数据血缘。

范式不适配：AI 的原料与计算模式均与传统数据平台迥异

AI 需要的原料是文档、音视频等“非结构化数据”，这些占了企业数据的 80% 以上，且包含大量有价值 Context 信息，我们称他们为“暗数据”。

真正的业务 know-how——客户是怎么想的、项目是怎么推进的、决策是怎么做出的——大部分都藏在一个模糊的非结构化数据为核心编织的数据网络里。

过去，这些数据的价值只能靠数据科学家人工去挖掘。现在，AI 第一次提供了规模化处理这些数据的可能性。

但现在的数据库 / 数仓 / 数据平台是为结构化数据和关系模型设计的。却不擅长处理文档、音视频。这是处理非结构化数据（AI 的主要原料）时的范式缺失。

这些缺失是结构性和根本性的，是从底层的处理硬件开始（GPU vs CPU）、到存储系统、存储格式、数据管理、元数据系统到引擎算子的全技术栈缺失。

2 AI 引入的三大范式变化

要打造 AI 时代的数据护城河，必须对底层架构进行彻底的范式重构，这集中体现在计算能力、数据形态与访问模式的三个维度。

高阶计算能力：从 关系代数 到 AI 模型

过去，数据库和数据平台只有一种引擎：结构化分析引擎，基于关系代数，符号化、确定性、低语境依赖。你给它一条 SQL，它返回一个确定的结果，分毫不差。

但 AI 引擎的特性完全不同：基于概率模型，模糊匹配、概率推断、高语境依赖。同一个问题问两遍可能得到不同答案。

但正因如此，它能做传统引擎做不到的事——理解、抽取、总结、推理、生成。

例如，在经典的 DIKW（数据 - 信息 - 知识 - 智慧）金字塔中，传统结构化引擎的能力边界在 Information 层——它能把数据加工成报表和指标，但无法告诉你这些指标“意味着什么”。AI 引擎能深入到 Knowledge 层级，实现真正的语义理解和推理。

换个角度：如果把传统引擎类比为大脑顶叶（负责数学计算），AI 引擎则对应前额叶皮层（负责高阶认知、规划、决策）。两者的关系是互补而非替代——二维关系计算交给传统引擎，总结、归纳及推等认知计算交给 AI 引擎。

暗数据的解锁：Lakehouse 下的多模态表达

⻓期以来，企业数据资产中超过 80% 都是⾮结构化或半结构化的 “暗数据ˮ（Dark Data），如客⼾服务的录⾳、合同 PDF ⽂档、监控视频等。在传统数仓架构下，这些数据往往被丢弃或仅作为冷备份存储，⽆法参与核⼼业务计算。

Lakehouse（湖仓一体）架构的普及为这些数据的存储提供了低成本方案，但通过 AI 对其进行深度解析才是关键。

通过 AI 的多模态处理能力，能够自动解析、向量化并索引这些非结构化数据，将其转化为机器可理解的格式。这意味着企业可以首次全景式地利用其拥有的所有信息资源，而非仅仅通过那 20% 的结构化表格来决策。

访问模式转变：从 Scan 到 Search

AI 引擎有一个独特特性：上下文窗口极小（100 万 Token 约等于 4MB），但处理成本极高。1TB 数据，AI 引擎推理需要 25 万个窗口，总成本高达百万美元，同样的数据量大数据引擎处理成本在 5 美元以下。

这带来访问模式的根本转变：从“全量扫描”转向“精准检索”。例如计算 “过去一年的总销售额”。这需要扫描大量行数据。然而，AI Agent 的典型访问模式完全不同：它们更多地进行 “精准检索”（Point Lookup）或 “语义搜索”（Vector Search），例如 “找到与该投诉最相似的历史案例”。

这种从 Scan 到 Search 的转变，对底层存储引擎的索引结构、缓存策略和并发能力提出了全新的要求。RAG（检索增强生成）技术的兴起，本质上就是为了解决这一问题。

但 RAG 仅仅是检索环节，更重要的是如何构建一个高效、实时、低成本的 AI 处理平台，将非结构化数据转化为 AI 就绪（AI-Ready）的知识并存储在 RAG 中。

3 未来架构蓝图：AI 原生数据平台的五个设计原则

基于上述变革，构建新一代数据护城河需要遵循五个核心原则，这些原则构成了 AI 原生数据平台的蓝图。Databricks、Snowflake 以及国内云器科技等厂商，都在沿着这个方向演进。

核心设计原则概览

• 原则一：Lakehouse 统一存储。 一份数据，多种视图（Table/Vector/Graph），打破结构化与非结构化的边界。

• 原则二：AI 作为原生计算引擎。 AI 能力内嵌至 SQL，支持 AI ETL 与 GPU 统一调度。

• 原则三：增量计算结合的奖牌架构。 抛弃 Lambda 架构，采用全链路增量（GIC）构建奖牌架构。

• 原则四：Agent 友好 的开发范式。 API First，自然语言交互，建立 “执行 - 反馈” 闭环。

• 原则五：企业级能力。 细粒度权限治理，Serverless 弹性伸缩，满足审计与合规需求。

原则一：Lakehouse 统一存储

Lakehouse 的核心是用一套系统同时支持低成本存储和高效查询。但对 AI 原生平台来说，更关键的是它原生支持多种数据表达形态。同一份数据可以有多种表达，不同表达带来不同的能力边界。

以一段客户反馈为例，同样的信息可以有不同的存储方式，假如：

• 存成原始文本：信息最完整，但检索效率低

• 抽取成结构化字段（情感倾向、产品类别、问题类型）：查询快、可聚合，但丢失了细节

• 转成向量：支持语义检索，能找到“意思相近”的内容

• 构建图关系：能表达客户、产品、问题之间的关联网络

不同形态有不同权衡。越靠近结构化，准确率越高、可解释性越强、处理成本越低；越靠近原始态，信息越丰富、灵活性越高，但成本也越高。

一个洞察是，AI 的数据不应该独立建一套平台。它应该和结构化数据融合在一起，因为 AI 处理流程中有大量结构化计算的需求。把两者割裂开，反而会制造新的数据孤岛。

举个例子：你问 AI “Meta 2021 年的营收是多少”，如果只有原始文本，AI 可能猜错单位（是百万还是十亿？美元还是其他货币？）。但如果结构化数据和语义层（Semantic Layer）结合，标注清楚 revenue 列的单位和口径，回答就会精确得多。

这就是为什么 Lakehouse 架构强调统一——不是简单地把数据堆在一起，而是让不同形态的数据能够协同工作。

原则二：内生 AI 计算

AI 能力必须内嵌到数据平台，成为 SQL 的一部分，而非通过 API 外挂。

海外头部厂商已经在这样做。Snowflake 和 Databricks 都在 SQL 里加入了一系列 AI 算子，形成了相对完整的能力图谱：

• AI_COMPLETE：文本补全和生成，比如根据上下文自动填充缺失字段

• AI_EXTRACT：从非结构化文本中抽取结构化信息，比如从合同里提取关键条款

• AI_FILTER：语义级别的过滤，比如筛选"与某主题相关"的内容

• AI_AGGREGATE：对文本内容做聚合摘要，比如把 100 条客户反馈总结成 3 个要点

• AI_CLASSIFY：分类打标，比如判断一段文本的情感倾向或主题类别

这些算子对应的底层能力，其实就是大模型的理解、抽取、生成、总结、推理。但封装成 SQL 算子之后，AI 模型与数据结果的结合表达能力获得大幅提升，不需要搭 LangChain，不需要懂 Prompt Engineering，一条 SQL 搞定。

（图：AI 能力与 SQL 算子的融合，Snowflake Cortex AI）

举个具体场景：金融分析师每天面对上万条新闻，传统做法要么人工筛选，要么写复杂的关键词规则（然后漏掉大量相关信息）。现在可以直接写：

WHERE AI_FILTER(content, '与我关注的公司直接相关的新闻')

如果需要更精细的处理，还可以组合多个算子：

WHERE AI_FILTER(content, '与科技行业相关的重大事件')

这才是真正的多模态计算——AI 和 SQL 在同一个执行引擎里协同工作，而非简单的多模态召回。是在统一的数据 governance 的环境中做权限管理的 AI 数据处理，符合隐私合规；而且算子可组合，复杂逻辑也能表达。

原则三：大奖牌架构与增量计算 - “只计算变化的部分”

传统 Lambda 架构维护实时和离线两套代码，导致逻辑冗余且指标经常无法对齐。Databricks 和微软 2024 年提出的 Medallion Architecture（大奖牌架构）已成为 AI+Data 数据处理的标准模型。（Reference：Databricks：What is a medallion architecture? Medallion Architecture 101: Building Data Pipelines That Don't Fall Apart）

这个架构的核心思想是把数据处理分成三层，像炼矿一样逐级提纯：

Bronze 层（铜）：存原始数据，越原始越好，不做任何加工。就像矿石——今天你炼铁，明天可能发现里面还有金子。原始数据不能丢，因为你不知道未来会需要什么。

Silver 层（银）：做清洗、抽取、结构化。把非结构化数据转成可查询的格式，把脏数据清理掉，统一 schema。这一层是数据质量的关键战场。

Gold 层（金）：生成最终产出——报表、特征、指标，直接供业务和模型使用。

并且，这个架构同时适用于结构化和非结构化数据。

图：奖牌架构数据处理流程：结构化数据（上图）；非结构化数据（下图）

奖牌架构是一套建模方法，它最终能跑起来，有一个前提：增量计算能力。

奖牌架构有四个核心原则：灵活性（Flexibility）、数据质量管理（Data Quality Management）、成本效率（Cost Efficiency）、以及最关键的——增量 ETL（Incremental ETL）。

前三个相对直观，第四个是难点和核心。为什么？因为 AI 推理成本极高，“全量重跑”模式根本不可行。每次数据更新都从头算一遍，成本和延迟都无法接受。

奖牌架构本质上是一个 Kappa 架构——端到端的统一增量数据处理流程，不再区分流 / 批等传统计算模型。但这个架构能跑起来的前提是：必须有真正的增量计算能力。

AI 推理成本决定了“全量重跑”不可行。通用增量计算（GIC）的核心思想是：

（图：增量计算原理）

只处理变化的部分，不重复计算已经算过的东西。这个方式并不像说的那样容易，需要从底层重新设计计算引擎：精确追踪数据的每一个变化，理解变化对下游计算的影响，只对需要更新的部分做增量处理。这涉及到存储格式、索引结构、执行计划、状态管理的全面重构。

理想的增量计算引擎能用一套系统 Single-Engine 同时支持实时和离线，同一套代码、同一份数据、同一个执行引擎。（增量计算白皮书 -- 请参看附录）

原则四：Agent 友好的开发范式

当软件使用者从人变成 Agent，开发平台的设计范式也必须改变。

过去的数据开发平台，核心交互是 GUI：拖拉拽建模、点选配置、根据监控调整。这对人很友好，但 Agent 并不需要点按钮。

面向 Agent 的设计需要几个根本转变：

• API First 而非 UI First。 Agent 通过接口与系统交互，所有能力都必须 API 化。GUI 变成可选的观测层，而非核心交互层。

• 自然语言作为主要接口。 Agent 用“交流”的方式检索和操作数据。NL2SQL 不再是锦上添花的功能，而是核心能力。Agent 可以在一次查询里融合文本、向量、图关系的检索结果，实现真正的多模态查询。

• 反馈链路不可或缺。 AI 是概率模型，有时对有时错。传统软件是确定性的——代码写对了就永远对。但 AI 系统需要持续校正，需要建立“执行→反馈→调整”的闭环机制，像机器学习训练一样不断迭代。

• 自解释的语义层。 Agent 需要理解数据的业务含义，而非只知道表名和字段名。这要求数据平台具备丰富的元数据和语义描述，让 Agent 能够自主理解"revenue 列的单位是什么""这两个表之间是什么业务关系"。

但有一点需要清醒认识：短期内人不会完全退出，而且人与 Agent 的交互也同样关键。

AI 写的代码、做的决策仍需人来检查与审批。不管 AI 多强，"因为是 AI 写的所以 bug 不算数"这种逻辑并不成立。人的角色从"开发者"变成"Reviewer+Observer"——审批关键决策，监控系统运行。

未来的数据平台会是混合模式：Agent 负责主要的开发和执行，人作为审批者和监控者。平台需要同时支持两种交互范式。

原则五：企业级治理能力

AI 原生时代，开源自建的 ROI 逻辑在改变。

Agent 大规模调用企业数据时，细粒度访问控制变得极其重要——财务报表、员工工资、客户隐私管理、严格的权限隔离、数据防泄露等企业级数据管理与治理能力。此外，AI 的决策需要可追溯、可审计，在金融、医疗等强监管行业尤其关键。

这些能力开源软件天然缺失，商业级托管平台天然具备。这也是为什么 Databricks/Snowflake 这一类商业平台受到包括 OpenAI 在内的新一代企业青睐的原因。

路径选择：全球共识与中国式解法

上述五个原则由云器科技总结提出，事实上全球头部厂商都在沿着这个方向演进，只是路径选择各有不同。

Databricks是这套范式的最佳践行者。从 Spark 起家，到推出 Delta Lake 实现湖仓一体，再到 2024 年系统性提出 Medallion Architecture，它一直在引领 Data+AI 融合的技术方向。商业上，Databricks 坚持云中立 + 托管化，不绑定任何一家云厂商，这让它能够服务于多云和混合云场景的企业客户。

Snowflake也是数据领域的先行者之一。它的底子是云原生数仓，强项在结构化数据的极致性能。面对 AI 浪潮，Snowflake 选择通过收购和集成来补齐能力——Document AI 处理非结构化数据，Cortex 提供 AI 服务，Snowpark 支持 Python 生态。路径不同，但方向一致。

值得注意的是，这两家公司都没有选择自研基础模型，而是专注于数据的价值挖掘。

中国市场有其特殊性。

一方面，国内云厂商的技术栈与海外存在较大差异；另一方面，企业对数据主权和合规性有更高要求。直接照搬海外方案并不现实，这给了本土厂商机会。云器科技 是目前国内最接近 Databricks 定位的公司。技术上，它基于 Lakehouse + GIC 实现了批流一体的架构重构；商业上，同样坚持云中立与全托管路线。

目前，云器科技的这一架构已在蚂蚁集团、小红书、快手等头部互联网公司的生产环境中得到了验证。这些场景往往具有极高的数据吞吐量和复杂的业务逻辑，能在这些苛刻环境中稳定运行，证明了该技术路径的成熟度与可替代性。

（表：Databricks 与云器科技产品对比）

编者按： 据悉，近期云器科技已完成 B 轮融资。资金将主要用于新一代 AI 数据基础平台的持续研发，进一步推动 AI 原生数据架构在本土市场的落地与普及。当前形势下，作为国内最接近 Databricks 定位的公司，云器的融资进展也反映出资本对亚太 Data+AI 基础设施赛道的持续看好。

4 终局：构建智能时代的数据壁垒

从最宏观的视角看，数据平台的定位在 AI 时代正在发生根本变化。

关键事实：

• 用户主体变迁： 软件的主要使用者正在从人类（Human）加速转向智能体（Agent），要求数据接口具备更高频、低延迟的机器交互能力。

• 架构痛点解决： 传统 Lambda 架构在即时性与准确性上难以兼得，且维护成本高昂；云器科技通过统一的流批一体与增量计算技术，彻底解决了数据一致性难题。

• 暗数据价值释放： 针对企业内部大量存在的非结构化 “暗数据”（文档、日志、多媒体），平台提供了原生的存储与计算支持，使其成为可被 AI 利用的高价值资产。

• 计算模式革新： 从传统的全量扫描（Scanning）模式转向更高效的搜索（Searching）模式，大幅提升了 RAG（检索增强生成）场景下的响应速度。

• 技术路径融合： 采用 Lakehouse 架构作为数据底座，结合独创的 GIC（增量计算）技术，实现了存储成本与计算效率的最优平衡。

• 中国生态定位： 针对中国企业复杂的 IT 环境，云器科技提供云中立且具备完全托管能力的解决方案，填补了国内市场在高端 AI 数据基础设施上的空白

过去它是“被动响应的资产库”——业务系统产生数据，数据平台存起来，有人查就返回结果。未来它将成为“主动参与决策的智能实体”的底座，是企业 AI 的“记忆与知识库”。

可以想象这样的场景：Agent 群在上面运行、学习、协作，数据平台在下面收集、计算、优化数据。与上层 Agent 形成互动。AI 消费数据、理解数据、改写数据，数据再反过来塑造 AI 的行为与能力。

这个循环迭代越快，系统的智能水平就越高。

更宏观地看，AI+Data 正在形成新的技术范式。未来的超级智能不会是孤立的模型，而是持续运转的系统——是数据 + 算力 + 模型的融合；它既使用知识，也创造知识。数据不再是被动存放的资源，而是不断加工、更新、进化的运行态。

承载这个循环的核心基础设施，必然是 AI 原生的数据平台。谁能更快完成从传统架构到 AI 原生的迁移，谁就更有机会在下一轮基础设施竞争中占据位置。

Reference

AI SQL Query Language：https://www.snowflake.com/en/blog/ai-sql-query-language/

奖牌模型 Medallion Architecture: https://www.databricks.com/glossary/medallion-architecture

Medallion Architecture 101: Building Data Pipelines That Don't Fall Apart： https://dev.to/aawiegel/medallion-architecture-101-building-data-pipelines-that-dont-fall-apart-1gil

增量计算白皮书：https://www.yunqi.tech/resource/incremental-computation/reservation