필사 모드: Semantic Layer·Metrics Store·Reverse ETL 完全指南: dbt·Cube·Looker·Hightouch·Census 与数据激活 (2025)

Season 5 Ep 5 — 如果说 Ep 4 讲的是管道的工程学，那么 Ep 5 就是“数据的含义只定义一次”这个古老承诺的 2025 年版本。

• 前言 — “为什么每个团队算出来的营收都不一样？”
• 第 1 章 · Semantic Layer 的历史
  • 1.1 第一代: BI 内部定义
  • 1.2 第二代: Looker 的 LookML (2013–)
  • 1.3 第三代: Headless / Open Semantic Layer (2020–)
  • 1.4 为什么现在又火起来
• 第 2 章 · Semantic Layer 的构成
  • 2.1 核心实体
  • 2.2 关系与联接
  • 2.3 过滤器与参数
  • 2.4 示例 (dbt Semantic Layer / MetricFlow)
• 第 3 章 · dbt Semantic Layer / MetricFlow
  • 3.1 背景
  • 3.2 结构
  • 3.3 优势
  • 3.4 局限
• 第 4 章 · Cube — “面向开发者的 Semantic Layer”
  • 4.1 定位
  • 4.2 特点
  • 4.3 示例
  • 4.4 用在哪里
• 第 5 章 · Looker·LookML — “企业级的经典”
  • 5.1 定位
  • 5.2 优势
  • 5.3 局限
  • 5.4 2025 年策略
• 第 6 章 · 其他主要工具
  • 6.1 AtScale
  • 6.2 Lightdash
  • 6.3 Transform (dbt)
  • 6.4 Metabase·Superset
  • 6.5 Thought Spot
• 第 7 章 · Metrics Store 模式
  • 7.1 概念
  • 7.2 构成
  • 7.3 例子
  • 7.4 效果
• 第 8 章 · Headless BI
  • 8.1 定位
  • 8.2 优点
  • 8.3 工具
  • 8.4 局限
• 第 9 章 · Reverse ETL — “把数据送回运营”
  • 9.1 为什么需要
  • 9.2 主要工具
  • 9.3 模式
  • 9.4 案例
  • 9.5 数据激活 (Data Activation)
• 第 10 章 · AI·LLM 与 Semantic Layer
  • 10.1 为什么 AI 需要 Semantic Layer
  • 10.2 “Text-to-SQL” vs “Text-to-Metric”
  • 10.3 案例
  • 10.4 质量管理
  • 10.5 2025 年的方向
• 第 11 章 · Data Activation 实战场景 3 个
  • 11.1 电商 — 个性化推荐
  • 11.2 B2B SaaS — Product-led Sales
  • 11.3 金融科技 — Risk scoring
• 第 12 章 · 韩国企业的成熟度
  • 12.1 现状
  • 12.2 引入路径
  • 12.3 注意事项
• 第 13 章 · 反模式 10 例
  • 13.1 没有 Semantic Layer 就直接接 AI
  • 13.2 只依赖 LookML
  • 13.3 指标负责人不明
  • 13.4 不做 Deprecation 就改
  • 13.5 Reverse ETL 路径泛滥
  • 13.6 对 Reverse ETL 期待实时
  • 13.7 没有 Metric 版本就上线
  • 13.8 指标只定义在 Superset/Metabase 里
  • 13.9 自然语言 BI 缺少完整性校验
  • 13.10 每个团队各写各的 SQL 算指标
• 第 14 章 · 检查清单 — Semantic Layer·Reverse ETL 12 项
• 第 15 章 · 下期预告 — Season 5 Ep 6:“Feature Store 与 Vector·Graph·时序 DB 的融合”

前言 — “为什么每个团队算出来的营收都不一样？”

2015 年很多公司都经历过的经典混乱:

• 财务团队: “本月营收 10 亿”
• 市场团队: “本月营收 11.5 亿”
• 销售团队: “本月营收 9.7 亿”

同样的数据，不同的数字。原因是:

• 退款的处理方式
• 是否含税
• 货币换算的基准日
• 确认时点 (下单时 vs 入账时)

每个团队各自直接写 SQL，定义因此分岔。Semantic Layer 就是把“指标定义收拢到一处”来解决这个问题的尝试。

第 1 章 · Semantic Layer 的历史

1.1 第一代: BI 内部定义

• Business Objects、Cognos、MicroStrategy (1990s–2000s)
• 定义写在各个 BI 工具内部 → 厂商锁定

1.2 第二代: Looker 的 LookML (2013–)

