Season 5 Ep 5 — 如果说 Ep 4 讲的是管道的工程学，那么 Ep 5 就是“数据的含义只定义一次”这个古老承诺的 2025 年版本。
- Prologue — “为什么每个团队算出来的营收都不一样？”
- 第 1 章 · Semantic Layer 的历史
- 第 2 章 · Semantic Layer 的构成
- 第 3 章 · dbt Semantic Layer / MetricFlow
- 第 4 章 · Cube — “面向开发者的 Semantic Layer”
- 第 5 章 · Looker·LookML — “企业级的经典”
- 第 6 章 · 其他主要工具
- 第 7 章 · Metrics Store 模式
- 第 8 章 · Headless BI
- 第 9 章 · Reverse ETL — “把数据送回运营”
- 第 10 章 · AI·LLM 与 Semantic Layer
- 第 11 章 · Data Activation 实战场景 3 个
- 第 12 章 · 韩国企业的成熟度
- 第 13 章 · 反模式 10 例
- 第 14 章 · 检查清单 — Semantic Layer·Reverse ETL 12 项
- 第 15 章 · 下期预告 — Season 5 Ep 6:“Feature Store 与 Vector·Graph·时序 DB 的融合”
Prologue — “为什么每个团队算出来的营收都不一样？”
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 模式
- 用 dbt 构建客户分群模型
- Reverse ETL 从 Warehouse 读取并推送到 Salesforce/HubSpot/Intercom
- 销售与市场立刻用上这些分群
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 引入路径
- dbt + 把标准指标写成文档
- 在 Metabase/Superset 里把指标暴露出来
- 试验 dbt Semantic Layer / Cube
- 从特定团队开始用 Reverse ETL 打通运营
- 全公司 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 时代的基础设施。