Google PDE: BigQuery 分析与数仓工程 — 学习指南

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

属于 Google Professional Data Engineer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

BigQuery 是一个无服务器、列式、MPP（大规模并行处理）的分析型仓库，它将存储与计算分离，提供了近乎无限的扩展能力、ANSI SQL 和集成式治理。BigQuery 上的仓库工程需要在模式设计（分区、聚类、反规范化与规范化、嵌套记录）、注入模式（批量加载、流式注入、Storage Write API）和工作负载管理（按需付费版与基于容量的版本及预留）之间取得平衡。强大的安全性（授权视图、行/列级策略、策略标签）与成本控制和性能优化工具并存，旨在最大限度地减少扫描的字节数并降低延迟。本节涵盖了您在生产环境中必须预见的核心设计、运维和故障模式。

存储与语义：数据集、表、视图和数据湖访问

• 数据集、表、视图：

  • 数据集是 IAM 和治理的作用域。为每个租户保留独立的数据集，以实现隔离和清晰的计费。
  • 标准表以原生格式存储数据；分区和聚类决定了数据布局和剪枝。
  • 视图封装了 SQL 逻辑，但本身不存储数据。授权视图允许视图所有者向其他项目或租户暴露受限的数据子集，同时隐藏底层表。
  • 物化视图 (MV) 会持久化预计算的结果并自动刷新。查询重写在兼容时会透明地使用物化视图；不兼容的谓词或函数会绕过它们。
  • 外部表引用 Cloud Storage、Google Drive 或 Google Sheets 中的数据。它们避免了数据注入，但牺牲了吞吐量和函数支持以换取便利性。对于重复性的分析，应将数据注入到原生表中。

• 分区、聚类和嵌套记录：

  • 按注入时间、DATE/TIMESTAMP/DATETIME 或整数范围进行分区，以实现扫描剪枝。在分区列上使用 WHERE 过滤器或使用像 _PARTITIONDATE 这样的修饰符来启用剪枝。
  • 对高基数、经常被过滤或连接的列（最多 8 个）进行聚类。BigQuery 会自动重新聚类；重复的小型 DML 操作可能会暂时降低聚类质量。
  • 嵌套和重复记录 (STRUCT, ARRAY) 可以在没有连接开销的情况下为一对多关系建模。谨慎使用 UNNEST；对大型数组重复使用 UNNEST 可能会导致数据量急剧膨胀。

• 反规范化与规范化：

  • 将维度属性反规范化到事实表中，以最大限度地减少连接并利用列式扫描的优势；这对于读取密集型的分析场景是理想选择。
  • 当写放大、更新热点或自连接导致争用或复杂性增加时，应进行规范化（例如，分离主患者表和就诊表以避免自连接导致的数据爆炸）。考虑采用混合模式：规范化的核心实体，加上宽化的、反规范化的事实或嵌套的子记录。

• 物化视图：设计考量

  • 最适合对分区基表进行稳定的、增量的聚合。MV 刷新是异步的；下游用户应能容忍数据陈旧窗口，或将查询基表作为备用方案。
  • 按分区列进行过滤和分组以实现增量刷新。不确定性函数、不支持的连接类型或 UDF 可能会使 MV 失去被查询重写资格。

• 联合查询、BigLake 和下推：

  • 联合查询使用 SQL 直接读取外部系统（例如 Cloud SQL）。它们便于进行轻量级连接或一次性探索，但延迟更高且配额更严格；对于重度分析，应将数据提取到 BigQuery 中。
  • BigLake 表统一了数据湖和数据仓库的治理，能对 Cloud Storage 或开放表格式（如 Parquet）中的数据进行列级和行级控制。谓词和投影下推可以减少下载的字节数；对于大规模扫描，为了获得最佳性能，仍然推荐将数据注入到原生表中。

• 通配符表和旧式分片：

  • 通配符查询是针对按日期分片表的旧模式。推荐使用原生分区，但在需要时可使用：

undefined

。

查询优化与工作负载管理

• 分区裁剪与聚类：

  • 始终基于分区列进行筛选，以避免扫描冷分区。使用 BETWEEN 并指定较窄的窗口范围。
  • 按选择性对聚类键进行排序；靠前的键应匹配频繁的筛选和连接条件。避免在基数非常低的列上进行聚类。

• 查询计划优化：

  • 使用 EXPLAIN 和执行详情来发现倾斜的连接、大规模的数据重排（shuffle）或未被裁剪的扫描。
  • 通过 SELECT 列表和子查询尽早减少列的数量；BigQuery 是列式存储，能高效地丢弃未使用的列。
  • 对于大规模数据，优先使用近似聚合函数（例如，APPROX_QUANTILES）以在速度和成本之间进行权衡。

  • 当摄取源可能重复发送事件时，使用窗口函数进行去重：

undefined

