语义数据层——技术雷达
概述
语义层（semantic layer）是一种数据架构技术，在原始数据存储与消费端应用（BI 工具、AI 智能体、API）之间引入一个共享的业务逻辑层，集中管理指标定义、连接（join）、访问规则与业务术语。dbt Labs 将其描述为一种统一、贴近业务的数据表示，充当供 BI 工具、LLM 及其他端点消费的指标与维度 API。AtScale 与 Databricks 同样把语义层视为介于数仓/湖仓与分析/AI 工具之间、面向指标与维度的「唯一事实来源」。Thoughtworks 的技术雷达（Technology Radar）将「Semantic layer」置于其技术（Techniques）象限，建议团队从小处入手，并关注正在兴起的互换标准。
本页针对语义数据层领域本身套用 Thoughtworks 风格的雷达（象限 × 环）——既覆盖超大规模云/数据云原生能力（Snowflake、Databricks、Microsoft Fabric/Power BI、AWS QuickSight、Google Looker），也覆盖与之竞争或互补的通用/代码优先语义层产品（dbt Semantic Layer、Cube、AtScale、Denodo、Honeydew 等）。它与智能体 AI 相关，是因为语义层正日益成为受治理、具业务含义的查询界面：LLM 智能体（text-to-SQL、自然语言 BI、基于 MCP 的数据智能体）越来越倾向消费该界面，而非直接查询原始 schema。
三种架构模式
当今语义层大致可分为三类模式：
| 模式 | 描述 | 示例 |
|---|---|---|
| 数仓/湖仓原生语义对象 | 语义定义作为一等对象存储于数据平台自身内部 | Snowflake Semantic Views、Databricks Metric Views |
| BI 原生语义模型 | 内建于 BI 工具、作用域限于该工具消费方的语义建模层 | Power BI 语义模型、Looker（LookML）、AWS QuickSight Topics |
| 通用/独立语义层平台 | 跨工具的语义引擎，通过 SQL/REST/GraphQL/XMLA 向任意消费方暴露指标 | dbt Semantic Layer（MetricFlow）、Cube Core、AtScale、Denodo |
雷达模型
本雷达把 Thoughtworks 通用象限重构为四个针对本领域的象限，并保留经典的三个环（省略 Hold，因为此处无条目需归入其中）：
象限：
- 云数据平台 —— 内建于超大规模云/数据云平台的语义功能
- BI 与分析语义 —— BI 工具原生的语义模型
- 通用语义层与指标存储 —— 独立、跨工具的语义引擎
- 语义知识栈 —— 支撑更丰富语义的知识图谱/本体（ontology）工具
环：
- 🟢 采用（Adopt） —— 已在生产环境中得到验证；在其细分领域是默认选择
- 🔵 试用（Trial） —— 有前景且已可用于生产；可在聚焦的领域采用
- 🟡 评估（Assess） —— 新兴技术；值得关注、可做 POC，但应控制影响范围
编者按。下文的环位置带有观点性，基于截至 2026 年年中的 GA/预览状态与生态信号——它们并非 Thoughtworks 雷达的官方条目（Thoughtworks 自身的雷达在「技术」中只有一个通用的「Semantic layer」点，而非按厂商逐一定位）。
技术雷达
为避免标签拥挤，方案被拆分到两张图表中。两图共用同一 x 轴（环位置：评估 → 试用/采用），y 轴各图不同。
如何解读： - 右侧（x > 0.5）= 试用/采用 —— 已可用于生产，更强的默认候选 - 左侧（x < 0.5）= 评估 —— 视情况而定、面向利基场景，或仍在成熟中
图表 1 —— 云数据平台原生与 BI 语义层
Y 轴：BI 工具作用域（下）→ 数仓/湖仓原生（上）
图表 2 —— 通用语义层与指标存储
Y 轴：领域专用（下）→ 通用/企业级全域（上）
云数据平台原生语义层
Snowflake —— Semantic Views
环：试用→采用 · 象限：云数据平台
Snowflake Semantic Views 将具业务含义的概念（实体、指标、维度、关系）作为 schema 级对象存储，可通过 SQL 与 Cortex Analyst 自然语言 API 查询。它们充当从 AI/BI 消费方通往原始数据的受治理桥梁。Snowflake 还发起了 Open Semantic Interchange（OSI）倡议——一个厂商中立、基于 YAML 的语义模型规范，配有面向 Apache 开源项目的映射模块，并不断扩充合作伙伴阵容。GA 特性叠加强劲的生态势头，使其对多数组织处于试用阶段；在 Snowflake 已作为企业数据主干的场景下则趋向采用。可定义领域语义视图（Customer、Orders、Revenue），并通过语义 SQL 将其暴露给 Cortex Analyst 与 BI。
Databricks —— Metric Views 与 Unity Catalog 业务语义
环：试用 · 象限：云数据平台
Databricks Metric Views 是 Unity Catalog 中的一等语义层对象，用 YAML 定义受治理、可复用的业务指标与维度——度量、维度、关系、显示名、格式、同义词——并通过 SQL、仪表盘与 AI notebook 消费。Unity Catalog 业务语义现已 GA，其核心实现已开源进 Apache Spark，以将语义能力扩展到单一平台之外。虽已 GA，但企业采用尚处早期；对以湖仓为中心的组织契合度高。建议从少量高价值指标起步，在 Unity Catalog 中清晰组织 metric view，并在弃用遗留的「一张大表」设计前先验证输出。
Microsoft —— Power BI 语义模型与 Fabric OneLake 集成
环：采用 · 象限：BI 与分析语义 / 云数据平台
Power BI 语义模型提供成熟的表格式、内存内语义层（维度、度量、关系、行级安全）。借助 Microsoft Fabric 与 OneLake，导入的语义模型数据会自动作为 Delta 表写出到 OneLake，且 Direct Lake 模式支持直接在 OneLake 湖仓/数仓上构建语义模型，包括跨多个 Fabric 数据源的多制品（multi-artifact）模型。技术成熟、在企业 BI 中广泛部署，现已与 Fabric 数据平台集成。可将 Power BI 语义模型用作「BI 语义界面」，并逐步使指标定义与数仓层语义（例如 dbt Semantic Layer 或 OSI 对齐的模型）保持一致。另见 Microsoft Fabric IQ，它在此语义基座之上构建了面向智能体的共享上下文层。
AWS —— QuickSight Topics 与 Amazon Q in QuickSight
环：评估→试用 · 象限：BI 与分析语义
AWS QuickSight 的 Topics 功能被明确描述为架于数据之上的语义层：用终端用户语言定义业务术语与指标，添加友好名称/描述/同义词，指定字段角色（度量还是维度）、默认聚合、语义类型（货币、百分比、地点、人物、组织）及取值格式。Amazon Q in QuickSight（生成式 BI）利用这些定义提供自然语言问答。对以 AWS 为中心的 BI 功能完备，但「平台级」程度不及 Semantic Views 或 Metric Views。对已投入 QuickSight 的团队，适合用 Amazon Q 试点语义感知的生成式 BI；作为跨工具语义引擎则较为受限。
Google Cloud —— Looker 语义层（LookML）
环：采用 · 象限：BI 与分析语义
Looker 的语义层通过 LookML 将维度、度量、连接与逻辑定义为业务指标的唯一事实来源，供 Looker 及其他工具跨端消费——其定位明确是为 AI 与分析提供一致的参考定义作为事实依据。Google 也是 OSI 参与方，正推动可跨平台的开放、可互换语义模型规范。稳定、应用广泛、语义建模表达力强。可将 LookML 作为分析的核心语义层，并在需要超越 Looker/GCP 的语义可移植性时规划最终的 OSI 对齐。
通用/独立语义层与指标存储
dbt Semantic Layer（MetricFlow）
环：试用 · 象限：通用语义层
dbt Semantic Layer 由 MetricFlow（收购 Transform 后引入）驱动，是业务团队与数据团队之间的翻译层：指标在 YAML 中集中编码、在 Git 中做版本控制，并通过枢纽辐射式（hub-and-spoke）架构以数据 API 的形式暴露给多个端点（BI 工具、API、LLM）。dbt 是 OSI 的核心参与方；实践者反馈曾用它驱动 MCP 风格的智能体服务器。对 dbt 已成熟的团队可用于生产；与新兴的 OSI 标准高度对齐。建议从单一业务领域（例如营收）起步，以免过度建模。
Cube Core / Cube Cloud
环：试用→采用 · 象限：通用语义层
Cube Core 是一个开源、独立的语义层，只需在代码中一次性定义指标、维度、连接与访问规则，即可通过 SQL、REST 与 GraphQL 暴露给 BI 工具、自定义应用与 AI 智能体——它作为数据的集中控制面板，统一管理数据建模、访问、缓存与预聚合。Cube Cloud 为企业级使用增加了可观测性、合规、开发者工具与预聚合管理，常构建于 AWS、Snowflake 等平台之上。在面向 API 的分析栈中应用广泛。尤其适合为 AI 智能体、嵌入式分析与多个 BI 工具供给语义 API，而无需为每个工具重复建模。
AtScale —— Universal Semantic Layer
环：采用 · 象限：通用语义层
AtScale 在各云数据平台（Snowflake、Databricks、BigQuery）之上提供受治理的业务逻辑与多维分析，集中管理指标定义与业务术语，并通过标准接口（XMLA、JDBC、REST）暴露，从而在 Power BI、Tableau、Excel、Python notebook 与 AI 智能体之间保持指标一致。AtScale 已加入 OSI，将十年的语义层经验带入厂商中立的标准工作。企业级、经过验证、多工具互操作性强——对于希望获得集中治理及多云/多 BI 语义、又不想自建语义 API 的大型组织，是默认选择。
Denodo —— Universal Semantic Layer（数据虚拟化）
环：试用 · 象限：语义知识栈 / 通用层
Denodo 的 Universal Semantic Layer 构建于其数据虚拟化平台之上，在不同数据源与工具中互不连通的定义之间集中并协调语义，强调「AI 就绪」的数据语义，使元数据与业务术语对齐，服务于业务用户、分析工具、应用与 AI 智能体。Denodo 也是 Snowflake OSI 生态的一部分。对以虚拟化为中心的架构契合度高；但在典型的以现代数仓为中心的栈中，相较 dbt/Cube/AtScale 仍属利基。最具吸引力的场景是：语义须跨异构数据源，而无需将所有数据集中进单一数仓/湖仓。
Honeydew —— 面向 AI+BI 的语义层
环：评估→试用 · 象限：通用语义层
Honeydew 在意图上与 Snowflake Semantic Views 类似，但作用域是组织级而非按 schema，它在 Snowflake 之上打造业务逻辑的单一集散地，为多样化工作负载提供多个数据模型/语义视图，聚焦语义一致的 AI 与 BI 体验。相较 dbt/Cube/AtScale 还较为年轻；建议在单一 AI 密集领域试点，以验证其相较直接使用 Snowflake Semantic Views 的收益，尤其适合已投入 Snowflake、以 AI 为先的团队。
Bright Analytics —— 营销语义层
环：评估 · 象限：通用语义层
Bright Analytics 提供面向营销领域的语义层，可在不迁移数据的情况下连接多家云厂商与数据库（AWS、GCP、Azure、Snowflake、Redshift、RDS、BigQuery、Azure SQL），将各不相同的数据源协调进一个中心模型以实现统一报表。它偏领域专用，强调多源连通与协调，而非通用的企业级语义。当营销技术栈零散、需要快速统一又不想启动更宏大的语义计划时，它很有用。
语义知识栈
在以指标为中心的语义层之外，Thoughtworks 将语义层与向量检索（vector search）和知识图谱（knowledge graph）并列，视为让组织数据可被有意义地访问的技术。知识图谱与本体平台构成一个相关象限，在需要把语义从表格式指标扩展到对非结构化内容进行实体—关系推理时尤为重要：
| 工具 | 环 | 说明 |
|---|---|---|
| OntoText | 评估→试用 | 具备丰富语义建模能力的知识图谱平台 |
| PoolParty | 评估→试用 | 分类法/本体管理与语义检索 |
| Sinequa | 评估→试用 | 带语义增强的企业级检索 |
| Semaphore | 评估→试用 | 语义元数据与分类平台 |
标准与生态 —— Open Semantic Interchange（OSI）
Open Semantic Interchange（OSI）倡议由 Snowflake 牵头，合作伙伴包括 dbt Labs、Sigma、Omni、Hex，以及后来加入的 Google 与 AWS，旨在为语义模型交换建立一套厂商中立的规范（基于 YAML 的 OSI 模型加映射模块）。在 OSI 之前，每个工具各自实现私有的语义层（指标存储、上下文层、无头 BI），即便指标逻辑在单个工具内定义良好，仍会产生语义碎片化。目前 OSI 工作组的参与方包括 Alation、Atlan、BlackRock、Cube、dbt Labs、Elementum AI、Hex、Honeydew、Mistral AI、Omni、RelationalAI、Salesforce、Select Star、Sigma 与 ThoughtSpot——它被定位为一个「通用翻译器」，让各平台能在嵌入式分析与 AI 体验中一致地理解诸如「revenue」或「active user」这类特定于业务的定义。
环：评估→试用 · 象限：横跨上述所有象限的跨领域技术/标准。具战略意义；仍在演进；值得让新的语义层工作向其正在成形的方向对齐。
雷达汇总表
| 厂商 / 工具 | 象限 | 环 | 主要场景 |
|---|---|---|---|
| Snowflake Semantic Views | 云数据平台 | 试用→采用 | 面向 AI/BI 的数仓原生语义 |
| Databricks Metric Views | 云数据平台 | 试用 | 湖仓原生语义指标 |
| Power BI 语义模型 + Fabric | BI 语义 / 云数据平台 | 采用 | 成熟的 BI 语义，OneLake 集成 |
| AWS QuickSight Topics | BI 语义 | 评估→试用 | BI 原生的语义问答术语与指标 |
| Looker（LookML） | BI 语义 | 采用 | 以 GCP 为中心的语义建模语言 |
| dbt Semantic Layer（MetricFlow） | 通用语义层 | 试用 | 与 dbt 集成的代码优先指标存储 |
| Cube Core / Cube Cloud | 通用语义层 | 试用→采用 | 跨工具的开放语义层 API |
| AtScale Universal Semantic Layer | 通用语义层 | 采用 | 跨 BI 的企业级语义治理 |
| Denodo Universal Semantic Layer | 语义知识栈 / 通用 | 试用 | 跨平台的虚拟化语义 |
| Honeydew Semantic Layer | 通用语义层 | 评估→试用 | Snowflake 之上的 AI+BI 语义层 |
| Bright Analytics 语义层 | 通用语义层 | 评估 | 以营销为中心的语义协调 |
| OntoText / PoolParty / Sinequa / Semaphore | 语义知识栈 | 评估→试用 | 本体/知识图谱语义 |
| OSI（Open Semantic Interchange） | 跨领域标准 | 评估→试用 | 厂商中立的语义模型规范 |
最佳实践
| 挑战 / 领域 | 描述 | 解决方案 / 建议 |
|---|---|---|
| 全企业铺开的风险 | 试图一次性对整个企业做语义建模，会造成双轨报表，新旧定义并存 | 从单一领域（例如营收与客户分析）起步；在扩展之前，先把两三个消费工具接到该语义源 |
| 语义的平台锁定 | 数仓/湖仓原生的语义对象（Semantic Views、Metric Views）虽强大，但绑定于单一平台 | 当多个 BI 工具或 AI 智能体须一致地消费同一指标时，将平台原生语义与通用层（dbt Semantic Layer、Cube、AtScale）搭配使用 |
| 跨工具的语义碎片化 | 历史上每个 BI/AI 工具各自实现私有语义层，导致同一指标（「revenue」）在各工具中定义不一 | 在厂商支持的地方追踪并对齐新兴的 OSI 规范；否则将定义集中于一个通用层，并把工具原生模型视为它的投影 |
| AI 智能体直接查询原始 schema | 绕过语义层的 LLM text-to-SQL/NL-BI 智能体会复现不一致的指标逻辑，并有连接（join）幻觉的风险 | 让智能体的数据访问经由受治理的语义层（在 Semantic Views 之上的 Cortex Analyst、由 dbt Semantic Layer/Cube 支撑的 MCP 服务器），而非原始数仓 schema |
按平台倾向的落地实操指引
- Snowflake 优先：Semantic Views（试用→采用）搭配 dbt Semantic Layer 或 AtScale/Cube 实现跨工具语义。
- Databricks 优先：Metric Views（试用）加上 dbt Semantic Layer 或 Cube，以在 Databricks 之外复用语义。
- 以 Microsoft 为中心：Power BI 语义模型 + Fabric/OneLake 集成（采用），随后评估非 Microsoft 工具是否需要通用层（AtScale、Cube）。
- 重度使用 AWS：QuickSight Topics 用于 BI 语义（评估→试用）；如需在更多工具间做到语义 DRY，可考虑通用层（Cube、AtScale）。
- 以 GCP 为中心：继续采用 Looker 语义模型（采用）；随着多工具需求增长，关注 OSI 对齐与通用层选项。
参见
- Agent Tech Stack References
- Thoughtworks Technology Radar Vol. 34 — Agentic AI Digest
- Microsoft Build 2026 — Fabric & Databases
- Databricks Genie（产品家族，包括 Genie Code）
- RAG Implementation
- Production Best Practices — Context Engineering
- AllThingsAWS
- AllThingsGoogle
- AllThingsMicrosoft
参考资料
- Semantic layer | Technology Radar — Thoughtworks
- What is Semantic Layer? — Databricks
- What is a Semantic Layer? Definition, Benefits, Types & More — AtScale
- Cube Core is open-source semantic layer for AI, BI and more — GitHub
- Build and centralize metrics with the dbt Semantic Layer — dbt Labs
- Semantic Layer: What it is and when to adopt it — dbt Labs
- Overview of semantic views — Snowflake Documentation
- Introduction to Metric Views (part 1 of 3) — Databricks Community
- How Looker's semantic layer enhances gen AI trustworthiness — Google Cloud
- How to Connect Your Semantic Models to Microsoft Fabric — Pragmatic Works
- A Guide to generative BI Topics with AWS QuickSight — Superluminar
- Snowflake's Semantic Layer: The Missing Link in Modernization — Hakkoda
- Open Semantic Interchange (OSI) Further Expands Partner Ecosystem — Snowflake
- Snowflake OSI: How the Open Semantic Interchange Initiative Will... — Brooklyn Data Co.
- Open and Unified Business Semantics for BI and AI — Databricks
- Model metric views — Azure Databricks, Microsoft Learn
- OneLake integration for semantic models — Microsoft Learn
- Making QuickSight topics natural-language-friendly — Amazon QuickSight Docs
- Semantic Layer — Cube.dev
- How Cube's Universal Semantic Layer & AWS work together — Cube.dev
- AtScale Joins OSI to Advance Open Semantic Standards for AI — AtScale
- Semantic Layer: Your Key to AI-Ready Data Insights — Denodo
- Honeydew and Snowflake Semantic Views — Honeydew
- Marketing semantic layer for your data warehouse — Bright Analytics
- The future of data is semantic — Thoughtworks
- What Is Open Semantic Interchange? — ThoughtSpot
- What do you think about the Open Semantic Interchange (OSI)? — r/dataengineering