• 用 LookML 把指标定义代码化
• 用 Git 管理、可复用
• 缺点: 只能在 Looker 里用

1.3 第三代: Headless / Open Semantic Layer (2020–)

• 独立于 BI 的单独一层
• dbt Semantic Layer / MetricFlow (2022)
• Cube (2019–)
• Transform(2021，→ dbt 于 2022 年收购)
• AtScale(企业级)

1.4 为什么现在又火起来

• 数据栈碎片化 → 指标重复更加严重
• AI・聊天机器人要查询数据 → 需要 自然语言→指标 的映射
• Headless BI 的崛起

第 2 章 · Semantic Layer 的构成

2.1 核心实体

• Entity: 业务对象 (订单、客户、产品)
• Dimension: 属性 (国家、类目、日期)
• Measure: 原始数值 (金额、数量)
• Metric: 可度量的指标 (营收、用户数、转化率)

2.2 关系与联接

• 声明实体之间的关系
• 自动生成联接路径
• 查询指标时在内部执行合适的联接

2.3 过滤器与参数

• 把期间、国家、产品等过滤条件标准化
• 按用户的权限 (Row-level security)
• 内置同比、环比 (YoY、MoM) 的计算

2.4 示例 (dbt Semantic Layer / MetricFlow)

semantic_models:
  - name: orders
    model: ref('fact_orders')
    entities:
      - name: order_id
        type: primary
      - name: customer_id
        type: foreign
    measures:
      - name: total_amount
        agg: sum
        expr: amount_krw
    dimensions:
      - name: order_date
        type: time
        type_params: {time_granularity: day}

metrics:
  - name: gross_revenue
    type: simple
    type_params:
      measure: total_amount

→ API 调用: metric('gross_revenue', filters=..., group_by=['order_date'])

第 3 章 · dbt Semantic Layer / MetricFlow

3.1 背景

• 2021 年 Transform 创立 (Nick Handel，前 Airbnb 实验团队)
• 2022 年 dbt 收购 Transform
• MetricFlow 成为 dbt Semantic Layer 的查询引擎

3.2 结构

• 在 dbt 模型之上定义 semantic model 与 metrics
• dbt Cloud 提供 API 服务
• BI・笔记本・AI 通过 API 调用查询指标

3.3 优势

• 对 dbt 友好，可扩展已有项目
• 开放标准 (GraphQL・JDBC)
• 2024–2025 年与主流 BI 集成 (Tableau・Hex・Mode 等)

3.4 局限

• 依赖 dbt Cloud (自托管选项仍在成熟中)
• 复杂的联接与度量，目前仍是直接写 SQL 更划算

第 4 章 · Cube — “面向开发者的 Semantic Layer”

4.1 定位

• 2019 年 Cube Dev
• 开源 + Cube Cloud
• 面向数据应用・Headless BI 的 API

4.2 特点

• 用 YAML/JS/Python 定义数据模型
• REST/GraphQL/SQL API
• 适合自己动手做仪表盘的开发者与产品团队

4.3 示例

cube(`Orders`, {
  sql: `SELECT * FROM fact_orders`,
  measures: {
    revenue: { sql: 'amount_krw', type: 'sum' },
    count: { type: 'count' }
  },
  dimensions: {
    orderDate: { sql: 'order_date', type: 'time' },
    country: { sql: 'country', type: 'string' }
  }
});

4.4 用在哪里

• 嵌入式分析 (把仪表盘提供给客户)
• 定制数据应用
• AI 聊天机器人查询指标的后端

第 5 章 · Looker·LookML — “企业级的经典”

5.1 定位

• 2013 年 Looker → 2019 年被 Google 收购
• LookML: 定义指标的 DSL
• 与 Google Cloud 集成，和 Looker Studio 结合

5.2 优势

• 业界最经受检验的 LookML
• 庞大的企业客户案例
• 2024–2025 年通过 Gemini 集成支持自然语言查询

5.3 局限

• LookML 很难在 Looker 之外复用
• 成本与锁定

5.4 2025 年策略

• dbt Semantic Layer 与 LookML 并行
• 以 BigQuery 为中心的企业，Looker + Gemini 就是默认选项

第 6 章 · 其他主要工具

6.1 AtScale

• 专攻企业级 Semantic Layer
• 大规模 MDX/XMLA (Excel・Power BI) 兼容
• 在金融・保险大企业中有优势

6.2 Lightdash

• 开源 Headless BI + dbt Semantic
• 作为 Looker 的替代品受到关注
• 2024–2025 年高速增长

