大型科技公司語義層的祕密：Uber、Netflix 和 Airbnb 如何管理指標以及您如何在自己的公司中應用這些方法

過去幾年，數據界的每個人都在談論語義層。 

商業智能供應商將其作為一種便捷的指標模型進行銷售。現代數據架構稱之為指標層。人工智能團隊則聲稱，如果沒有它，就無法構建分析代理。但如果你仔細觀察一下主要科技公司（Uber、Netflix、Airbnb、LinkedIn、Spotify）的架構，就會發現它們的含義與「語義層」一詞通常所暗示的含義截然不同。 

他們來説，這不僅僅是 BI 工具內部的一層指標。它是數據平臺內的一個獨立基礎設施。一個管理業務指標定義、計算、數據質量、訪問控制以及這些指標在 BI、機器學習、產品甚至 AI 系統中的使用方式的平臺。 

尤其有趣的是，許多公司都曾在博客、研究論文和架構演講中部分透露過其架構信息。如果將這些零散的信息拼湊起來，就會呈現出一幅相當令人驚訝的圖景。本文將嘗試做到這一點。 

我們將收集大型科技公司 數據工程項目 資料中公開可用的證據，並重建語義層的真實架構。我們將研究 Uber 和 LinkedIn 的指標平臺是如何運作的，Netflix 為什麼構建 Metrics Repo，Airbnb 如何設計 Minerva，Spotify 為什麼在數據倉庫前面放置 API，以及語義層在人工智能系統中開始發揮什麼作用。 

最終結果將類似於一張地圖：語義層在大科技公司中實際是如何運作的，以及哪些原則可以應用於更典型的組織。或許最有趣的結論會出乎意料：在大型科技公司中，語義層根本不是 BI 功能，而是現代數據平臺的關鍵架構層之一。 

1. 大型企業的語義層架構

1.1 優步

指標平臺架構

Uber 構建了一個名為 uMetric 的集中式平臺，用於管理指標的整個生命周期：定義 、 發現 、 計算 、 質量驗證 和消費。 

實際上，這既是一個 語義層，也是一個指標平臺 。 

Uber 公開將其內部 uMetric 平臺描述為一個統一的指標平臺，涵蓋指標的整個生命周期：定義、發現、規劃、計算、質量和使用。 

此外，Uber明確表示，該平臺將指標擴展到 機器學習特徵 ，這意味着它不再僅僅是一個分析詞典，而是分析和機器學習之間的橋樑。 

2025年，Uber還介紹了其對話式數據代理 Finch 。它基於精心整理的單表數據集市和構建在元數據之上的語義層運行。Finch使用存儲在OpenSearch中的元數據、列別名和值，使LLM能夠生成更精確的WHERE篩選條件，並顯著減少錯誤。 

• 洞察力

在 Uber，語義層實際上已經成為 機器的控制平面 ，而不僅僅是分析師的控制平面。 

這里最有價值的證據是，他們的AI代理並沒有依賴於「LLM會自行推斷模式」的想法。相反，他們依賴於精心管理的數據集市、元數據別名和受控訪問權限。 

換句話説，真正基於數據構建的企業級人工智能並不依賴於原始SQL語句的生成，而是依賴於 預先構建的語義上下文 。 

• 系統核心理念

該系統的主要理念是消除不同團隊計算出的指標之間的差異。 

• 簡化架構

[事件流] → [數據管道] → [指標定義] → [指標計算引擎] → [質量驗證] → [指標 API] → [儀表盤/機器學習/應用] 

• 關鍵見解

Uber明確表示，其指標系統不僅用於分析，還用作 機器學習特徵平臺 。 

這實際上意味着： 語義層 = 機器學習的特徵層

1.2 Netflix

指標庫 — 指標即代碼

Netflix 構建了一個名為Metrics Repo 的 系統，這是一個集中式指標定義的框架。 

Netflix 在描述其實驗平臺時解釋説，Metrics Repo 是一個內部 Python 框架，用户可以在其中定義以編程方式生成的 SQL 查詢和指標定義。然后，系統會將這些定義集中管理。 

在Netflix最近發佈的一份關於其分析 項目 的概述中，該公司強調，內部指標的創建和使用「通常比應有的複雜得多」。換句話説，即使在Netflix這樣成熟的公司，指標定義不一致的問題也並未完全消失。 

此外，還有另一個重要的信號。在另一篇關於雲效率的文章中，Netflix 描述了一個 分析數據層 ，該數據層為金融 項目 用例提供時間序列效率分析。 

• 洞察力

