语义层四层模型调研：DPROD / MetricFlow / Cube.js 谁管什么 —— AI 时代数据栈的”分层真相”

副标题 ：从 Headless BI 到 OSI，飞熊把 ” 语义层 ” 按职责拆成 4 层，每个项目只做自己那一段
赛道：数据治理 · 实战向系列第 8 篇
作者：飞熊 · 增长运营官 yunying 出品
时间：2026-08-19

上周我跟一个金融客户的 CDO 开会，他们刚做完数据中台一期，准备上 ” 语义层 ”。他说：”调研了一圈，发现每家都说自己是语义层 —— dbt Labs 说 MetricFlow 是语义层，DataHub 说自己是语义层，你们之前发的 DPROD 调研也说语义层，Cube.js 也说自己是语义层。我到底选谁？“

这个问题问到点子上了。

真相是：业内把 ” 语义层 ” 这个筐装得太满了。 不同的 ” 语义层 ” 项目，层级、目标、消费者、技术形态完全不同。如果不分清楚就选型，大概率踩坑。

飞熊把过去 8 篇调研（DPROD 368 + DataHub 330 + OpenMetadata 366 + OpenLineage 358 + Marquez 360 + Cube.js 282 + dbt 290 + DataGov 横评 352）按职责拆开，真正能讲清楚的 ” 语义层 ” 实际是 4 层：

L4 Governance（治理层）← ODRL / 数据契约 / 访问策略
L3 Ontology（本体层）← DPROD / RDF 知识图谱
L2 Metric（指标层）← MetricFlow / Cube.js / LookML
L1 Discovery（发现层）← DataHub / OpenMetadata / Atlas

每一层只做自己那一段 ， 必须配合用 ， 不能用一个项目解决所有问题。

本文飞熊实战向，带你 4 层全拆 + 5 大代表项目横评 + 飞熊客户场景的全栈组合。

核心问题 ：用户找数据。
代表项目 ：DataHub、OpenMetadata、Apache Atlas
飞熊已调研：DataHub · OpenMetadata

出品：LinkedIn（11 年）→ Acryl Data 商业支持
治理：Linux Foundation Data
核心能力：
元数据抓取（80+ 数据源 connector）
全文搜索 + 谱系图（Lineage Graph）
Ownership / Glossary / Tags
关键判断：L1 的事实标准，2026 主打 “Context Platform for AI Stack”
集成：原生支持 DPROD 本体描述（消费侧）

出品：open-metadata.org 社区，业内 14K stars 最高
治理：Apache-2.0 + Linux Foundation 治理中
核心能力：
DataHub 类似的元数据 catalog
独家：内置 Data Quality / Data Profiler / Data Observability
MCP Server 原生（openmetadata-mcp/ 目录直接是 MCP 实现）
关键判断：DataHub 的最强对手，MCP 集成更彻底

出品：Apache 顶级 / Hortonworks 起源
老牌元数据 catalog，跟 Hadoop 生态绑定深
关键判断：老牌但更新慢，新项目一般不选

核心问题 ：同一个指标在不同 BI 工具里数字不一致。
代表项目 ：MetricFlow、Cube.js、Looker、AtScale
核心范式：Headless BI（无头 BI —— 独立于 BI 工具的指标层）

出品：dbt Labs（dbt-core 同一团队）
License 历史（这条很多人不知道）：
v0.0 – v0.140：AGPL-3.0（传染性强）
v0.150 – v0.208：BSL（Business Source License） ⚠️
v0.209.0+：Apache-2.0 ✅（当前）
核心能力：
定义 Metric（指标）+ Dimension（维度）+ Entity（实体）
编译 dataflow-based query plan → 各方言 SQL（Postgres / Snowflake / BigQuery / Databricks）
Multi-hop joins + 复杂 metric（ratio / cumulative / derived）
关键人物 / 生态：OSI（Open Semantic Interchange）发起方之一（详见第六节）
安装：pip install dbt-metricflow

