用途
本技能适用于在 GCP 上以 Dataplex、BigQuery 及相关 Google Cloud 元数据控制为中心开展数据治理的场景。它帮助智能体定义治理区域、策略标签边界、血缘预期，以及面向数据仓库与数据湖平台的可信发布模式。
适用时机
- 设计 Dataplex 数据湖、区域（zones）或治理域（governance domains）
- 定义 BigQuery 策略标签（policy tags）与受治理的发布边界
- 改善 GCP 上的元数据质量、血缘与数据发现
- 在 Cloud Storage、BigQuery、Dataflow 和 Dataproc 之间对齐仓库与数据湖治理
- 使受治理的分析交付能够满足区域性或受监管数据的控制要求
技能特别提示：不应把 BigQuery 治理仅视为权限问题。可信发布还需要元数据、归属关系和策略边界。
工作流程
- 定义治理边界。需要决定：数据湖与区域、数据集与域、生产者与消费者边界、归属关系预期。
- 定义元数据与策略控制。包括：策略标签、分类、血缘覆盖范围、发现元数据、可信资产与探索性资产的标识。
- 对齐数据湖与仓库治理。明确 Cloud Storage、BigQuery 及处理服务如何纳入同一控制模型。
- 设计受治理的发布行为。要求：清晰的服务边界、归属关系可见性、必要的发布或验证证据、模式与策略变更规则。
- 验证日常运维（day-2 operations）。审查在治理模型下，新资产接入、模式演进和新域是否仍然可管理。
常见误区
- “策略标签就是整个治理设计。”——标签有帮助，但不能替代归属关系、区域设计、可信发布或元数据质量。
- “Dataplex 只用于数据湖治理。”——许多团队需要跨存储、仓库和处理面的联合治理模型。
- “资产被扫描后，发现会自动发生。”——有用的数据发现需要经过整理的元数据和信任信号。
危险信号
- 数据湖、数据集和域的边界不一致
- 存在策略标签，但缺少归属关系或发布上下文
- 仓库与数据湖治理行为不同，且没有明确规则
- 缺少认证或可信资产行为
- 模式与策略变更在运维层面不清晰
验证要点
- 治理边界在数据湖与仓库面上均明确
- 策略标签、元数据和血缘预期已定义
- 发布行为受治理且可审查
- 归属关系与发现预期可见
- 日常运维符合治理设计