當AI吞噬軟件，數據正在成為企業唯一的護城河

数据见闻

2026年6月3日

AI 時代數據成企業核心護城河，詳解 AI 原生數據平台五大設計原則與技術演進路徑。

編者按： 近日編者獲悉，國內領先的數據平台公司「雲器科技」(Singdata)完成B輪融資，其聚焦在亞洲市場，產品戰略對標Databricks。隨AI持續火熱，全球數據基礎設施市場也正經歷一場範式轉移。本文將對比國內外數據領域技術發展，深度拆解AI時代數據平台必須完成的進化之路。

導語：當大模型成為通用商品，資金正瘋狂湧向唯一的非標資產——數據

2026年初，全球科技界正經歷一場前所未有的範式轉移。AI三要素（算法、算力、數據）中，算法與算力正在快速商品化。算法層面，大模型加速標準化，逐步成為通用的「超級大腦」；算力層面，AI數據中心的規模化建設使算力供給日益充足。二者獲取門檻大幅降低，但也日趨同質。

全球具備基礎模型研發能力的企業不超過10家，AI芯片廠商更是屈指可數。對絕大多數企業而言，其私有高質量數據正在成為企業競爭力唯一的護城河。

資本市場已率先捕捉到這一趨勢，AI數據基礎設施成為投資熱點。一個標誌性事件是，在一級市場中，過去18個月，Databricks估值約增長3.1倍，最新估值達1340億美金；ClickHouse估值約增長7.5倍。

資本市場對Databricks和類似技術棧的追捧，本質上是對「Data + AI」這一輪新增長飛輪的押注，數據作為核心生產要素的地位已無可撼動。但現實是，大多數企業的數據體系沒準備好迎接AI，沒有做到基礎設施的AI就緒（AI-Ready）。

過去二十年，企業建設了數據中台、數倉和治理體系，但在AI真正落地時發現，許多數據資產「用不上」。根本原因在於，傳統數據平台是為SQL設計的，擅長處理Filter（過濾）、Aggregation（聚合）、Join（連接）等確定性計算，數據必須結構化。

但企業80%以上的數據是文檔、音視頻、聊天記錄、會議紀要等「非結構化數據」。這些數據長期躺在各個系統中，被稱為「暗數據」（Dark Data）。

更關鍵的是訪問模式的改變。人類分析師習慣於看日報、週報，容忍T+1的數據延遲，且查詢模式多為「全量掃描」後的聚合指標。

而Agent的訪問模式完全不同：它們可能在秒級發起成千上萬次查詢，要求毫秒級的響應，且查詢方式多為基於語義的「精準檢索」（Vector Search）。

這種高頻、低延遲、基於語義的機器交互需求，徹底擊穿了傳統Lambda架構的性能與成本底線。如果沿用老架構，每一次Agent的思考都可能觸發昂貴的全表掃描，導致算力成本指數級上升。

一、當前數據基建支持AI就緒的兩個結構性障礙

企業這些年在數據建設上投入不少，數據中台、數倉、治理體系都搭了，但許多數據資產「缺失」「用不上」「用不好」的問題，主要出在兩個地方。

1.1 架構的熵增：Lambda架構的「一致性難題」是通向AI實時決策的巨額債務，且注定無法解決

過去十年，為了同時支持實時和離線，行業普遍採用Lambda架構：批處理一套，流處理一套。這一選擇由彼時的業務需求與技術條件共同決定。

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

痼疾也很明顯，如兩套系統的數據很難對齊。同一個指標，批處理通過複雜的ETL處理和計算形成的指標，與流計算不一定對得上。

所以說Lambda架構下的「數據一致性」基本是美好願望，需要巨大的運維成本，潛在制約了數據業務整合和發展。另外還有維護成本高、運維複雜等問題。

BI時代這個問題勉強能忍，但AI時代忍不了了。

傳統數據庫掃描一張結構化數據表，成本可能幾分錢；同樣的數據如果送給大模型做推理，成本可能幾百塊，差距在10萬倍量級。

且Agent要求新數據儘快就緒可召回，因此AI時代要求引擎同時滿足數據不可能三角的三個頂點（新鮮度、低成本、Readiness）。這意味著「有問題就全量重跑」的兜底方案徹底失效——你必須精確知道哪些數據變了，只處理增量。