出品：Cube Dev（公司），GitHub cube-js/cube
技术栈：Rust 核心 + TypeScript + React Dashboard
核心能力：
跟 MetricFlow 几乎同位 —— L2 双雄之一
独有优势：前端嵌入式 BI（Cube.js Playground + React 组件库）
10,710 commits，活跃度极高
关键定位：面向 ” 嵌入式分析 + AI 消费 ”的语义层（README 第一句话：”open-source semantic layer for AI, BI and embedded analytics”）
OSI 创始成员

LookML 老牌（2012 起源），2020 Google 收购
核心：建模语言 + 强治理
关键判断：L2 的祖师爷，但现在被 MetricFlow/Cube.js 抢了不少风头
飞熊读者：企业级客户已在用 Looker 不用动；新项目不推荐

主打语义层 + AI 优化查询
跟 Snowflake 深度集成
关键判断：商业闭源 + 头部企业用，开源圈关注度低

维度	MetricFlow	Cube.js	Looker	AtScale
License	Apache-2.0 ✅	Apache+MIT ✅	闭源 💰	闭源 💰
学习曲线	中（要会 dbt）	中（JS/TS 友好）	高（LookML）	高
AI 友好度	中（OSI 推动中）	高（README 直说 for AI）	低	中
嵌入式 BI	弱	强（React 组件）	弱	弱
社区生态	大（dbt 用户基数）	大（20K stars）	大但闭源	小

核心问题 ：描述 ” 数据产品 ” 本身的语义信息，让人和机器都能 ” 读懂 ” 数据是什么。
代表项目：DPROD、RDF/OWL 知识图谱、Solid LWS

出品：OMG（Object Management Group） + EKGF + EDM Council 三方治理
仓库：github.com/EKGF/dprod（36 commits / 15 contributors）
License：CC BY 4.0（⚠️ 文档型 License，不是代码）
核心能力：
profile W3C DCAT（Data Catalog Vocabulary），专门描述 Data Product
基于 5 大 W3C 标准：DCAT / RDF / OWL / SHACL / PROV
三要素：数据 + 元数据契约 + 访问接口
关键人物：Jacobus Geluk（DPROD 创始人 / agnos.ai CEO）
思想旗帜：”AI Agents Don’t Read Brochures — why the data economy needs enforceable meaning“
规范站：ekgf.org/dprod

维度	DataHub 元数据	DPROD 描述
核心对象	Dataset / Dashboard / Pipeline	Data Product（业务交付单元）
Owner	技术团队	业务领域 + 技术 Owner 双 Owner
SLA	无	一等公民（freshness / availability / quality）
契约	无	DataContract 一等公民
AI 友好度	中	极高（语义可执行）

关键判断：DataHub 是 ” 有什么数据 ”，DPROD 是 ” 这个数据产品怎么交付 + 怎么消费 ”。

Apache OWL/RDF（W3C 标准）—— 老牌本体语言栈，但缺 Data Product 概念
Solid LWS（Tim Berners-Lee 项目）—— Web 去中心化数据保管，DPROD 的 ” 好搭档 ”
Schema.org —— SEO 时代的本体，跟 DPROD 不直接冲突（不同领域）

核心问题 ：数据访问合规 + 使用条款 + 违规审计。
代表项目：ODRL、Soda Core（Data Contracts）、Great Expectations、Unity Catalog

出品：W3C（2018-02-15 发布）
标准状态：W3C Recommendation（最高级标准）
核心能力：
政策表达语言（policy expression language）
可声明 “ 可 / 不可 ” 的操作（read/write/modify/distribute）
约束条件（count / datetime / purpose / industry）
跟 DPROD 关系：DPROD 描述产品本体，ODRL 描述使用条款
Jacobus Geluk 原话：”DPROD（语义）+ ODRL 数据契约（条款）+ Solid/LWS（保管）= 数据经济的机器可操作基础“

