Semantic Layer vs. Data Catalog：互补而非竞争
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source link, formatting, markdown, and any code blocks exactly as they are.
数据目录
数据目录是组织数据资产的可搜索清单——可以把它想象成数据的图书馆卡系统。它告诉你有哪些数据、数据位于何处、谁拥有这些数据以及数据在系统中的流动方式。
关键功能
- 发现 – 通过搜索关键字、标签或所有者来查找表、视图、文件和仪表盘。
- 血缘 – 追踪数据从源头到目的地的流动路径，包括沿途的每一次转换。
- 治理元数据 – 记录数据质量评分、分类（如 PII、机密）以及合规状态。
- 文档 – 存储资产描述，通常由数据生产者和使用者共同维护。
数据目录本质上是一个 被动 系统。你可以搜索、浏览并阅读其中的信息，但它不会改变查询的执行方式或指标的计算方式；它仅仅是对数据相关信息进行组织。
语义层
语义层定义了数据的含义以及如何正确使用它。它是一个 active 系统，位于原始数据和查询这些数据的工具之间。
关键功能
- 指标定义 – 收入、流失率、活跃用户——在所有地方以相同方式计算。
- 查询翻译 – 将业务问题转换为优化的 SQL。
- 访问强制 – 在查询时应用行级安全和列掩码。
- 文档 – 维基和标签附加到视图和列上。
当用户询问“按地区的收入是多少？”时，语义层会将“收入”翻译为正确的 SQL 公式，连接相应的表，应用安全过滤器，并返回结果。
Comparison
| 方面 | 数据目录 | 语义层 |
|---|---|---|
| 主要回答的问题 | “我们有什么数据？” | “这些数据意味着什么？” |
| 系统行为 | 被动（搜索和浏览） | 主动（查询翻译） |
| 范围 | 所有资产的元数据 | 业务定义、指标、安全 |
| 血缘 | 跟踪数据流向 | 定义计算逻辑 |
| 查询执行 | 不执行查询 | 翻译并优化查询 |
| 访问控制 | 记录策略 | 在查询时强制执行策略 |
为什么两者都需要
- 没有语义层的目录 – 用户可以找到数据，但不知道如何正确使用。它们可能自行编写收入公式，导致组织内部不一致。
- 没有目录的语义层 – 用户可以对语义层覆盖的数据集执行准确、受治理的查询，但无法发现层之外的数据集。新来源、实验表和原始文件在手动添加之前是不可见的。
最有效的架构是将两者集成：
- 发现与血缘 由目录在所有资产中处理。
- 意义、计算和治理 由业务关键数据集的语义层处理。
一个集成系统提供单一界面，数据发现和业务上下文并存。您搜索目录以找到数据集，然后查看其语义层定义——度量公式、文档、标签和访问策略——以及目录元数据（血缘、质量、所有权）。
综合示例：Dremio
Dremio 将 Open Catalog（基于 Apache Polaris，开源的 Iceberg REST 目录标准）与语义层功能相结合：
- Open Catalog – 表、视图、数据源及其血缘的清单。
- Virtual datasets（SQL 视图） – 定义业务逻辑和指标计算。
- Wikis – 记录每个数据集和列的含义。
- Labels – 为数据打标签，以实现治理和可发现性（如 PII、Finance、Certified）。
- FGAC – 在查询时强制执行行/列安全。
AI 代理的收益
AI 代理可以直接利用此集成：
- 使用目录来浏览可用的数据集（例如，“Sales 空间中有哪些表？”）。
- 使用语义层生成准确的查询（例如，“Revenue 是什么含义，谁可以看到哪些行？”）。
如果缺少其中任何一部分，AI 要么对可用数据一无所知，要么生成错误的 SQL。
快速自检
打开当前的数据目录，选择一张业务关键表：
- 您能看到它的关键指标是如何计算的吗？
- 谁可以访问哪些行？
- 列名在业务层面上意味着什么？
如果目录仅显示该表的存在，那么您已经识别出语义层需要填补的空白。