过去几年，数据界的每个人都在谈论语义层。 

商业智能供应商将其作为一种便捷的指标模型进行销售。现代数据架构称之为指标层。人工智能团队则声称，如果没有它，就无法构建分析代理。但如果你仔细观察一下主要科技公司（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 语义层实际上就是 数据模型 。大型科技公司的语义层是 指标基础设施 。