出品：Soda Data
核心：Data Contracts + Data Quality 测试
关键判断：跟 ODRL 互补 —— Soda 是 ” 商业化 Data Contract 工具 ”，ODRL 是 ” 标准化的表达语言 ”

出品：Great Expectations 开源社区
核心：Data Quality 期望 + 自动校验
关键判断：L4 偏 ” 质量 ”，但跟 L4 治理的 ” 访问 ” 互补

出品：Databricks（开源核心 + 商业扩展）
核心：湖仓一体的统一治理（数据 + AI + Notebook）
关键判断：跟 DPROD 在 AI 治理方向同向，Databricks 用户用 Unity Catalog 即可

维度	ODRL	Soda Core	Great Expectations	Unity Catalog
形态	W3C 标准（语言）	商业化工具	开源框架	商业化平台
核心职责	条款表达	契约执行	质量校验	统一治理
License	W3C 推荐 ✅	ELv2 ⚠️	Apache-2.0 ✅	不开源 💰
AI 友好度	极高	中	中	高
跟 DPROD 配套	必须	可选	可选	可选

重点 —— 因为这是飞熊 BI/ 数据栈全景图 338 的关键补丁。

Open Semantic Interchange（OSI） = Snowflake 牵头的语义模型交换标准。

发起时间 ：2025 年中（Snowflake 在 dbt Coalesce 2025 上宣布）
治理：开源 + vendor-neutral（Apache 项目）

类别	公司
数据平台	Snowflake（牵头）、Alation、Atlan、Select Star
语义层厂商	Cube、dbt Labs、AtScale（即指 Semantic Layer 公司）、RelationalAI、Hex
BI / 分析	Looker/Google、Sigma、ThoughtSpot、Omni、Blue Yonder
AI	Mistral AI、Salesforce、Elementum AI、Honeydew、BlackRock

一句话：2026 主流语义层厂商都加入了 OSI。这是事实上的 ” 语义层 L2 标准联盟 ”。

核心模型 ：YAML 格式 的语义模型标准
API：统一的 vendor-neutral query API
生态：Apache 开源项目，每家提供 ” 映射器 ” 把自己的语义层格式转 OSI 格式

维度	OSI	DPROD
标准组织	Snowflake 牵头（产业联盟）	OMG（国际标准组织）
治理	Apache 开源	OMG Managed Community
核心形态	YAML 模型 + Query API	W3C RDF/OWL 本体 + JSON-LD
关注点	L2 指标层 + 跨工具交换	L3 产品层 + AI Agent 可读
License	Apache-2.0	CC BY 4.0
成熟度	2025 起步，快速	2024 起步，1.0 beta
AI 友好	高（query API）	极高（语义可执行）

关键判断：

OSI = L2 指标层的产业标准（Cube/MetricFlow 通用格式）
DPROD = L3 产品层的国际标准（AI Agent 数据基座）
两者完全互补：OSI 解决 ” 指标怎么交换 ”，DPROD 解决 ” 数据产品怎么描述 ”

Standardization（标准化）—— 统一语义模型表达
Interoperability（互操作性）—— 跨工具跨平台
Extensibility（可扩展）—— 可适配业务
Open Source（开源）—— Apache 项目

把 4 层 + OSI + DPROD 串起来，飞熊给客户的 ” 语义层全栈方案 ” 长这样：

┌──────────────────────────────────────────────┐
│ 消费方 │
│  • AI Agent（通过 MCP）│
│  • BI 工具（Tableau/Looker/Sheet）│
│  • 嵌入式分析（Cube.js React）│
└─────┬────────────────┬──────────────┬─────────┘
      │ MCP            │ GraphQL/REST │ SQL
      ▼                ▼              ▼