• 连接与反规范化：

  • 将连接键同时设为聚类键（Co-locate），以减少数据重排。对于极端倾斜，布隆过滤器（Bloom filters）或预聚合可以提供帮助。
  • 将小的、缓慢变化的维度反规范化到事实表中，以避免热连接。对于频繁更新的宽维度表，应进行规范化，并依赖聚类键和物化连接。

• 工作负载管理、槽、版本和自动扩缩：

  • 按需模式（On-demand）：BigQuery 按查询弹性扩展计算资源；您按扫描的 TB 数付费。通过设置计费的最大字节数和分区裁剪来控制成本。
  • 基于容量的模式使用 BigQuery 版本（Standard、Enterprise、Enterprise Plus）和槽预留。购买基准承诺，创建预留，并将项目或文件夹分配给它。自动扩缩可以在高峰期增加槽，在需求下降时释放它们；为 ETL 和 BI 使用独立的预留，以防止相互干扰。
  • 作业优先级：交互式（默认）用于低延迟场景；批处理用于数据回填和计划查询。批处理作业会排队，直到预留或服务中有可用空闲容量时，再以正常成本运行。

• 并发与配额：

  • 使用预留和分配来隔离关键工作负载。对于混合租户，将他们放置在具有定制并发限制的不同预留或项目中。
  • 为作业添加标签以便进行归因分析；监控 INFORMATION_SCHEMA.JOBS 和 Cloud Monitoring 指标，以了解槽利用率和排队延迟。

• BI 缓存与数据新鲜度：

  • 查询结果缓存可改善相同查询的延迟和成本；对于需要亚小时级新鲜度的客户端，应禁用此功能。一些 BI 工具会独立缓存数据——禁用报表缓存以显示最新结果。

数据摄取、联合查询与恢复

• 加载作业：

  • 从 Cloud Storage 进行批量加载（首选 Avro/Parquet）是可靠且经济高效的方式。明确设置 schema 和编码；不匹配的 CSV 编码是导致字节级差异的常见原因。
  • 使用分区装饰器或直接加载到分区表以避免合并操作。对于大规模加载，按分区进行并行化。

• 流式摄取与 Storage Write API：

  • 旧版的流式插入（legacy streaming inserts）虽然简单，但配额更严格，并且可能在几秒钟内表现出最终一致性；对最新数据进行时间旅行可能会有延迟。
  • Storage Write API 是推荐用于高吞吐、低延迟写入的路径，它提供了更好的去重控制。使用幂等性（流偏移量）来防止重复数据。
  • 应用程序设计应能容忍在途事件（in-flight events）：根据预期的可用性（例如，观测到的延迟的 2 倍）延迟交互式查询，或在摄取时间分区上使用水印（watermarks）。

• Dataflow 与死信设计：

  • 对于合作伙伴提供的包含格式错误行的 CSV 文件，使用 Dataflow 进行解析和验证，将有效记录通过 Storage Write API 写入 BigQuery，并将错误路由到死信表以供检查。
  • 大规模读取 BigQuery 数据时，优先使用基于查询的读取（fromQuery），以仅选择必要的字段并减少数据重排。

• 计划查询与转换：

  • 使用计划查询进行 ELT 转换、增量汇总和表维护。优先写入分区和聚类的目标表。计划查询默认为批处理优先级，并与预留集成。

• 通知与可观测性：

  • 通过日志接收器（log sink）将 BigQuery 审计日志导出到 Pub/Sub，以触发针对特定表插入作业的警报：
    • 筛选器示例：

undefined

• 使用 Cloud Logging 审计日志和 INFORMATION_SCHEMA 视图来发现使用模式并实施治理。

• 时间旅行、快照与克隆：

  • 时间旅行（Time travel）允许您查询某个先前时间点的表（默认为 7 天）。使用 FOR SYSTEM_TIME AS OF 来读取过去的状态。
  • 表快照（Table snapshots）通过写时复制（copy-on-write）捕获一个时间点视图；可用于一致性数据回填或恢复。表克隆（Table clones）提供近乎即时的元数据副本，用于开发或“假设”分析，在数据发生分歧前存储成本极低。
  • 恢复选项：
    • 小错误：使用时间旅行查询并通过 INSERT…SELECT 进行恢复。
    • 大规模恢复：从快照或克隆创建表，然后进行交换。
  • 设置表和分区的过期时间以强制执行保留策略；验证保留策略与时间旅行的需求是否一致。

• 联合数据源：

  • 对于轻量级连接，使用 Cloud SQL 联合查询；对于持续的分析或大规模扫描，应安排提取-加载作业将其导入到原生表中。
  • 基于 Cloud Storage 中 Parquet/ORC 文件的 BigLake 表可以强制执行策略标签（policy tags）并下推过滤器和列投影；但其延迟仍会高于原生存储。

← 数据存储、数据湖与文件格式 · 所有领域 · 使用 Dataflow 和 Apache Beam 进行流处理 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Google →