阅读材料: 第8部分. 源和 Schema Manifest

模块「第8部分. 源和 Schema Manifest」中第 1 / 5 节课

您正在未登录状态下查看课程。请登录，以保存进度并参加测试。

来源

第 8 部分.数据源与 Schema Manifest

数据源画像(profiling)是一种观察模式,而非设计模式。智能体应该读取原始文件的表头、行示例和简单的统计数据,但不应自行决定其业务含义。在这一步中,我们收集事实与待澄清问题, 以避免在猜测之上编写契约。

需要画像的内容

针对每个数据源:

文件名或表名;
字段列表;
观察到的类型;
空值以及允许 null 的字段;
候选键;
PII 候选字段;
新鲜度或导出日期(若有);
需要向人类提出的问题。

示例:

数据源:raw/open_api_consents.csv
字段:consent_id, customer_id, scope, granted_at, revoked_at
候选键:consent_id
PII 候选:customer_id —— 合成的标识符,无直接 PII
待澄清问题:revoked_at 为空是否意味着同意处于生效状态?

为什么 manifest 与契约分开

Manifest 描述的是"被观察到的"。契约描述的是"被承诺的"。如果数据源中存在 pii_email 字段,manifest 必须将其呈现出来。契约可以禁止它进入 mart。如果把这两个层次混在一起,智能体就会在人类批准策略之前就开始"清理"数据源。

Qwen 查询

读取 raw CSV 的表头与前几行数据。
生成 Schema Manifest:字段、观察到的类型、候选键、PII 候选、
新鲜度提示与待澄清问题。
不要编写 dbt 模型。在批准之前不要决定 grain。

最小产出

至少为两个数据源编写一份 manifest 草稿。在可运行的示例中, 已有如下文件:

specs/source-manifests/card_transactions.md
specs/source-manifests/open_api_consents.md

格式:

# Schema Manifest: card_transactions

## 观察到的字段
## 候选键
## PII 候选
## 质量备注
## 待澄清问题

待澄清问题并不是弱点。这是对隐性猜测的一种防护。

给读者的解读

数据源画像要求克制。智能体看到 risk_flag 字段, 就急着赋予它业务含义。看到空的 revoked_at,就想当然地认定该同意是生效的。看到 stage,就可能联想到信贷方法论。在这种时刻,最有用的做法就是禁止自己进行解读。数据源画像只负责观察:有哪些字段、哪些类型看起来是真实的、哪些值为空、哪些键看起来是稳定的。

Manifest 保护原始层(raw layer)不被过早地清洗。如果数据源中存在异常,应当先记录下来,而不是直接修正。一个空日期可能是错误、表示"同意生效"的一种合法编码方式,或者是数据丢失的结果。这些可能性需要不同的处理。如果智能体立刻把空值替换成方便的值, 审查者就再也看不到本应交给人类决定的问题了。

因此,"待澄清问题"一节并不是工作做得不好的标志。恰恰相反, 它表明作者没有把猜测当成事实。在数据工程中,很多错误的发生并非因为有人不懂 SQL,而是因为过早地关闭了问题。"看起来像键"就被当作了键。"看起来像 PII"没有任何策略就留下了。"看起来像生效的同意"就被写进了报表。

一份好的 manifest 读起来就像一份现场勘查记录:我们发现了什么, 测量了什么,什么看起来可疑,什么必须由数据源负责人才能决定。这样一份文件并不能取代契约。它让契约更诚实,因为契约的起点不是理想图景,而是实际收到的数据。