┌──────────────────────────────────────────────┐
│ L4 Governance Layer │ ← ODRL 条款 / Soda 契约 / GE 质量
├──────────────────────────────────────────────┤
│ L3 Ontology/Product Layer │ ← DPROD 描述 + RDF/OWL 本体
├──────────────────────────────────────────────┤
│ L2 Metric Layer │ ← MetricFlow / Cube.js / OSI 标准格式
├──────────────────────────────────────────────┤
│ L1 Discovery Layer │ ← DataHub / OpenMetadata (MCP Server)
└──────────────────────────────────────────────┘
      │ │
      ▼ ▼
┌──────────────────────────────────────────────┐
│ 存储 / 计算层 │
│  • OLAP：ClickHouse / Doris / StarRocks │
│  • 湖仓：Iceberg / Delta Lake │
│  • 血缘：OpenLineage / Marquez │
└──────────────────────────────────────────────┘

真实查询流程（AI Agent 视角）：

问：" 上个季度华东区客户复购率？"

Step 1 [L1] OpenMetadata 搜 → 找到 " 客户复购指标 " 在哪个 Data Product
Step 2 [L3] DPROD 描述这个 Data Product →
 " 客户行为数据集，Owner= 数据科学团队，SLA=99.9%，访问 =Presto"
Step 3 [L2] MetricFlow 找 " 复购率 " 指标定义 →
 ratio(repeat_customers, total_customers)
 维度：region='华东'、time='上个季度'
Step 4 [L4] ODRL 校验：当前用户有 " 华东区 "+" 客户 " 权限
Step 5 [OSI] 通过 OSI query API 调用 Cube.js
Step 6 返回：" 上个季度华东区客户复购率 = 23.7%"

按 4 层模型，飞熊精选 5 个代表项目做横评，方便客户选型。

排名	项目	层级	Stars	License	关键定位
01	DPROD	L3	OMG 标准	CC BY 4.0	AI Agent 数据层 · W3C DCAT profile
02	Cube.js	L2	20K	Apache-2.0+MIT	嵌入式分析语义层 · Rust+TS · OSI 创始成员
03	DataHub	L1	12K	Apache-2.0	数据目录事实标准 · LF Data 治理
04	MetricFlow	L2	dbt Labs	Apache-2.0	dbt 生态语义层 · 编译 dataflow → SQL · OSI 创始成员
05	ODRL	L4	W3C 标准	W3C Rec	数字权利表达语言 · 跟 DPROD 配套

总数据：20K stars 最高 + 3 大 W3C/OMG/W3C 标准 + 5 跨层级生态

维度	DPROD (L3)	Cube.js (L2)	DataHub (L1)	MetricFlow (L2)	ODRL (L4)
核心问题	数据产品是什么	指标怎么算	数据在哪	指标怎么算	谁能用怎么用
消费者	AI Agent	BI + 嵌入式 + AI	人 + 搜索	BI + SQL 消费方	治理 + 合规
技术栈	W3C RDF/OWL	Rust + TS	Java + Python	Python lib	W3C XML/JSON-LD
AI 友好度	极高	高	中	中（OSI 推动中）	极高

现状	推荐优先级
BI 报表口径乱	L2 优先（MetricFlow/Cube.js）
数据找不到 / 重复建设	L1 优先（DataHub/OpenMetadata）
AI Agent 项目	L3 + L4 优先（DPROD + ODRL）
合规审计要求高	L4 优先（ODRL + Soda）

场景	推荐
已经在用 dbt 生态	MetricFlow（无缝衔接）
要前端嵌入式 BI / SaaS 产品	Cube.js（React 组件库）
团队 JS/TS 强	Cube.js
团队 Python 强	MetricFlow
预算紧 + 想要 OSS	都免费，二选一
要快速接入 OSI	都行（两家都是 OSI 创始成员）

现状	建议
只用一家 BI + 一家语义层	暂缓（OSI 给多工具场景用）
3+ BI 工具 + 多个语义层	必上（避免每家重复定义指标）
要 AI Agent 跨工具查数据	必上（OSI query API 是关键）