但Lambda架構的數據平台，天然做不到這一點。因為基於多套系統、多套邏輯、多套數據血緣。

1.2 範式不適配：AI的原料與計算模式均與傳統數據平台迥異

AI需要的原料是文檔、音視頻等「非結構化數據」，這些佔了企業數據的80%以上，且包含大量有價值的Context信息，我們稱他們為「暗數據」。

真正的業務know-how——客戶是怎麼想的、項目是怎麼推進的、決策是怎麼做出的——大部分都藏在一個模糊的以非結構化數據為核心編織的數據網絡裡。

過去，這些數據的價值只能靠數據科學家人工去挖掘。現在，AI第一次提供了規模化處理這些數據的可能性。

但現在的數據庫／數倉／數據平台是為結構化數據和關係模型設計的，並不擅長處理文檔、音視頻。這是處理非結構化數據（AI的主要原料）時的範式缺失。

這些缺失是結構性和根本性的，是從底層的處理硬件開始（GPU vs CPU）、到存儲系統、存儲格式、數據管理、元數據系統到引擎算子的全技術棧缺失。

二、AI引入的三大範式變化

要打造AI時代的數據護城河，必須對底層架構進行徹底的範式重構，這集中體現在計算能力、數據形態與訪問模式的三個維度。

2.1 高階計算能力：從關係代數到AI模型

過去，數據庫和數據平台只有一種引擎：結構化分析引擎，基於關係代數，符號化、確定性、低語境依賴。你給它一條SQL，它返回一個確定的結果，分毫不差。

但AI引擎的特性完全不同：基於概率模型，模糊匹配、概率推斷、高語境依賴。同一個問題問兩遍可能得到不同答案。

但正因如此，它能做傳統引擎做不到的事——理解、抽取、總結、推理、生成。

能力類型	代數／關係運算（結構化資料分析引擎）	推理／歸納／規劃（AI引擎）
計算層次	低階	高階
計算特徵	符號化、規則驅動、可精確驗證	模糊匹配、概率推斷、多模態整合
認知需求	低語境依賴，確定性處理	高語境依賴，不確定性處理
生物神經基礎（類比）	大腦頂葉（數學處理區域）	前額葉皮層（高階認知區）

例如，在經典的DIKW（數據－信息－知識－智慧）金字塔中，傳統結構化引擎的能力邊界在Information層——它能把數據加工成報表和指標，但無法告訴你這些指標「意味著什麼」。AI引擎能深入到Knowledge層級，實現真正的語義理解和推理。

換個角度：如果把傳統引擎類比為大腦頂葉（負責數學計算），AI引擎則對應前額葉皮層（負責高階認知、規劃、決策）。兩者的關係是互補而非替代——二維關係計算交給傳統引擎，總結、歸納及推理等認知計算交給AI引擎。

2.2 暗數據的解鎖：Lakehouse下的多模態表達

長期以來，企業數據資產中超過80%都是非結構化或半結構化的「暗數據」（Dark Data），如客戶服務的錄音、合同PDF文檔、監控視頻等。在傳統數倉架構下，這些數據往往被丟棄或僅作為冷備份存儲，無法參與核心業務計算。

Lakehouse（湖倉一體）架構的普及為這些數據的存儲提供了低成本方案，但通過AI對其進行深度解析才是關鍵。

通過AI的多模態處理能力，能夠自動解析、向量化並索引這些非結構化數據，將其轉化為機器可理解的格式。這意味著企業可以首次全景式地利用其擁有的所有信息資源，而非僅僅通過那20%的結構化表格來決策。

2.3 訪問模式轉變：從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中。

三、未來架構藍圖：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搞定。

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

sql

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

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

sql

SELECT
  AI_EXTRACT(content, '提取涉及的公司名稱和事件類型') as event_info,
  AI_CLASSIFY(content, ['利好', '利空', '中性']) as sentiment
FROM news_feed
WHERE AI_FILTER(content, '與科技行業相關的重大事件')

這才是真正的多模態計算——AI和SQL在同一個執行引擎裡協同工作，而非簡單的多模態召回。是在統一的數據governance環境中做權限管理的AI數據處理，符合隱私合規；而且算子可組合，複雜邏輯也能表達。

原則三：大獎牌架構與增量計算——「只計算變化的部分」