6.3 Transform (dbt)

• 收购后被吸收进 dbt Semantic Layer

6.4 Metabase·Superset

• BI 工具本身内置了一部分 Semantic Layer 能力
• 与 dbt Semantic Layer 的联动在扩大

6.5 Thought Spot

• 自然语言检索式 BI
• 2024–2025 年在 LLM・AI 集成上领先

第 7 章 · Metrics Store 模式

7.1 概念

• 公司指标的唯一存放处
• 定义、版本、负责人、相关仪表盘
• “指标目录”

7.2 构成

• Metric catalog: 名称、说明、公式
• Governance: 审批、变更、deprecation
• API: 供 BI・笔记本・AI 查询
• Lineage: 指标来自哪些数据

7.3 例子

• Airbnb Minerva (内部系统，有公开论文)
• Uber uMetric
• LinkedIn Datahub metrics
• dbt Semantic Layer 把它对外标准化

7.4 效果

• 团队之间的指标一致
• 应对审计与监管
• 提升 AI 自然语言提问的准确性

第 8 章 · Headless BI

8.1 定位

• 查询・指标引擎 ↔ 前端 UI 的分离
• 前端可以自由地是应用、仪表盘或 AI 渠道
• 由 Semantic Layer 以 API 形式提供

8.2 优点

• 多 UI (网页・移动端・Slack・语音)
• 从既有 BI 迁移比较容易
• 便于集成 AI

8.3 工具

• dbt Semantic Layer + Hex/Mode/Tableau
• Cube + 定制网页
• Lightdash + dbt
• Metabase + dbt Semantic Layer

8.4 局限

• 定制 UX 的成本
• 维护被分散

第 9 章 · Reverse ETL — “把数据送回运营”

9.1 为什么需要

• Warehouse 里有宝贵的客户・行为数据
• Salesforce/HubSpot/Marketo 里却没有
• 工程师去接 API → 时间、成本、可靠性的问题

→ Reverse ETL: 把数据从 Warehouse 同步到运营 SaaS

9.2 主要工具

• Hightouch: 2020 年，业界领先
• Census: 2018 年，另一个领先者
• Grouparoo(现在是 Airbyte 的一部分)
• RudderStack(CDP + Reverse ETL)
• Workato(通用 iPaaS + 数据)

9.3 模式

1. 用 dbt 构建客户分群模型
2. Reverse ETL 从 Warehouse 读取并推送到 Salesforce/HubSpot/Intercom
3. 销售与市场立刻用上这些分群

9.4 案例

• 把客户 LTV 注入 Intercom → 对话优先级
• 把 Health score 注入 Salesforce → 应对 Churn
• 把基于用量的分群送进 Marketo → 做活动

9.5 数据激活 (Data Activation)

• 不止步于分析，而是触发 运营动作
• 与 CDP (Customer Data Platform) 部分竞争、部分互补
• 2025 年现代数据栈的收官拼图

第 10 章 · AI·LLM 与 Semantic Layer

10.1 为什么 AI 需要 Semantic Layer

• LLM 想把自然语言问题转成 SQL 时，需要指标定义
• “我们的营收是多少？”的答案每家公司都不一样
• 如果让 LLM 直接访问 raw 表，就有幻觉与错误的风险

10.2 “Text-to-SQL” vs “Text-to-Metric”

• Text-to-SQL: 基于公司 schema 生成 SQL → 指标不一致的风险
• Text-to-Metric: 调用 Semantic Layer API → 只返回已定义的指标 → 安全

10.3 案例

• dbt Semantic Layer + GPT/Claude/Gemini 做自然语言 BI
• Cube + 定制聊天机器人
• ThoughtSpot AI・Looker Gemini 原生支持

10.4 质量管理

• 指标定义的标准化是必需项
• 权限・审计在 Semantic Layer 中央管理
• 不让 AI 直接写 SQL 才更安全

10.5 2025 年的方向

• Headless BI + AI = “所有团队都用自然语言与数据对话”
• Semantic Layer 成为 AI 的 安全数据访问层

第 11 章 · Data Activation 实战场景 3 个

11.1 电商 — 个性化推荐

• Warehouse: 客户行为・购买历史 → 用 ML 模型算推荐分数
• Reverse ETL: 分数 → Braze/Iterable/Salesforce Marketing Cloud
• 结果: 个性化推送/邮件的自动化

11.2 B2B SaaS — Product-led Sales

• Warehouse: 产品用量・功能 adoption 指标
• Reverse ETL: 指标 → Salesforce
• AE 可以立刻看到“我的客户里谁最可能升级”

