網(wǎng)易首頁 > 網(wǎng)易號 > 正文申請入駐

從 SQL 到 OSI：當“數(shù)據(jù)是什么意思”也有了標準答案

2026-03-12 17:07:11　來源: InfoQ

北京舉報

分享至

作者 | 周衛(wèi)林，Aloudata 創(chuàng)始人 & CEO

上一篇文章里，我從一個 OpenClaw Skill 聊起，講了一個判斷：個人認知正在被 .md 編譯，企業(yè)認知需要語義層來編譯，而 OSI 標準的發(fā)布意味著這件事正在從愿景變成現(xiàn)實。

不少朋友讀完后問我：OSI 到底是什么？跟 SQL 是什么關系？全球那些數(shù)據(jù)巨頭為什么突然要聯(lián)手搞一個標準？這對中國企業(yè)意味著什么？

這篇文章就來展開聊聊這些問題。

1 先講一段老故事：SQL 是怎么統(tǒng)一世界的

1970 年代，IBM 的研究員基于關系代數(shù)提出了 SEQUEL（后來改名 SQL）。那個年代，每家數(shù)據(jù)庫廠商——DB2、Informix、Sybase——都有自己的私有查詢語言。你在 A 系統(tǒng)上寫的查詢邏輯，換到 B 系統(tǒng)上就得重寫一遍。開發(fā)者被鎖死在特定廠商的生態(tài)里，遷移成本極高。

1986 年，SQL 成為 ANSI 標準，次年被 ISO 采納。標準化之后發(fā)生了什么？應用可以跨數(shù)據(jù)庫遷移了，整個 BI、ERP、數(shù)據(jù)工具的生態(tài)在接下來三十年里蓬勃生長——這個生態(tài)的底座，就是 SQL 這一層“大家都認”的查詢協(xié)議。

回頭看，SQL 標準化給我們?nèi)齻€啟示：

第一，標準解決的是協(xié)作成本問題，不是純技術問題。SQL 不是當時技術上最優(yōu)的查詢語言，但它足夠好，且大家愿意一起用。

第二，標準必須由行業(yè)共同推動，不能是一家廠商的私有方案。如果 SQL 只屬于 IBM，它不可能成為標準。

第三，標準成功依賴實用性，不依賴理論完美性。SQL 到今天還有一堆被人吐槽的設計缺陷，但這不妨礙它統(tǒng)治了四十年。

這段歷史之所以重要，是因為我們正在看到一個高度相似的劇本重演。

2 OSI：讓“數(shù)據(jù)是什么意思”標準化

SQL 解決了“怎么取數(shù)”的標準化問題。但四十年后，一個 SQL 沒有回答的問題變得越來越緊迫：同一個指標名稱，在不同系統(tǒng)里到底是什么意思？

“月度收入”在財務系統(tǒng)里要剔除退款和異常訂單，在市場系統(tǒng)里包含所有支付成功的訂單，在供應鏈系統(tǒng)里只算已發(fā)貨部分。同一個詞，三套計算邏輯。

人類員工處理這種差異靠三種方式：開會對齊、當面確認、老帶新口口相傳。原始但管用。

但 Agent 不會開會。Agent 不會打電話問“你說的 GMV 包含退款嗎”。Agent 拿到一個指標名稱，就會按自己理解的邏輯去算——如果三個 Agent 各算各的，協(xié)同就失效了。

AI Agent 的規(guī)模化落地，把“語義一致性”從一個“有了更好”的優(yōu)化項，變成了“沒有不行”的前提條件。

這就是 OSI 要解決的問題。

2026 年 1 月 27 日，Open Semantic Interchange（OSI）v1.0 規(guī)范在 GitHub 正式發(fā)布（倉庫地址：github.com/open-semantic-interchange/OSI，采用 Apache 2.0 開源許可）。這不是一個概念或倡議——是一份可落地的技術標準，用聲明式 YAML 格式定義指標、維度、關系和上下文（context）的統(tǒng)一描述規(guī)范，讓不同系統(tǒng)可以互相理解對方的語義。簡單說，它給“數(shù)據(jù)是什么意思”提供了一種跨平臺、跨工具的通用語言。

更具體地講：過去你在 dbt 里定義了“凈收入”的計算邏輯，想在 Tableau 或 Power BI 里用，得重新定義一遍。OSI 要解決的就是這個問題——定義一次，導出成 OSI 格式，所有兼容的工具都能直接理解和執(zhí)行。