傳統Lambda架構維護實時和離線兩套代碼，導致邏輯冗餘且指標經常無法對齊。Databricks和微軟2024年提出的Medallion Architecture（大獎牌架構）已成為AI+Data數據處理的標準模型。

這個架構的核心思想是把數據處理分成三層，像煉礦一樣逐級提純：

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在內的新一代企業青睞的原因。

路徑選擇：全球共識與中國式解法

上述五個原則由Singdata總結提出，事實上全球頭部廠商都在沿著這個方向演進，只是路徑選擇各有不同。

Databricks 是這套範式的最佳踐行者。從Spark起家，到推出Delta Lake實現湖倉一體，再到2024年系統性提出Medallion Architecture，它一直在引領Data+AI融合的技術方向。商業上，Databricks堅持雲中立+托管化，不綁定任何一家雲廠商，這讓它能夠服務於多雲和混合雲場景的企業客戶。

Snowflake 也是數據領域的先行者之一。它的底子是雲原生數倉，強項在結構化數據的極致性能。面對AI浪潮，Snowflake選擇通過收購和集成來補齊能力——Document AI處理非結構化數據，Cortex提供AI服務，Snowpark支持Python生態。路徑不同，但方向一致。

值得注意的是，這兩家公司都沒有選擇自研基礎模型，而是專注於數據的價值挖掘。

中國市場有其特殊性。

一方面，國內雲廠商的技術棧與海外存在較大差異；另一方面，企業對數據主權和合規性有更高要求。直接照搬海外方案並不現實，這給了本土廠商機會。Singdata 是目前國內最接近Databricks定位的公司。技術上，它基於Lakehouse + GIC實現了批流一體的架構重構；商業上，同樣堅持雲中立與全托管路線。

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

編者按： 據悉，近期雲器科技(Singdata)已完成B輪融資。資金將主要用於新一代AI數據基礎平台的持續研發，進一步推動AI原生數據架構在本土市場的落地與普及。當前形勢下，作為國內最接近Databricks定位的公司，雲器的融資進展也反映出資本對亞太Data+AI基礎設施賽道的持續看好。

四、終局：構建智能時代的數據壁壘

從最宏觀的視角看，數據平台的定位在AI時代正在發生根本變化。

關鍵事實：

用戶主體變遷： 軟件的主要使用者正在從人類（Human）加速轉向智能體（Agent），要求數據接口具備更高頻、低延遲的機器交互能力。
架構痛點解決： 傳統Lambda架構在即時性與準確性上難以兼得，且維護成本高昂；Singdata通過統一的流批一體與增量計算技術，徹底解決了數據一致性難題。
暗數據價值釋放： 針對企業內部大量存在的非結構化「暗數據」（文檔、日誌、多媒體），平台提供了原生的存儲與計算支持，使其成為可被AI利用的高價值資產。
計算模式革新： 從傳統的全量掃描（Scanning）模式轉向更高效的搜索（Searching）模式，大幅提升了RAG（檢索增強生成）場景下的響應速度。
技術路徑融合： 採用Lakehouse架構作為數據底座，結合獨創的GIC（增量計算）技術，實現了存儲成本與計算效率的最優平衡。
中國生態定位： 針對中國企業複雜的IT環境，Singdata提供雲中立且具備完全托管能力的解決方案，填補了國內市場在高端AI數據基礎設施上的空白。

過去它是「被動響應的資產庫」——業務系統產生數據，數據平台存起來，有人查就返回結果。未來它將成為「主動參與決策的智能實體」的底座，是企業AI的「記憶與知識庫」。

可以想象這樣的場景：Agent群在上面運行、學習、協作，數據平台在下面收集、計算、優化數據，與上層Agent形成互動。AI消費數據、理解數據、改寫數據，數據再反過來塑造AI的行為與能力。

這個循環迭代越快，系統的智能水平就越高。

更宏觀地看，AI+Data正在形成新的技術範式。未來的超級智能不會是孤立的模型，而是持續運轉的系統——是數據+算力+模型的融合；它既使用知識，也創造知識。數據不再是被動存放的資源，而是不斷加工、更新、進化的運行態。

承載這個循環的核心基礎設施，必然是AI原生的數據平台。誰能更快完成從傳統架構到AI原生的遷移，誰就更有機會在下一輪基礎設施競爭中佔據位置。

產品演示與專屬交流通道：https://www.yunqi.tech/reservation