11.3 金融科技 — Risk scoring

• Warehouse: 交易模式・风险分数
• Reverse ETL: 分数 → 客服工具 (Zendesk/Intercom)
• 客服在接待 VIP・高风险客户时拿到上下文

第 12 章 · 韩国企业的成熟度

12.1 现状

• 大企业・IT: Looker・Tableau・Superset 混用，Semantic Layer 的引入还在早期
• 创业公司: dbt + Metabase/Superset 的组合很常见
• Toss・Coupang・Danggeun・Kakao: 有自建内部 Metrics Store 的案例
• Reverse ETL: Hightouch・Census 在 2024 年急剧扩张

12.2 引入路径

1. dbt + 把标准指标写成文档
2. 在 Metabase/Superset 里把指标暴露出来
3. 试验 dbt Semantic Layer / Cube
4. 从特定团队开始用 Reverse ETL 打通运营
5. 全公司 Metrics Store + 接上 AI

12.3 注意事项

• 韩语业务术语的定义
• 税金・汇率・会计政策的定制
• 安全与权限体系 (按职级、部门)
• 反映审计与监管要求

第 13 章 · 反模式 10 例

13.1 没有 Semantic Layer 就直接接 AI

指标幻觉、一致性崩塌。

13.2 只依赖 LookML

和其他 BI・AI 渠道断开。

13.3 指标负责人不明

变更责任出现真空。

13.4 不做 Deprecation 就改

下游的仪表盘会坏掉。

13.5 Reverse ETL 路径泛滥

从 Warehouse 拉出几十条同步管道，无法管理。

13.6 对 Reverse ETL 期待实时

大多是分钟–小时级，并不是“实时”。

13.7 没有 Metric 版本就上线

过去的报表无法复现。

13.8 指标只定义在 Superset/Metabase 里

没有独立的 Semantic Layer → 与其他工具割裂。

13.9 自然语言 BI 缺少完整性校验

原样相信 AI 的回答 → 做出错误决策。

13.10 每个团队各写各的 SQL 算指标

回到原点。

第 14 章 · 检查清单 — Semantic Layer·Reverse ETL 12 项

• 把核心指标目录写成文档 (负责人、定义、SLA)
• 评估 Semantic Layer 候选 (dbt/Cube/Looker)
• BI・AI 渠道的集成计划
• 指标版本与 deprecation 流程
• 权限与 Row-level security
• 血缘 (Lineage) 与审计
• Reverse ETL 工具选型与管道目录
• 与运营系统 (Salesforce・HubSpot 等) 的映射
• 数据激活的 ROI 度量
• AI/LLM 自然语言访问的管控
• 失败与告警的应对机制
• 用户培训与上手引导

第 15 章 · 下期预告 — Season 5 Ep 6:“Feature Store 与 Vector·Graph·时序 DB 的融合”

如果说 Semantic Layer 是 BI 的语言层，那么 Feature Store 就是 ML 的语言层。而 2025 年的数据 DB 正在把向量、图、时序融合起来。

• Feature Store 的重新定义 (Feast/Tecton)
• Online-Offline skew 的管理
• 实时 Feature Pipeline
• Vector DB 的版图 (Pinecone/Weaviate/Milvus/Chroma/LanceDB)
• 多模态 embedding 的存储
• Graph DB (Neo4j/NebulaGraph/Dgraph) 与知识图谱
• 时序 DB (InfluxDB/TimescaleDB/VictoriaMetrics)
• 2025 年“Unified DB”的登场
• AI・ML 工作负载给 DB 版图带来的冲击
• 韩国企业的选择

“数据胜过模型，特征胜过数据”是 2025 年 ML 的智慧。

下一篇再见。

摘要: Semantic Layer 是“指标定义一次，所有渠道复用”这个古老承诺的 2025 年版本。dbt Semantic Layer・Cube・Looker・Lightdash・AtScale 各自占住一个位置，Reverse ETL (Hightouch・Census) 把 Warehouse 的数据送回运营工具，从而完成 Data Activation。在 AI・LLM 时代，Semantic Layer 被提升为 安全的数据访问层，并且推荐用 Text-to-Metric 取代 Text-to-SQL。韩国企业正以 dbt + Metabase/Superset + Hightouch/Census 的组合快速追赶，像 Toss・Coupang・Kakao 那样自建内部 Metrics Store 的案例正在扩散。“讲述数据含义的那一层”不再是奢侈品，而是 AI 时代的基础设施。