語義層（Semantic Layer）

3 秒看懂

語義層是位於原始資料與業務消費之間的”翻譯層”，將資料庫表結構、欄位含義、業務邏輯封裝為統一的業務語義模型，讓非技術使用者能用”營收""毛利""月活”等業務術語直接查詢資料，無需瞭解底層 SQL 或表關聯關係。

一句話：語義層 = 資料世界的”中間翻譯官”，左邊對接複雜資料來源，右邊輸出業務可理解的指標。

3 分鐘產業解釋

為什麼需要語義層？

在沒有語義層的傳統架構中，存在一個反覆出現的問題：

角色	痛點
業務分析師	問”上月營收多少”，需要知道在哪張表、用哪個欄位、什麼口徑計算
資料工程師	同一指標被不同團隊用不同 SQL 寫出來，口徑不一致，資料”打架”
BI 工具	每換一個工具就要重新建模，語義不統一
AI/LLM 應用	大型模型要查企業資料，無法直接理解”哪些表、什麼關係、怎麼算”

語義層的核心價值：

┌─────────────────────────────────────────────────┐
│                  業務消費層                       │
│   BI報表 / 自助查詢 / AI助手 / API服務           │
└──────────────────────┬──────────────────────────┘
                       │  "上月營收多少？"
                       ▼
┌─────────────────────────────────────────────────┐
│              ★ 語義層 (Semantic Layer) ★          │
│  • 統一指標定義：營收 = SUM(order.amount)         │
│  • 維度定義：時間、區域、產品線                    │
│  • 業務邏輯：退款已排除、匯率已折算                │
└──────────────────────┬──────────────────────────┘
                       │  生成標準化查詢
                       ▼
┌─────────────────────────────────────────────────┐
│                   資料儲存層                      │
│   資料倉儲 / 資料湖 / 各業務資料庫               │
└─────────────────────────────────────────────────┘

產業位置

語義層處於資料基礎設施與資料應用的交界處，是現代資料棧（Modern Data Stack）中承上啟下的關鍵環節。

15 分鐘專家深入

演進路徑與產業格局

第一代：BI 工具內嵌語義層（約 2000-2015 年）

代表：Business Objects Universe、Cognos Framework Manager、Tableau 資料來源
特點：語義定義繫結在特定 BI 工具內，遷移成本高，跨工具無法複用
問題：廠商鎖定嚴重

第二代：獨立語義層平台（約 2015-2020 年）

代表：AtScale、Kyvos
特點：從 BI 工具中獨立出來，支援多消費端
進步：語義定義可跨 BI 工具複用，但仍偏向傳統 OLAP 場景

第三代：Metrics Layer / Headless BI（約 2020 年至今）

代表：dbt Semantic Layer（原 MetricFlow）、Cube（Cube.js）、Metriql、Minerva（Airbnb 內部）
特點：
- 與現代資料棧深度整合（dbt + Snowflake/Databricks/BigQuery）
- API-first，語義層暴露標準化查詢 API，任何消費端可呼叫
- 支援”指標即程式碼”（Metrics as Code），版本控制、CI/CD 友好

第四代：AI-Native 語義層（當前前沿）

特點：語義層不僅服務於 BI，更成為 LLM 訪問企業資料的”橋樑”
典型場景：Text-to-SQL + 語義層上下文 → 提高 LLM 查詢準確率
思路：將語義層的後設資料（表關係、欄位含義、指標口徑）作為 RAG 的知識庫，注入 LLM 上下文

核心概念解析

1. 維度（Dimension）與度量（Measure）

概念	含義	示例
維度（Dimension）	分析的”視角”或”切面”	時間、地區、產品類別、客戶型別
度量（Measure）	可被聚合計算的數值	營收、訂單數、使用者數、平均客單價
指標（Metric）	度量 + 維度約束 + 時間粒徑	”2024年Q1 華東區營收”

2. 語義層的核心能力

┌─────────────────────────────────────────────────────────────┐
│                    語義層核心能力矩陣                        │
├─────────────────┬───────────────────────────────────────────┤
│ 能力            │ 說明                                       │
├─────────────────┼───────────────────────────────────────────┤
│ 指標定義        │ 統一業務口徑，"一個指標一個定義"           │
│ 關係建模        │ 定義表間 join 關係，消費端無需手動寫 join   │
│ 維度層級        │ 時間：年→季→月→日；地域：國家→省→市       │
│ 訪問控制        │ 行級/列級權限，不同角色看到不同資料         │
│ 快取策略        │ 對高頻查詢結果快取，加速響應               │
│ 多源聯邦        │ 跨不同資料來源（倉庫+湖+資料庫）統一查詢     │
└─────────────────┴───────────────────────────────────────────┘