OSI 还在早期 —— 2025 起步，规范 + 映射器都没稳定，生产部署建议等 6-12 个月
DPROD 1.0 beta —— OMG 正式标准还需 12-18 个月，规范可能变
MetricFlow License 历史坑 —— 0.140 之前是 AGPL，0.150-0.208 是 BSL， 必须锁 0.209+ 才安全
Cube.js 项目重命名 —— GitHub 从 statsbotco/cubejs-client 改名 cube-js/cube，老 PR/Issue 链接失效
4 层不要全做 —— 中小企业上 4 层是过度工程， 优先 L1 + L2 即可，L3/L4 等 AI Agent 落地再做
W3C 学习曲线陡 —— DPROD + ODRL 都需要懂 RDF/OWL，国内团队普遍缺

客户痛点：同样 ” 营收 ” 在不同 BI 报表数字差 5%+，业务吵架

方案：
– L1 上 DataHub（数据目录 + ownership）
– L2 上 MetricFlow（统一指标定义）
– dbt 做转换层

报价：30-80 万（含咨询 + 实施 + 培训 6 个月）

客户痛点：AI Agent 拿不到可信数据，调用接口混乱

方案：
– L1 上 OpenMetadata（带 MCP Server）
– L3 上 DPROD（Data Product 描述）
– L4 上 ODRL（合规校验）
– AI Agent 通过 MCP 调用

报价：10-30 万（轻量咨询 + 落地实施 3 个月）

客户痛点：自己的 SaaS 要给客户加 BI 报表能力

方案：
– L2 上 Cube.js（唯一支持前端嵌入式）
– 私有部署 + React 组件库
– L1 用自家 catalog（可选）

报价：20-50 万（含前端组件定制）

Step 1 · 装 dbt + MetricFlow

pip install dbt-core dbt-metricflow
dbt init my_project
mf tutorial  # 跑通 MetricFlow 教程

Step 2 · 定义第一个 Metric

# models/metrics/orders.yml
metrics:
  - name: orders_total
    type: simple
    type_params:
      measure: orders
  - name: revenue_total
    type: simple
    type_params:
      measure: revenue

Step 3 · 启动 DataHub MCP Server

docker run -d -p 8080:8080 acryldata/datahub-mcp-server
# AI Agent 通过 MCP 查询 DataHub catalog

Step 4 · 编写 DPROD 描述 + ODRL 契约

// Data Product 描述（DPROD profile of DCAT）{
  "@context": "https://ekgf.org/dprod/context",
  "@type": "dprod:DataProduct",
  "dct:title": " 客户复购指标 ",
  "dprod:hasOwner": {"@id": "ex:domain-crm"},
  "dprod:hasSLA": {"dprod:freshness": "PT1H"}
}

<!-- ODRL 政策 -->
<o:Policy xmlns:o="http://www.w3.org/ns/odrl/2/">
  <o:permission>
    <o:target>ex:data-product/customers</o:target>
    <o:action>o:read</o:action>
    <o:constraint>
      <o:andConstraint>
        <o:leftOperand>ex:region</o:leftOperand>
        <o:operator>eq</o:operator>
        <o:rightOperand> 华东区 </o:rightOperand>
      </o:andConstraint>
    </o:constraint>
  </o:permission>
</o:Policy>

“ 语义层 ” 不是单一项目，是 4 层职责分明的体系。

L1 发现数据 → L2 算对指标 → L3 描述产品 → L4 治理合规 。
每一层有自己代表项目，必须配合用，不能用一个项目解决所有问题。

之前的全景图缺了语义层视角。飞熊把它补成 4 层：

L4 Governance    ← ODRL / Soda Core / GE
L3 Ontology      ← DPROD
L2 Metric        ← MetricFlow / Cube.js / LookML
L1 Discovery    ← DataHub / OpenMetadata / Atlas

