當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 架構的數據平臺受到「數據不可能三角」限制——你無法同時獲得數據的實時性、低成本和高查詢性能；只能三者取其二。通常，批處理面向成本和複雜查詢優化，流處理面向解決實時性優化，兩套系統各司其職。

痼疾也很明顯，如兩套系統的數據很難對齊。同一個指標，批處理通過複雜的 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 搞定。

舉個具體場景：金融分析師每天面對上萬條新聞，傳統做法要麼人工篩選，要麼寫複雜的關鍵詞規則（然后漏掉大量相關信息）。現在可以直接寫：

SQLSELECT * FROM news_feedJOIN my_watchlist ON ...  WHERE AI_FILTER(content, '與我關注的公司直接相關的新聞')

如果需要更精細的處理，還可以組合多個算子：

SELECT   AI_EXTRACT(content, '提取涉及的公司名稱和事件類型') as event_info,  AI_CLASSIFY(content, ['利好', '利空', '中性']) as sentimentFROM news_feedWHERE 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 實現了批流一體的架構重構；商業上，同樣堅持雲中立與全託管路線。

目前，雲器科技的這一架構已在螞蟻集團、小紅書、快手等頭部互聯網公司的生產環境中得到了驗證。這些場景往往具有極高的數據吞吐量和複雜的業務邏輯，能在這些苛刻環境中穩定運行，證明了該技術路徑的成熟度與可替代性。

編者按： 據悉，近期雲器科技已完成 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