3. dbt Semantic Layer 的技術實現思路（基於公開文件）

# dbt metrics YAML 定義示例（概念性）
metrics:
  - name: revenue
    label: 營收
    type: simple
    type_params:
      measure:
        name: total_amount
        filter: |
          &#123;&#123; Dimension('order__status') }} != 'cancelled'
    dimensions:
      - order__order_date__month
      - customer__region

工作流程：

使用者/應用請求 "按月看華東區營收"
        │
        ▼
┌─────────────────────┐
│ Semantic Layer API   │  解析請求，匹配指標定義
│ (MetricFlow引擎)     │
└─────────┬───────────┘
          │ 生成最佳化後的 SQL
          ▼
┌─────────────────────┐
│ 資料倉儲執行         │  Snowflake / BigQuery / Databricks
└─────────┬───────────┘
          │ 返回結果
          ▼
┌─────────────────────┐
│ 格式化返回消費端     │
└─────────────────────┘

技術原理（深入機制）

語義模型的內部結構

語義層的核心是一個後設資料圖（Metadata Graph），描述了資料實體之間的關係：

┌─────────────────────────────────────────────────────────────────┐
│                       語義模型後設資料圖                           │
│                                                                 │
│   ┌──────────┐    has_many    ┌──────────┐                      │
│   │ Customer │───────────────→│  Order   │                      │
│   │          │                │          │                      │
│   │ PK: id   │                │ PK: id   │                      │
│   │ dim:     │                │ FK: cust │                      │
│   │  region  │                │ measure: │                      │
│   │  tier    │                │  amount  │                      │
│   └──────────┘                │  qty     │                      │
│        │                      └────┬─────┘                      │
│        │                           │ has_many                    │
│        │                           ▼                             │
│        │                      ┌──────────┐                      │
│        │                      │OrderItem │                      │
│        │                      │          │                      │
│        │                      │ FK: order│                      │
│        │                      │ FK: prod │                      │
│        │                      │ measure: │                      │
│        │                      │  line_   │                      │
│        │                      │  amount  │                      │
│        │                      └────┬─────┘                      │
│        │                           │                             │
│        └───────────────────────────┼──────────────────────┐      │
│                                    ▼                      │      │
│                               ┌──────────┐                │      │
│                               │ Product  │                │      │
│                               │          │                │      │
│                               │ PK: id   │                │      │
│                               │ dim:     │                │      │
│                               │  category│                │      │
│                               │  brand   │                │      │
│                               └──────────┘                │      │
│                                                           │      │
│   ┌───────────────────────────────────────────────────────┘      │
│   │  時間維度 (Time Spine)                                       │
│   │  ┌────────────────────────────────────────────┐              │
│   │  │ date_day ← date_week ← date_month ← date_year            │
│   │  └────────────────────────────────────────────┘              │
│   └───────────────────────────────────────────────────────────── │
└─────────────────────────────────────────────────────────────────┘

查詢生成機制

當消費端發起請求時，語義層執行以下步驟：

步驟1: 解析語義請求
─────────────────────────────────────────────────
輸入: { metric: "revenue",
        dimensions: ["month", "region"],
        filters: ["region = '華東'"],
        time_range: "2024-Q1" }

步驟2: 遍歷後設資料圖，確定所需實體
─────────────────────────────────────────────────
→ 需要 Order 表（revenue metric 定義於此）
→ 需要 Customer 表（region 維度定義於此）
→ 需要 join Customer → Order

步驟3: 生成查詢（或 SQL）
─────────────────────────────────────────────────
生成邏輯:
  SELECT
    DATE_TRUNC('month', o.order_date) AS month,
    c.region,
    SUM(o.amount) AS revenue
  FROM orders o
  JOIN customers c ON o.customer_id = c.id
  WHERE c.region = '華東'
    AND o.order_date >= '2024-01-01'
    AND o.order_date < '2024-04-01'
    AND o.status != 'cancelled'
  GROUP BY 1, 2

步驟4: 查詢最佳化與快取判斷
─────────────────────────────────────────────────
→ 檢查是否有預計算的聚合快取
→ 檢查是否可下推到資料來源原生聚合引擎
→ 確定最終執行計劃