Netflix 透露了一些鮮為人知的內幕： 

在大型公司中，語義層通常不是一個單一的通用系統。相反，它由 特定領域的指標庫和 針對特定用例的分析層組成——例如實驗、效率分析、創意分析等等。 

換句話説，真正的架構更接近於 聯邦語義治理， 而不是「一個語義層統治一切」的想法。 

這不是直接引語——而是根據 Netflix 對其各種指標框架和特定領域分析層的描述得出的結論。 

• 核心思想

指標是 通過程序 定義的，而不是在 BI 工具內部定義的。 

因此，指標計算從 ETL 管道中移出，更靠近分析師。 

• 簡化架構

[原始數據] → [數據倉庫] → [指標庫（代碼定義）] → [實驗平臺] → [統計引擎] → [儀表盤/決策系統] 

• 關鍵見解

指標庫不僅用於商業智能，而且主要用於： 

A/B 測試、產品實驗、因果推斷

Netflix關於其實驗平臺的研究論文證實了這一點。換句話説，Netflix的語義層是 科學實驗平臺 的一部分。 

1.3 LinkedIn

統一指標平臺

LinkedIn 構建了 統一指標平臺 (UMP) 。該平臺旨在解決的主要問題是：不同的團隊以不同的方式計算相同的指標。 

爲了解決這個問題，LinkedIn採取了集中化措施：度量定義 、 計算 和 服務 。 

• 簡化架構

[原始事件] → [Kafka] → [批處理 + 流處理] → [指標計算] → [指標存儲] → [指標 API] → [儀表盤/服務] 

• 關鍵見解

LinkedIn 將語義層轉化為一項 真正的服務 ，而不是 SQL 模型，而是一個 指標 API 。 

1.4 Spotify

實驗平臺內部的語義層

Spotify 構建了自己的實驗平臺。其架構大致如下： 

[產品事件] → [數據湖] → [指標定義] → [實驗引擎] → [統計分析] → [決策儀表盤] 

• 核心原則

指標必須具有 可復現性 。換句話説，每個實驗都必須基於 相同的指標定義 。 

1.5 Airbnb

Minerva——面向整個公司的語義層

Airbnb 開發了一個名為Minerva 的 系統。 

Airbnb明確指出，Minerva在其新的數據倉庫架構中扮演着核心角色。它負責攝取事實表和維度表，對數據進行反規範化處理，並通過API將其提供給下游應用程序。 

他們還揭示了該系統的規模：超過 12,000 項指標、 超過 4000個維度和 超過200 名來自不同公司職能部門的 數據生產者。

指標和維度定義存儲在 集中式 GitHub 存儲庫 中，並經過代碼審查、靜態驗證和測試運行。 

該系統支持： 

定義質量檢查、回填、版本控制 

成本歸因、GDPR選擇性刪除、訪問控制 

自動棄用策略、基於使用量的保留 

Airbnb 對其目標做了非常清晰的總結： 「一次定義，處處可用」。

• 洞察力

真正的「祕訣」不在於公式。Airbnb 的語義層既不是 用戶界面功能，也不是商業智能功能 ——它是一門工程學科。 

指標被視為代碼。 元數據是強制性的。 存在審查流程。 中間計算結果可以重用。 棄用和生命周期管理已正式化。 

換句話説，Minerva 不僅解決了「如何計算 KPI」的問題，還解決了「如何防止業務意義在數百個團隊中分散」的問題。 

Airbnb明確解釋説，僅僅標準化表格是不夠的。標準化必須 在指標層面 進行，因為用户使用的是指標、維度和報告，而不是表格。 

Minerva 管理：指標 、維度和 KPI計算 。 

• 核心思想

定義一次，即可處處使用

• 簡化架構

[數據倉庫] → [語義層（Minerva）] → [指標計算] → [指標 API] → [分析工具] 

Airbnb 還指出，它已將其 數據質量評分 擴展到 Minerva 指標和維度。 

這是一個至關重要的信號：除非指標具有 信任信號， 否則它不被視為一個完整的對象。 

• 洞察力

一個真正的企業語義層幾乎總是由三個組件構成： 

意義的定義 

計算機制 

信任/質量信號 

如果沒有第三個組成部分，它就僅僅是一個公式詞典，而不是企業級語義層。Airbnb的 Minerva + 數據質量評分 以及Uber uMetric 平臺中獨立的 質量支柱都清楚地支持了這一結論。

1.6 Pinterest

在最近一篇關於文本轉 SQL 的文章中，Pinterest 解釋説，在解析查詢之前，他們會用以下方式豐富上下文： 

