第 19 部分.语义层、指标与 exposures

当相同的指标开始在多个报表、应用或团队中被使用时,语义层就出现了。 在此之前,清晰的数据集市和验证事实已经足够。但如果 total_balance_rub、 活动中的同意状态或 risk_event_count 在下游消费链中反复出现, 它们的定义就需要集中管理。

什么是指标

指标不仅仅是一列数据。它包含名称、计算公式、粒度、过滤器、刷新频率、 所有者以及消费者列表。如果两份报表按不同规则计算「活跃客户」, 问题不在 BI 工具,而在于语义契约。

dbt semantic models

dbt 支持 semantic models 和 metrics,但在教学路线中我们不要求 启用完整的语义层。首先需要记录语义意图:

指标:active_consent_count
源数据集市:mart_open_api_consents
定义:`revoked_at is null` 的同意数量
粒度:`scope`
消费者:Open API 监控

之后可以决定是否需要 dbt 语义层,或者有文档化的数据集市就足够了。

Exposures

Exposure 用于展示谁在读取数据产品:仪表板、API、notebook、报表。 这对契约漂移很重要。如果 mart 有 exposure,破坏性变更必须 通知下游消费者。

Qwen 查询

阅读数据集市和 specs。
找出看起来像通用指标的字段。
为每个字段建议定义、粒度、所有者、消费者和验证事实。
未经确认不要创建 semantic models。

最小输出

创建一个语义注册表:

# 语义注册表

## total_balance_rub
定义:
粒度:
所有者:
消费者:
验证:

读者解读

引入语义层不是因为它在现代技术栈中流行,而是因为 没有它,可重复使用的指标会开始出现偏差。只要一个数据集市 只被一份报表使用,定义可以放在数据集市旁边。当同一字段 出现在多个团队中时,就出现了新的契约:active_consent_count 具体 意味着什么,谁拥有这个定义,指标的粒度是多少, 应用了哪些过滤器。

重要的是不要将语义层与花哨名称的目录混淆。指标不是

列的重命名。它是计算公式、上下文、约束和消费者。如果 一个团队通过 revoked_at 中的 null 来统计活动中的同意状态, 而另一个团队通过日期排除旧的同意状态,那么组织就有了 两个同名指标。问题出在 BI 之上,而是出在缺乏明确的语义契约。

在教学项目中,可以不启用完整的语义层。这是 有意识的限制。首先需要学会记录意图:字段、定义、 粒度、所有者、消费者、验证。只有在此之后,判断 Markdown 注册表是否足够,还是需要 dbt semantic model,才有意义。否则团队 会得到另一个没有共识含义的 YAML 层。

Exposures 添加了消费者边界。它们展示谁在读取数据集市: 仪表板、notebook、API、定期报表。这会影响破坏性变更。 如果 mart 没有消费者,变更看起来是局部的。如果 记录了 exposure,作者就能看到字段重命名或粒度更改会影响到谁。这样 语义层就成为 SDD 的一部分,而不是独立的术语集市。

实践

从数据集中市中选择一个指标并填写语义注册表。如果无法

指出所有者或消费者,不要添加 semantic model —— 首先明确 产品承诺。

常见错误

为了技术栈的完整性而添加语义层。如果没有多个消费者和 可重复使用的指标,该层会变成官僚流程。但如果消费者已经存在, 缺失它会造成漂移。

检查问题

1. 指标与列有什么区别?
2. 何时 exposure 会使变更成为破坏性的?
3. 为什么在出现通用指标之前不应启用语义层?