✅ 数据治理 6+1 篇：DataHub 330 + OpenMetadata 366 + Marquez 360 + OpenLineage 358 + OL 实战 364 + DataGov 横评 352 + DPROD 368
✅ 语义层横评：本文（4 层模型 + 5 项目横评）
✅ AI Agent 框架 6 篇：DSH 340 + Aiframe 342 + LangChain 344 + Vibe Coding 346 + Open Design 348 + Cordis 350
✅ BI 栈全景图：338（含语义层补丁版）

写实战篇：“DPROD + DataHub + MetricFlow + ODRL 端到端实战 ”（30 天内）
更新 BI 栈全景图：338 加语义层 4 层视图（2 周内）
写 OSI 跟进：2026 Q3 OSI 规范成熟后再发一篇（3 个月内）

维度	详情
WP 文章	《语义层四层模型调研：DPROD / MetricFlow / Cube.js 谁管什么》
封面	`yj_semantic_layer_cover.png`（League Table 5 项目版）
WP POST ID	370
封面 media ID	369
WP 总数	156 → 157
赛道	数据治理 · 实战向系列第 8 篇
本地 md	`semantic-layer- 调研.md`

语义层四层模型调研：DPROD / MetricFlow / Cube.js 谁管什么 —— AI 时代数据栈的”分层真相”

一、引子：飞熊客户问 ” 我们想上语义层 ”，到底怎么答？

二、L1 Discovery Layer（发现层）—— “ 数据在哪，谁有，跟我什么关系 ”

DataHub（飞熊已调研 · 12K stars · Apache-2.0）

OpenMetadata（飞熊已调研 · 14K stars · Apache-2.0）

Apache Atlas（未调研 · 2.4K stars · Apache-2.0）

三、L2 Metric Layer（指标层）—— “ 营收到底是多少，每个工具算出来都一样 ”

MetricFlow（dbt Labs · Apache-2.0）

Cube.js（飞熊已调研 · 20K stars · Apache-2.0 + MIT 双协议）

Looker（Google Cloud · 闭源商业）

AtScale（闭源商业 · 已融资）

L2 选型决策矩阵（5 维）

四、L3 Ontology/Product Layer（本体 / 产品层）—— “ 这数据是啥，谁负责，能干啥 ”

DPROD（飞熊刚调研 · OMG 提议标准 · 1.0 beta）

DPROD vs 传统 DataHub 元数据描述（关键差异）

其他 L3 玩家

五、L4 Governance Layer（治理层）—— “ 谁能用、怎么用、违反怎么办 ”

ODRL（Open Digital Rights Language · W3C Recommendation 2.2）

Soda Core（飞熊已调研 · 2.4K stars · ELv2 ⚠️）

Great Expectations（飞熊已调研 · 11K stars · Apache-2.0）

Unity Catalog（Databricks · 不开源）

L4 选型决策矩阵

六、OSI（Open Semantic Interchange）—— 2026 年最值得关注的语义标准化

OSI 是什么？

OSI 创始成员（16 家巨头）

OSI 关键设计

OSI vs DPROD（关键对比）

OSI 4 大原则

七、4 层全栈架构图（飞熊实战模板）

八、5 大代表项目横评（飞熊 BI 栈语义层补充）

4 维度对比（横向选型）

3 大决策矩阵（飞熊客户咨询用）

决策 1：我先上哪一层？

决策 2：L2 选 MetricFlow 还是 Cube.js？

决策 3：上不上 OSI？

九、风险清单 + 飞熊咨询变现场景

6 条风险

3 大飞熊咨询变现场景

场景一：金融 / 制造企业 ” 指标口径统一 ” 项目（高客单价）

场景二：AI 创业公司 ”Agent 数据接入 ” 项目（2026 刚需）

场景三：SaaS 产品 ” 嵌入式分析 ” 项目（中长期）

实战 4 步（飞熊演示用）

十、收官判断

一句话总结

飞熊 BI 栈全景图 338 的语义层补丁

飞熊咨询资产盘点（语义层赛道）

下一步建议

📎 参考资料

✅ 已发布

近期文章

近期评论