表格和列描述

標準化術語

度量定義

數據質量注意事項

建議日期範圍

他們還解釋説，如果沒有這種上下文，LLM 就只能看到原始的表格和列，因此會失去數據的業務意義。 

Pinterest 還指出，這種上下文信息是通過以下方式自動維護的： 

人工智能生成的文檔

基於連接的詞匯表傳播

基於搜索的語義匹配

• 洞察力

這為一種新趨勢提供了強有力的證據。在人工智能時代，語義層不再僅僅是類似這樣的表達式：收入 = SUM(x) 

它還包括： 

字段的同義詞

數據質量注意事項

可接受的日期範圍

有效的連接路徑

這些正是傳統 BI 語義層產品中經常缺失的要素——儘管它們對於 文本到 SQL 系統和代理驅動的分析 至關重要。 

2. 大型科技公司語義層矩陣

3. 真實情況

當這些做法結合起來時，它們就形成了大型科技公司語義層的統一架構。 

[數據源] → [數據倉庫/湖屋] → [轉換層] → [指標定義（Git）] → [指標計算引擎] → [指標目錄] → [指標 API] → [BI / ML / 應用 / AI]

這代表了一個 完整的企業級語義層架構 。 

實際上，在一般公司內部複製這種架構並非易事。 

大多數組織已經具備：數據倉庫 、 轉型工具 和 BI儀表盤 。 

但它們通常缺乏將業務含義與底層數據結構連接起來 的語義建模層。

這正是 DataForge  這類工具的用武之地。DataForge並非將指標邏輯嵌入BI工具或SQL管道中，而是允許團隊設計一個集中式的語義模型 ， 該模型包含事實、維度和業務指標——有效地充當了本文所述的架構層。 

換句話説，它有助於實現 Uber、Airbnb 和 LinkedIn 等公司使用的相同原則——但形式上卻能讓普通的數據團隊輕松上手。 

4. 普通公司與大型科技公司的區別是什麼

5. 大型科技公司地圖：每家公司實際開發了什麼

該矩陣突出了一個關鍵觀察結果： 

大型科技公司並非總是明確使用「語義層」這個術語。然而，當它們發佈架構細節時，相同的組件卻反覆出現： 

度量定義

集中式計算

服務層/API

治理

數據質量

產品目錄

跨工具重用

6. 語義層的演進：2010 年 → 2026 年

第一階段：2010–2014 年 / 「指標實時反映在報告和流程中」

早期階段，各項指標分散在 ETL 管道、報表工具和各個團隊中。LinkedIn 明確指出，在 UMP 推出之前，報表系統 支離破碎、各自獨立且缺乏系統性 ，不同的利益相關者對同一指標的計算方式也各不相同。這與 2010 年代初期企業分析環境的典型狀況極為相似。 

第二階段：2015–2019 年 / 標準化和實驗

在這個階段，企業開始集中管理指標，主要目的是爲了支持 A/B測試和可靠的實驗 。2019年，Netflix推出了 Metrics Repo ，作為一種統一的指標定義方式，並支持以編程方式生成SQL。與此同時，LinkedIn已經擁有了 統一指標平臺（UMP），支持A/B測試和報告。在這個階段，語義層的出現並非源於商業智能工具，而是源於確保可復現性和一致性的 需求。 

第三階段：2020–2022 年 / 指標即代碼和服務層

2020 年至 2021 年間，Spotify、Uber 和 Airbnb 等公司開始公開展示下一階段的發展方向： 

代碼或 Git 中的度量定義

集中式指標生命周期管理

API 或服務層

治理

質量驗證

Spotify 在數據倉庫前端引入了 API。Uber 開發了全生命周期的 uMetric 平臺。Airbnb 發佈了關於 Minerva 及其 API 的詳細信息。至此，語義層不再僅僅是一個 BI 模型，而成為一個 獨立的平臺層 。 

第四階段：2023–2024 年 / 開放生態系統和可組合性

2024年，谷歌通過 開放SQL接口（Open SQL Interface） 和不斷壯大的連接器生態系統，向外部工具開放了Looker語義層。同期，Meta發佈了其關於 可組合數據管理 以及不同系統間語義不一致挑戰的研究成果。至此，語義層開始被視為更廣泛的 互操作性架構 的一部分。 

第五階段（2024-2026 年）/語義層作為人工智能上下文層

在2024年至2025年間，谷歌明確地將語義層與 Gemini、對話分析API和MCP 連接起來，並指出人工智能應該查詢語義層，而不是生成原始SQL語句。優步此前已經通過「指標和機器學習特徵即服務」的概念暗示了這一點 。 至此，語義層已不再僅僅是一個分析抽象層。 