步驟5: 執行並返回
─────────────────────────────────────────────────
→ 傳送到資料倉儲執行
→ 結果格式化後返回消費端

語義層與 LLM 的結合機制（前沿方向）

┌────────────────────────────────────────────────────────────────┐
│              LLM + 語義層整合架構                               │
│                                                                │
│  使用者自然語言: "上個月華東區營收年增率怎麼樣？"                    │
│                    │                                           │
│                    ▼                                           │
│  ┌──────────────────────────────────────────┐                  │
│  │ LLM / AI Agent                           │                  │
│  │                                          │                  │
│  │ 上下文注入:                              │                  │
│  │  • 可用指標列表及其定義                  │                  │
│  │  • 維度列表及層級關係                    │                  │
│  │  • 表間關係圖譜                          │                  │
│  │  • 業務術語對映表                        │                  │
│  └──────────────┬───────────────────────────┘                  │
│                 │ 輸出結構化語義請求                            │
│                 ▼                                               │
│  ┌──────────────────────────────────────────┐                  │
│  │ 語義層 API                               │                  │
│  │  請求: {                                 │                  │
│  │    metric: "revenue",                    │                  │
│  │    dimensions: ["region"],               │                  │
│  │    compare: "yoy",                       │                  │
│  │    time: "2024-03"                       │                  │
│  │  }                                       │                  │
│  └──────────────┬───────────────────────────┘                  │
│                 │                                               │
│                 ▼                                               │
│  ┌──────────────────────────────────────────┐                  │
│  │ 資料倉儲                                 │                  │
│  └──────────────┬───────────────────────────┘                  │
│                 │                                               │
│                 ▼                                               │
│  LLM 組織自然語言回答: "華東區3月營收XX萬，年增率增長X%..."        │
└────────────────────────────────────────────────────────────────┘

關鍵優勢：LLM 不需要知道底層表結構和 SQL 語法，只需要輸出”請求哪個指標、用什麼維度篩選”這樣的語義化請求，語義層負責翻譯為正確可執行的查詢。這大幅降低了 LLM 生成 SQL 出錯的機率。

技術演進史

時期	階段	代表	核心特徵
2000s	BI Universe 時代	BO Universe、Cognos FM	繫結單一 BI 工具，GUI 建模
2010s	OLAP 引擎內嵌	SSAS、Oracle OBIEE	多維立方體，預計算聚合
2015-2018	獨立語義平台	AtScale	解耦 BI 工具，開始 API 化
2019-2021	Metrics Layer 概念興起	Airbnb Minerva、dbt Labs（內部）	“指標即程式碼”，與現代資料棧整合
2021-2023	Headless BI / 開源浪潮	Cube.js、dbt Semantic Layer 公開發布、Metriql	API-first，支援多引擎多消費端
2023-現在	AI-Native 語義層	與 LLM/RAG 架構整合	為 AI 提供結構化上下文，降低幻覺

技術路線對比

語義層技術方案對比

維度	傳統 BI 內嵌	獨立語義層平台	Metrics Layer (dbt/Cube)	LLM 直接 Text-to-SQL（無語義層）
口徑一致性	低（各 BI 各自定義）	中	高（單一定義源）	低（每次 LLM 生成可能不同）
跨工具複用	無	有	有（API-first）	N/A
與資料棧整合	弱	中	強（原生整合 dbt/倉庫）	弱（需單獨準備後設資料）
LLM 友好度	低	中	高（結構化後設資料可用）	中（依賴 Prompt 工程）
部署複雜度	低（已有工具附帶）	中高	中（需初始化模型定義）	低
查詢效能最佳化	強（預計算）	強	中（依賴倉庫能力）	弱
典型場景	單一 BI 場景	企業級 BI	現代資料團隊	AI 原型/探索

上下游

上游（資料輸入）

┌─────────────────────────────────────────────────────────────────┐
│                         上游資料來源                               │
├─────────────────┬───────────────────────────────────────────────┤
│ 類別            │ 說明                                          │
├─────────────────┼───────────────────────────────────────────────┤
│ 資料倉儲        │ Snowflake, BigQuery, Redshift, Databricks     │
│ 資料湖          │ Delta Lake, Iceberg, Hudi 表                  │
│ OLAP 引擎       │ ClickHouse, Druid, StarRocks                 │
│ 業務資料庫      │ MySQL, PostgreSQL（通過 CDC/ETL 同步）        │
│ SaaS 資料       │ Salesforce, HubSpot, Google Analytics 等     │
├─────────────────┼───────────────────────────────────────────────┤
│ 後設資料層        │ dbt model、資料目錄（DataHub, Atlan）        │
└─────────────────┴───────────────────────────────────────────────┘

