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

作者 | 周衛林，Aloudata 創始人 & CEO

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

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

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

1 先講一段老故事：SQL 是怎么統一世界的

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

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

回頭看，SQL 標準化給我們三個啟示：

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

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

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

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

2 OSI：讓“數據是什么意思”標準化

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

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

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

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

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

這就是 OSI 要解決的問題。

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

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

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

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

3 全球數據廠商：殊途同歸的語義層布局

OSI 的發布不是憑空出現的。過去兩年，整個數據技術棧都在向語義層聚攏，只是路徑不同。

BI 平臺在重構語義內核。 Salesforce 旗下的 Tableau 推出 Tableau Next，內置 Tableau Semantics 模塊——官方定義為“AI-infused semantic layer”，明確為 AI Agent 提供統一的業務術語，并推出了 Data Pro、Concierge、Inspector 三個內置 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 中將“數據集（Dataset）”正式更名為“語義模型（Semantic Model）”，強調它是業務知識的載體而非單純的數據容器（見 Power BI Blog Datasets renamed to semantic models）。

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

現代數據棧在推動語義中立。 dbt Labs 2025 年 10 月宣布將 MetricFlow 完全開源（Apache 2.0），作為對 OSI 標準的直接承諾，推動指標定義的標準化和可移植——MetricFlow 的 YAML 格式也是 OSI 規范的底層標準之一（見 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 供各類系統調用（見 Cube Blog Named Leader in 2025 GigaOm Radar）。

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

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

4 對中國企業意味著什么

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

關系很大。

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

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

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

5 OSI 之后，真正的挑戰才開始

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

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

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

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

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

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

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

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

6 站在標準化的起點上

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

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

但有幾件事是確定的：

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

現代數據生態的開放程度，遠高于四十年前的封閉競爭時代——這意味著標準推進的阻力更小。

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

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

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

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

延伸閱讀：了解 OSI

如果你想深入了解 OSI 標準，以下是一些關鍵資源：

OSI 官方資源

• OSI 規范倉庫（GitHub）：github.com/open-semantic-interchange/OSI

• OSI 官網：open-semantic-interchange.org

廠商視角的解讀

• Snowflake：“Open Semantic Interchange's Specs Finalized”（snowflake.com/blog）

• Salesforce / Tableau：“The Agentic Future Demands an Open Semantic Layer”（salesforce.com/blog）

• dbt Labs：“What the OSI Spec Means for Metrics, Semantics, and AI”（getdbt.com/blog）

• dbt Labs：“dbt Labs Affirms Commitment to OSI by Open Sourcing MetricFlow”（getdbt.com/blog）

各平臺語義層產品

• Snowflake Native Semantic Views：docs.snowflake.com/en/user-guide/views-semantic/overview

• Databricks Unity Catalog Metrics：docs.databricks.com/en/metric-views

• Tableau Semantics & Tableau Next：tableau.com/products/tableau-next

• Looker LookML 語義層：cloud.google.com/looker-modeling

• Power BI Semantic Model：learn.microsoft.com/en-us/power-bi/connect-data/service-datasets-rename

• Cube.dev 語義層平臺：cube.dev/use-cases/semantic-layer

• dbt MetricFlow（開源）：github.com/dbt-labs/metricflow