用途：当 BigQuery 是 GCP 上分析工程与数据交付的核心时使用本技能，帮助智能体判断哪些工作应放在 BigQuery、哪些属于 Dataform，以及何时应转向 Dataflow、Dataproc 或外部编排。
适用场景：设计或评审 BigQuery 物理模型；在 Dataform、dbt、Dataflow、Dataproc 之间划分职责；调优分区、聚类、槽位与成本行为；定义 GCP 上的摄取与转换边界；围绕 BigQuery 构建平台原生分析工作流。资料明确提醒：不要把 BigQuery 当作所有预处理与编排需求的通用默认选择。
工作流：一、定义工作负载边界，明确落地模式、转换复杂度、延迟要求、治理与区域约束、成本敏感度。二、有意识地设计 BigQuery 物理布局，涵盖分区、聚类、数据集边界、发布层、数据保留与服务预期。三、选择转换面：Dataform 用于仓库原生 SQL 转换工作流，dbt 用于团队已标准化的场景，Dataflow 或 Dataproc 用于超出仓库原生适配范围的预处理或运行时需求。四、定义编排与运维，包括编排运行位置、槽位与并发行为、失败与重跑预期、发布前验证门。五、验证成本与治理行为，要求具备槽位或查询成本意识、服务账号与密钥控制、必要的策略标签或治理元数据，以及发布就绪证据。
常见误区：认为 GCP 上一切都应跑在 BigQuery；认为 Dataform 只是 SQL 包装；认为分区与聚类可以以后再调。资料指出，部分预处理、流式或协议密集型工作应放在 Dataflow、Dataproc 或上游服务；Dataform 会改变转换工作流、依赖、测试与部署的管理方式；糟糕的物理设计往往成为长期成本与性能负担。
危险信号：BigQuery 物理设计隐含或照搬默认值；Dataform、Dataflow 与 Dataproc 之间的转换边界不清；模型设计时未考虑成本或槽位行为；仓库原生管道的发布与验证行为未定义；把治理元数据与访问控制当作单独的收尾工作。
验证清单：物理设计选择明确且贴合工作负载；Dataform、BigQuery 与其他 GCP 服务边界清晰；成本、槽位与并发影响有文档记录；治理与访问控制已纳入考虑；发布前发布与验证行为明确。
限制：资料未提供具体安装命令、代码示例、定价或平台版本信息。