下游（消費端）

┌─────────────────────────────────────────────────────────────────┐
│                         下游消費端                               │
├─────────────────┬───────────────────────────────────────────────┤
│ 類別            │ 代表                                          │
├─────────────────┼───────────────────────────────────────────────┤
│ BI / 視覺化     │ Tableau, Looker, Power BI, Superset, Metabase │
│ 自助分析        │ ThoughtSpot, Sigma Computing                  │
│ 嵌入式分析      │ 產品內嵌的分析模組                            │
│ AI 應用        │ LLM 助手、AI Agent、ChatBI                    │
│ 資料 API        │ 面向應用的 REST/GraphQL 資料介面              │
│ 資料應用        │ 運營儀表板、即時告警                            │
└─────────────────┴───────────────────────────────────────────────┘

關鍵指標

評估語義層的關鍵維度

指標	說明	重要性
查詢延遲	從語義請求到返回結果的時間（含 SQL 生成+執行）	高
SQL 生成準確率	生成的 SQL 與預期語義一致的比例	極高（影響資料可信度）
指標覆蓋率	已建模指標占業務常用指標的比例	高
消費端接入數	有多少 BI 工具/應用通過語義層查詢	中
快取命中率	使用快取的查詢佔比	中（影響效能）
口徑一致性指標	同一指標在不同報表中數值一致的百分比	極高（核心價值）
模型維護成本	新增/修改指標定義的人力與時間成本	高

供需與市場資料

市場格局（定性觀察）

⚠️ 注意：以下為基於公開資訊的定性判斷，具體市場規模數字未有權威統一口徑，不編造具體金額。

需求端驅動因素：

資料消費民主化：業務人員自助分析需求增長，降低 SQL 門檻
指標口徑治理：企業資料團隊從”煙囪式”指標開發轉向集中治理
AI 應用落地：LLM 需要結構化的企業資料上下文，語義層成為關鍵基礎設施
現代資料棧普及：dbt 生態擴張帶動語義層需求

供給端格局：

類別	代表廠商/專案	狀態
商業 SaaS	AtScale, Cube Cloud, Looker (Google)	成熟
開源 + 商業化	dbt Semantic Layer, Cube.js (開源)	快速增長
雲端廠商內嵌	Databricks（Unity Catalog）、Snowflake（Semantic Views，探索中）	發展中
資料目錄廠商延伸	Atlan, Alation（擴充套件語義能力）	早期
AI-native 方案	各 Text-to-SQL 架構內嵌語義上下文	早期探索

行業採用率：據定性觀察，大型企業中語義層的正式採用率仍處於早期階段，但 dbt 生態中的指標定義實踐正在快速普及。

代表公司與資本對映

公司/專案	定位	融資/狀態	與語義層的關係
dbt Labs	資料轉換與建模平台	已融資數億美元

三步設好你的觀察臺

選 1-3 個想觀察的人或賽道

看一份樣張

設定一次異動告警

語義層

語義層（Semantic Layer）

3 秒看懂

3 分鐘產業解釋

為什麼需要語義層？

產業位置

15 分鐘專家深入

演進路徑與產業格局

核心概念解析

技術原理（深入機制）

語義模型的內部結構

查詢生成機制

語義層與 LLM 的結合機制（前沿方向）

技術演進史

技術路線對比

語義層技術方案對比

上下游

上游（資料輸入）

下游（消費端）

關鍵指標

評估語義層的關鍵維度

供需與市場資料

市場格局（定性觀察）

代表公司與資本對映

語義層（Semantic Layer）

3 秒看懂

3 分鐘產業解釋

為什麼需要語義層？

產業位置

15 分鐘專家深入

演進路徑與產業格局

核心概念解析

技術原理（深入機制）

語義模型的內部結構

查詢生成機制

語義層與 LLM 的結合機制（前沿方向）

技術演進史

技術路線對比

語義層技術方案對比

上下游

上游（資料輸入）

下游（消費端）

關鍵指標

評估語義層的關鍵維度

供需與市場資料

市場格局（定性觀察）

代表公司與資本對映

相關推薦

同產業鏈 · 相關公司

相關概念