它成為 人工智能代理的受控上下文層 。 

7. 「交叉圖」：哪些祕密是所有人都知道的

8. 要達到最高水平需要做些什麼

目標不是 「購買語義層」 ，而是逐步完成六個成熟階段。 

第一級——杜絕混亂： 關鍵KPI不應再以Excel表格、BI計算字段或臨時SQL語句作為主要數據源。LinkedIn和Uber的案例明確表明，他們構建平臺的主要原因就是爲了解決團隊間指標重複和不一致的問題。 

第二級——一次性定義： 將指標定義移至集中式 規範/代碼層 。這可以通過以下方式實現：DataForge、YAML、DSL、dbt 元數據、LookML 風格的建模層、內部存儲庫 。 

Uber、Airbnb、Netflix 和 Google 正是這樣管理指標的。 

第三級——一次計算： 指標必須 在所有地方以相同的方式 計算：儀表盤、實驗系統、臨時分析、應用程序。這種模式在 LinkedIn 的 UMP 、Uber 的 uMetric 和 Spotify 的 指標目錄 中都有明顯的體現。 

第四級——無處不在：僅僅 維護一個指標定義庫是不夠的。您還需要一個 服務層 ，例如：API、查詢層、開放SQL接口、語義端點 。 

這種模式在Spotify、Airbnb 和 Google 的架構中都有明顯的體現。 

第五級——增強信任： 如果沒有質量檢查、驗證、所有權和審查流程，語義層就無法達到企業級成熟度。Airbnb 的 數據質量評分 、Uber 的 指標級質量檢查 以及 Stripe 的 數據質量平臺 都表明， 信任並非可有可無，而是成熟架構的基本組成部分 。 

第六級——將人工智能應用於語義層： 下一個最高級別的步驟是將語義層用作 人工智能和分析代理的上下文 。目前，最清晰的公開示例來自谷歌，它整合了以下技術：Looker、雙子座、對話分析 API、MCP。 

9.要邁向大型科技公司水平，需要做些什麼

步驟 1

實現 指標即代碼

示例：指標：收入，定義：訂單金額之和，維度：國家/地區，所有者：財務 

步驟 2

創建統一指標目錄。該目錄應包含：公式 、 描述 、 所有者 、 血統 和 質量檢查 。 

步驟 3

集中式指標計算。一個指標應該只計算 一次 。 

不是指：在 BI 工具中、在 SQL 查詢中、在 Excel 中。 

第四步

構建指標 API，以便以下用户可以使用指標：BI系統、機器學習管道、應用程序 。 

第五步

增加治理要素。每項指標都應包含以下內容：所有者、描述、驗證測試 。 

10. 小結

那麼，最「隱祕」的見解是什麼——即便它已被公開記錄？最被低估的結論是： 

領先的技術公司不會將語義層構建成BI之上的一個薄層。

他們將其打造為一款 用於管理業務的產品 ，其含義包括： 

• 代碼
• 評論
• 所有權
• 血統
• 質量
• 訪問控制
• 回填
• 棄用政策
• API 和代理消費

這種模式在Airbnb、Uber、Netflix 和 Pinterest 的架構中都能同時觀察到。如果你仔細研究 Uber、Netflix、LinkedIn、Airbnb 和 Spotify 的架構，你會發現一個顯而易見的事實： 

語義層 不是一種工具 。 

它是 業務指標的操作系統 。 

這就是大型科技公司將其構建成這樣的原因： 

• 一個平臺
• 一項服務
• API
• 治理層

大型科技公司並沒有將語義層構建成一個完善的商業智能功能。 

大型科技公司將語義層構建為 定義、計算、服務、信任以及現在的 AI 基礎架構的平臺層 。 

並非所有公司都會公開展示單一的統一語義層。 

但在任何一家頂尖公司里， 這一層級的組織機構都是顯而易見的 ： 

• 產品目錄
• 度量定義
• 服務 API
• 質量層
• 語義互操作性
• 實驗重複使用

這也是數據工具生態系統的發展方向。 

一種新的平臺類別正在興起，它不再將語義層視為 BI 工具內部的功能，而是將語義層視為數據平臺的 一流架構組件。

大多數 BI 語義層實際上就是 數據模型 。大型科技公司的語義層是 指標基礎設施 。 

本文來自微信公眾號 「數據驅動智能」（ID：Data_0101），作者：曉曉，36氪經授權發佈。