參與方的陣容本身就是最好的背書：Snowflake、Databricks、Salesforce、dbt Labs、AtScale、Qlik、JetBrains、Collibra、DataHub、Lightdash、Coalesce、Sigma……幾十家全球數(shù)據(jù)技術公司，覆蓋了云平臺、BI 工具、數(shù)據(jù)工程、數(shù)據(jù)治理的完整生態(tài)（完整名單見 OSI 官網(wǎng) open-semantic-interchange.org）。

其中 Snowflake 和 Databricks 兩家最引人注目。當兩個打得不可開交的對手愿意坐下來聯(lián)合定標準的時候，說明市場需求已經(jīng)大到不能再各自為政了。 Salesforce 也在官方博客中明確表態(tài)：“The agentic future demands an open semantic layer”——Agentic AI 的未來要求一個開放的語義層。

3 全球數(shù)據(jù)廠商：殊途同歸的語義層布局

OSI 的發(fā)布不是憑空出現(xiàn)的。過去兩年，整個數(shù)據(jù)技術棧都在向語義層聚攏，只是路徑不同。

BI 平臺在重構(gòu)語義內(nèi)核。 Salesforce 旗下的 Tableau 推出 Tableau Next，內(nèi)置 Tableau Semantics 模塊——官方定義為“AI-infused semantic layer”，明確為 AI Agent 提供統(tǒng)一的業(yè)務術語，并推出了 Data Pro、Concierge、Inspector 三個內(nèi)置 AI Agent（見 tableau.com/products/tableau-next）。Google 旗下的 Looker 長期以語義模型 LookML 為核心能力，2025 年進一步推出 Looker MCP Server，讓 Gemini CLI、Claude 等外部 AI 平臺可以直接查詢 Looker 的語義層（見 Google Cloud Blog Opening up the Looker semantic layer）。Microsoft 則在 Power BI 中將“數(shù)據(jù)集（Dataset）”正式更名為“語義模型（Semantic Model）”，強調(diào)它是業(yè)務知識的載體而非單純的數(shù)據(jù)容器（見 Power BI Blog Datasets renamed to semantic models）。

云平臺在向上延伸語義能力。 Snowflake 2025 年 4 月推出 Native Semantic Views（語義視圖），把語義定義變成數(shù)據(jù)平臺的原生功能，2026 年 2 月進一步發(fā)布 Semantic View Autopilot，用 AI 自動從查詢歷史和 BI 資產(chǎn)中生成語義視圖（見 Snowflake Engineering Blog Native Semantic Views: AI-Powered BI）。Databricks 在 Unity Catalog 中推出 Metric Views，用 YAML 格式定義指標并注冊到統(tǒng)一目錄中，實現(xiàn)“一次定義，處處可信”——在 Dashboard、Genie、Notebook、SQL 中均可直接調(diào)用（見 Databricks Blog What's new with Unity Catalog）。

現(xiàn)代數(shù)據(jù)棧在推動語義中立。 dbt Labs 2025 年 10 月宣布將 MetricFlow 完全開源（Apache 2.0），作為對 OSI 標準的直接承諾，推動指標定義的標準化和可移植——MetricFlow 的 YAML 格式也是 OSI 規(guī)范的底層標準之一（見 dbt Labs Blog dbt Labs Affirms Commitment to OSI by Open Sourcing MetricFlow）。Cube.dev 被 GigaOm 2025 年語義層雷達報告評為“Leader and Outperformer”，定位“Agentic Analytics Platform”，提供 REST、GraphQL、SQL、MDX、DAX 等多種 API 供各類系統(tǒng)調(diào)用（見 Cube Blog Named Leader in 2025 GigaOm Radar）。

這些動作方向一致：語義層正在從應用層的附屬功能，下沉為基礎設施層的核心能力。

而 OSI 做的事，是在這些廠商各自的語義層之間建立一種“互譯協(xié)議”——你在 Snowflake 上定義的“凈收入”，導出成 OSI 格式后，dbt、Tableau、Power BI 都能直接理解和使用，不需要重新定義一遍。根據(jù) OSI 路線圖，Phase 2 的原生平臺支持計劃在 2026 年 Q2-Q4 推進，目標覆蓋 50+ 平臺。

4 對中國企業(yè)意味著什么

看到這里，可能有人會問：這是硅谷的事，跟中國企業(yè)有什么關系？

關系很大。

