4. 数据资产准备与治理
AI 项目的失败往往不在模型结构，而在数据底座。一个 RAG 应用如果召回了过期合同、一份微调数据集如果混入了未脱敏的手机号，模型再强也无法交付。Unity Catalog（UC）的价值在于把“数据发现、质量校验、权限管理、血缘追踪、合规脱敏”收敛到同一套元数据与访问控制平面，让 AI 项目从“能跑通”走向“可审计、可复现、可交付”。本节围绕这五件事，讲清它们各自解决什么问题、在 UC 中如何落地，以及如何串成一条可信数据链路。
一、数据发现：先让数据“可被找到、可被理解”
数据发现的核心不是搜索框，而是元数据。UC 采用三层命名空间 catalog.schema.table，并支持对表、列、视图、函数、模型、卷（Volume）统一登记。AI 项目真正需要的是“语义可发现”：一份 prod_ai.rag_docs.contract_chunks 表，光有表名不够，还要知道每列含义、更新频率、负责人、是否含 PII。
落地做法是给关键资产补齐三类元数据：表级 COMMENT 说明业务用途与刷新周期；列级 COMMENT 标注语义与敏感级别；用 TAG 打上机器可读的标签，例如 domain=legal、pii=true、freshness=daily。标签是后续权限与脱敏策略的“挂钩点”，比人工记忆可靠得多。示例：
ALTER TABLE prod_ai.rag_docs.contract_chunks
SET TAGS ('domain' = 'legal', 'pii' = 'true', 'freshness' = 'daily');
ALTER TABLE prod_ai.rag_docs.contract_chunks
ALTER COLUMN signer_phone COMMENT '签署人手机号，PII，需脱敏后用于检索';
当标签体系建立后，数据发现就从“翻目录”变成“按标签筛选”：检索 pii=true 即可列出所有需要脱敏的资产，检索 freshness=daily 即可核对哪些表可能已过期。
二、质量校验：把“数据可用”变成可判定条件
AI 对数据质量的敏感点与 BI 不同：BI 怕算错，AI 怕“脏样本被学进去”。因此质量校验要覆盖完整性、唯一性、取值范围、分布漂移四类。UC 本身不内置质量引擎，但可通过 Delta 表约束、期望（Expectations）与调度任务组合实现。
以微调数据集 prod_ai.finetune.qa_pairs 为例，可定义如下校验规则：question 非空且长度在 5～512 之间；answer 非空；(question) 唯一；label 取值属于 {positive, negative, neutral}；每日新增行数波动不超过历史均值的 ±30%。前四条用 Delta 约束或 SQL 断言即可，第五条属于分布监控，需要按天聚合后比较。
-- 唯一性与取值域校验（示例）
SELECT COUNT(*) AS dup_cnt FROM (
SELECT question FROM prod_ai.finetune.qa_pairs
GROUP BY question HAVING COUNT(*) > 1
);
SELECT COUNT(*) AS bad_label FROM prod_ai.finetune.qa_pairs
WHERE label NOT IN ('positive','negative','neutral');
判断标准要事先写死：dup_cnt = 0、bad_label = 0 才允许下游训练任务启动；否则任务失败并告警。这样质量就从“感觉还行”变成“不达标就不放行”。
三、权限管理与血缘追踪：谁在用、从哪来、到哪去
UC 的权限模型是“目录—模式—表/视图/函数/模型/卷”逐级继承，配合账户级组（Group）而非个人授权，避免人员流动导致权限失控。AI 项目常见的最小权限划分是：数据工程组对原始层有写权限，特征/训练组对清洗层只读，推理服务对向量索引与模型只读，任何人不得直接读取原始 PII 列。
GRANT USE CATALOG ON CATALOG prod_ai TO `ai_engineers`;
GRANT USE SCHEMA ON SCHEMA prod_ai.finetune TO `ai_engineers`;
GRANT SELECT ON TABLE prod_ai.finetune.qa_pairs TO `ai_engineers`;
-- 原始 PII 表不授予 ai_engineers，仅授予 data_stewards
血缘追踪解决的是“这份训练数据从哪来、被谁改过、影响了哪些模型”。UC 自动记录表级与列级血缘，覆盖 Notebook、Job、SQL Warehouse 等写入路径。当上游 raw.contracts 的 schema 变更时，可沿血缘快速定位受影响的清洗表、特征表、向量索引与已注册模型，从而决定是否需要重跑。血缘也是合规审计的证据链：能证明某个模型只使用了已授权、已脱敏的数据。
四、合规脱敏：在“可用”与“不可识别”之间取平衡
脱敏不是简单地把字段删掉，而是按用途分级处理。常见策略有四类：掩码（保留格式，如 138****1234）、哈希（用于关联但不可逆）、泛化（如把精确生日变为年龄段）、令牌化（用代理值替换，保留可逆映射但映射表单独管控）。对 RAG 场景，检索仍需语义，因此手机号、身份证号应掩码或哈希，而合同金额、条款文本可保留。
UC 提供列级掩码与行级过滤函数，把脱敏策略绑定到标签上，实现“一次定义、处处生效”：
CREATE FUNCTION prod_ai.security.mask_phone(phone STRING)
RETURNS STRING
RETURN CASE WHEN is_account_group_member('pii_readers')
THEN phone ELSE CONCAT(SUBSTRING(phone,1,3),'****',SUBSTRING(phone,8,4)) END;
ALTER TABLE prod_ai.rag_docs.contract_chunks
ALTER COLUMN signer_phone SET MASK prod_ai.security.mask_phone;
这样，普通 AI 工程师查询时自动看到掩码值，只有 pii_readers 组能看到明文，且所有访问都留痕。脱敏策略与标签联动后，新增 PII 列只要打上 pii=true 并绑定掩码函数即可，不必逐表改代码。
五、把五环串成一条可交付链路
单独做好每一环并不难，难的是让它们协同。推荐的落地顺序是：先建标签规范（pii、domain、freshness），再对关键资产补 COMMENT 与 TAG；随后为 PII 列绑定掩码函数、为敏感表配置行过滤；接着用组授权收敛访问面；再接入质量校验任务，把校验结果写入 prod_ai.ops.dq_results 表；最后依赖 UC 自动血缘做影响分析。
判断这条链路是否真正可信，可以看四个可验证信号：任意一份训练数据能否沿血缘回溯到原始表；PII 列是否对所有非授权组自动掩码；质量校验失败时下游任务是否真的被阻断；新增一列 PII 时是否只需打标签而无需改代码。四个都能回答“是”，数据底座才算立住。