Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
필사 모드
分享
Authors

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

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

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 时代的基础设施。

Discuss on Twitter • View on GitHub