第一，Agent 的落地速度在中國可能更快。中國企業(yè)對新技術的采納速度一直領先全球——從移動支付到短視頻到直播電商，莫不如此。AI Agent 也一樣。當 Agent 在企業(yè)內(nèi)部大規(guī)模部署的時候，語義一致性的問題會比硅谷更早、更猛烈地爆發(fā)出來。

第二，中國企業(yè)的數(shù)據(jù)治理現(xiàn)狀更需要語義層。很多大型企業(yè)經(jīng)歷了十年的信息化和數(shù)據(jù)中臺建設，積累了大量數(shù)據(jù)資產(chǎn)，但指標定義散落在眾多系統(tǒng)里，口徑差異是常態(tài)。這些“技術債”在傳統(tǒng) BI 時代還能靠人力彌補，到了 Agent 時代就成了硬傷。

第三，OSI 作為開放標準，為中國廠商提供了參與全球生態(tài)的機會。它不是某一家公司的私有格式，而是一個開放協(xié)議（Apache 2.0 許可）。中國的數(shù)據(jù)語義層產(chǎn)品完全可以兼容 OSI 標準，進入全球技術生態(tài)的互操作網(wǎng)絡。

5 OSI 之后，真正的挑戰(zhàn)才開始

最后我想說一個 OSI 沒有解決的問題——這也是我認為下一階段最關鍵的問題。

OSI v1.0 解決的是“定義”層面的標準化：用什么格式描述一個指標、一個維度、一個關系。這很重要，是基礎。

但企業(yè)真正要用起來，光有定義不夠。你還需要：

動態(tài)組裝能力。業(yè)務需求千變?nèi)f化，Agent 可能需要實時組合“過去 24 小時一線城市 35 歲以上女性用戶對促銷活動的響應率”——這種指標不可能預先定義好，需要從原子指標和維度動態(tài)組裝。

執(zhí)行可驗證。從自然語言到語義查詢到 SQL 到結(jié)果，每一步都應該可追溯、可審計。業(yè)務負責人不需要懂 SQL，但他需要能點開看到“這個數(shù)是怎么算出來的”。

性能與精度的平衡。百億級數(shù)據(jù)下的亞秒級響應，同時計算邏輯 100% 準確——這兩個要求經(jīng)常矛盾，需要智能的物化加速和查詢路由來協(xié)調(diào)。

這些，正是“定義”之上的“執(zhí)行”層需要解決的問題。上一篇文章里我把它概括為一句話：定義是協(xié)議的前半段，執(zhí)行是協(xié)議的后半段。OSI 做了前半段，Aloudata 的 Semantic Fabric（語義編織）則把前后兩段都做了。

傳統(tǒng)的“數(shù)倉 + BI”兩層架構(gòu)，正在被“數(shù)據(jù)湖 + 語義層 + 消費層”三層架構(gòu)替代。語義層成為連接原始數(shù)據(jù)與業(yè)務價值的核心樞紐——它對下屏蔽數(shù)據(jù)源的復雜性，對上為 Agent、BI、應用提供統(tǒng)一的語義接口。

6 站在標準化的起點上

標準協(xié)議的價值，往往在普及之后才被充分認知。

回想 1986 年 SQL 成為標準的時候，大多數(shù)人沒有意識到這會催生接下來三十年的整個數(shù)據(jù)庫和 BI 生態(tài)。今天 OSI v1.0 剛剛發(fā)布一個月，它能走多遠、多快，還有很多不確定性。

但有幾件事是確定的：

AI Agent 對語義一致性的依賴，遠遠高于傳統(tǒng)應用對查詢語言的依賴——這意味著標準化的驅(qū)動力比 SQL 時代更強。

現(xiàn)代數(shù)據(jù)生態(tài)的開放程度，遠高于四十年前的封閉競爭時代——這意味著標準推進的阻力更小。

Git、API、Schema Registry 等工程基礎設施已經(jīng)成熟——這意味著標準落地的工具鏈已經(jīng)就緒。

當企業(yè)開始將“指標定義”視為與“財務制度”同等重要的治理資產(chǎn)，當語義描述變成一種可交換、可審計、可版本管理的協(xié)議——我們就真正站在了智能決策的新起點上。

從 SQL 到 OSI，間隔了四十年。SQL 讓機器聽懂了人類的查詢指令，OSI 要讓機器理解人類的業(yè)務語言。

這一步，比上一步更難，也更值得。