Google PDE: 数据存储、数据湖与文件格式 — 学习指南

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

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

概览

Google Cloud 上的数据存储涵盖了原始对象存储、精选数据湖以及为分析优化的格式。要构建可靠、受治理且高性能的数据湖，需要在存储类别、存储桶设置、位置、文件格式、表布局和生命周期方面做出审慎的选择。本节详细介绍了设计上的权衡、需要避免的故障模式，以及与大规模 BigQuery、Spark 和流式处理管道相适应的模式。

Cloud Storage 基础：类别、存储桶、一致性和生命周期

Cloud Storage 是用于存储原始文件和精选文件的持久、高可用的基础。

存储类别
- Standard (热)：频繁访问，延迟最低。无最短存储期限。
- Nearline (冷)：不频繁访问（约每月一次）。最短存储 30 天；会产生检索费用。
- Coldline (更冷)：不频繁访问（约每季度一次）。最短存储 90 天；检索费用更高。
- Archive (最冷)：长期保留（约每年一次）。最短存储 365 天；检索费用最高。
- Autoclass 可以自动在不同类别之间转换；请确认提前删除费用和访问模式不会侵蚀节省的成本。
存储桶位置和复制
- 区域：最适合在单一地理区域内实现数据局部性和合规性。
- 双区域：两个配对区域，具有自动复制功能；涡轮复制可快速提交副本，RPO 以分钟为单位；是低 RPO 灾难恢复的理想选择。
- 多区域：在同一大洲内进行地理分布，以实现广泛的可用性、内容分发以及跨越大范围区域的分析。
- 选择位置时需满足数据驻留法规，并最大限度地减少到计算资源（Dataproc、Dataflow、BigQuery 外部表）的出口流量/延迟。
一致性和语义
- Cloud Storage 提供强大的全局写后读、元数据更新后读和列表写入后读一致性。
- 对象写入是原子且不可变的；“重命名”是一种复制+删除模式。设计时应考虑幂等复制并验证校验和，以防止部分迁移。
访问模式和性能
- 并行复合上传和可续传上传可提高大文件的吞吐量。
- 范围读取可实现高效的列式页脚和选择性读取。
- 避免使用大量小文件（<8 MB），这会增加元数据/列表开销；应将它们批量处理或压缩成更大的对象。
- GZIP 不可分割，无法进行分布式读取；对于可扩展的处理，优先选择 Parquet/ORC/Avro+Snappy。
生命周期、保留和版本控制
- 存储桶级别的保留策略和对象保留（基于事件或临时）可强制实施不可变性，以满足合规性要求并减少意外删除。
- 对象版本控制会保留先前的世代；有助于从覆盖/删除中恢复。请监控存储成本的增长。
- 生命周期规则可自动执行转换和删除操作。示例 (JSON)，将较旧的数据移至更冷的存储层，并在一年后删除： { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
- 故障模式：如果转换过于激进，会产生提前删除费用；保留锁定无法缩短；无压缩的版本控制会增加成本。
传输和迁移
- 使用 Storage Transfer Service 进行从本地或其他云的并行化、带检查点的移动；使用 Transfer Appliance 进行离线 PB 级数据传输。
- 使用 CRC32C/MD5 和世代匹配前提条件验证完整性，以防止竞争条件。
- 优先使用带有 -m（并行）和校验和的 gsutil/gcloud storage；对于大容量入口流量，避免 SFTP 瓶颈。

使用 BigLake 和 Dataplex 实现统一的数据湖治理

BigLake 和 Dataplex 实现了跨文件和表的安全与治理的标准化。

BigLake
- 将 Cloud Storage 数据作为 BigQuery 管理的表（外部）公开，具有统一的精细访问控制，包括行级访问策略和列级策略标签。
- 对 Parquet/ORC 启用列裁剪和谓词下推，从而减少扫描的字节数和到 BigQuery、Dataproc 上的 Spark 以及 Dataflow 等引擎的出口流量。
- 通过 Cloud Logging 实现集中审计和中央策略执行；为数据湖文件和仓库表提供单一控制平面。
Dataplex
- 将数据组织成湖、区（原始、精选、可信）和资产（存储桶、数据集）；管理元数据、沿袭和数据质量规则。
- 与用于敏感列的策略标签集成，并通过在湖/区/资产范围内的 IAM 支持最小权限。
- 在多团队环境中鼓励标准化的命名、分区和模式管理，以避免“垃圾抽屉”现象。
治理模式
- 实施每租户一数据集和每区一存储桶的模式；避免跨租户数据泄露。
- 对 PII 使用行级访问策略和列策略标签。将 API 访问限制在经批准的身份。
- 使用 Cloud Logging 审计访问；将过滤后的日志路由到 Pub/Sub 以进行实时监控。

文件格式、压缩与查询行为

选择正确的文件格式对成本和性能有直接影响。

列式格式 (Parquet, ORC)
- 优点：列裁剪、谓词下推、每列独立的编码和压缩、统计信息以及可拆分的文件。
- 权衡：写入时 CPU 开销更高；必须谨慎管理 schema 演进（例如，添加列是安全的；更改类型有风险）。
- 压缩：Snappy 速度快，ZSTD 在支持的情况下压缩比更高。除非互操作性约束要求，否则应避免对列式格式使用 GZIP。
面向行的 Avro
- 优点：支持强类型的 schema 演进、块级压缩、可拆分；非常适合流式数据的落地和交换区。
- 权衡：分析扫描效率低于列式格式；在治理区中转换为 Parquet/ORC。
CSV 和 JSON (半结构化)
- CSV：人类可读，当值为简单类型时开销最小；缺少 schema、类型和一致的转义规则；大规模解析时成本高昂。
- JSON：自描述且灵活；可扩展的分布式读取需要使用换行符分隔的 JSON；冗长且解析时 CPU 密集。
- 尽可能先落地原始 CSV/JSON，然后验证并转换为 Avro/Parquet 用于分析。
BigQuery 外部表和 BigLake 表
- Parquet/ORC 外部表受益于谓词下推和列裁剪；CSV/JSON 通常不支持，导致扫描字节数更高。
- 压缩的 CSV (GZIP) 外部表无法在多个 worker 之间拆分；预计读取速度会较慢。
- 示例：创建一个使用 Hive 风格分区的 Parquet BigLake 表： CREATE EXTERNAL TABLE lake.sales WITH CONNECTION us.biglake_conn OPTIONS ( format = ‘PARQUET’, hive_partitioning_mode = ‘AUTO’, hive_partitioning_source_uri_prefix = ‘gs://corp-raw/sales/’, uris = [‘gs://corp-raw/sales/date=/region=/part-*.parquet’] );

布局、分区、性能工程、驻留和迁移

对象布局和分区
- 采用 Hive 风格的路径进行分区和聚类键设置： gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
- 将单个文件大小保持在 128–1024 MB 范围内，以平衡并行度和任务开销。避免每个分区包含数百万个文件。
- 通过以下方式缓解小文件问题：
  - 在客户端批量上传。
  - 在非高峰时段使用 Dataflow/Spark 压缩作业来合并小文件。
  - 归档原始小文件，仅向分析系统提供压缩后的数据。
BigQuery 分区和聚类
- 按注入时间或高基数过滤列（例如 event_date）进行分区。避免过度分区（例如按分钟分区），这会导致元数据爆炸。
- 按常用过滤/排序的维度（最多四个）进行聚类。聚类可增加数据局部性并减少扫描字节数。
- 对于重度交互式分析，优先使用原生 BigQuery 表；对于受治理的数据湖访问、跨引擎共享和成本隔离，则使用 BigLake/外部表。
查询性能影响
- 列式格式可显著降低外部扫描成本；CSV/JSON 外部表通常需要全文件扫描。
- 一致性保证消除了在读取 Cloud Storage 时人为设置延迟的需要，但下游系统（例如 BigQuery 流式插入）可能会出现短暂的数据可见性延迟——在需要时应使用水位线或读取延迟进行设计。
驻留、持久性和恢复
- 选择存储桶/数据集位置以满足驻留约束；将计算资源部署在同一位置以减少出口流量和延迟。
- 使用双区域和 Turbo Replication 以实现低 RPO；使用版本控制和保留策略以从人为错误和勒索软件中恢复。
- 对于灾难恢复（DR），使用存储桶复制功能将存储桶复制到单独的项目/区域，并使用独立的 IAM 边界进行保护。
安全迁移和验证
- 规划多阶段迁移：种子传输（批量传输）、增量同步（基于 mtime/窗口化复制）、切换（源设为只读）和切换后验证。
- 通过校验和、计数、字节总数和抽样解码进行验证。对于表格数据，比较行数和哈希聚合值：

undefined

使用前置条件（ifGenerationMatch）来防止并行复制期间的覆盖。通过版本控制或保留源数据来保留回滚窗口。
迁移后，根据新的访问模式启用生命周期管理和 Autoclass；在验证通过之前，避免启用保留锁定。

实际问题场景

Acme Retail 每天从一个物流合作伙伴处接收 CSV 文件，这些文件被投放到一个区域级 Cloud Storage 存储桶中。文件偶尔包含格式错误的行。Acme 必须接收、验证、转换为适合分析的格式，并加载到 BigQuery 中以支持近实时仪表板，同时保留错误行以供检查并强制执行治理。

方法：

在 Dataplex 中接收和治理原始数据
- 创建一个 Dataplex 数据湖，其中包含一个映射到 gs://acme-raw/logistics/ 的原始区域（raw zone）资产。
- 理由：集中进行治理、元数据和血缘关系管理。在区域（zone）级别强制执行 IAM，并使用策略标记（policy tags）标记敏感字段，以便在下游强制执行。
强制执行生命周期和保留策略
- 在 acme-raw 存储桶上应用 30 天的保留策略，并启用对象版本控制。
- 理由：防止合作伙伴意外覆盖/删除；短期保留策略平衡了成本和可恢复性。版本控制有助于回滚错误的交付。
使用 Dataflow 批处理管道进行验证和注入
- 通过对象完成通知（object finalize notifications）触发每日的 Dataflow 作业。使用 schema 读取 CSV 并进行逐条记录验证；将有效记录写入 BigQuery 暂存表（按 event_date 分区），并将解析/验证错误路由到死信（dead-letter）BigQuery 表。
- 理由：Dataflow 提供可扩展的并行解析和强大的死信处理能力，分析师可以借此检查错误行。这反映了处理异构质量 CSV 的最佳实践。
在策管区域（curated zone）中压缩并转换为 Parquet 格式
- 同一管道将经过验证的数据以大小约为 256–512 MB 的 Parquet 文件形式写入 gs://acme-curated/logistics/date=YYYY-MM-DD/。
- 理由：Parquet 在 BigQuery 和 Spark 中支持列裁剪和谓词下推，从而减少扫描字节数并改善延迟；文件压缩缓解了因合作伙伴交付模式造成的小文件开销。
通过 BigLake 提供受治理的分析
- 在策管的 Parquet 路径上创建一个 BigLake 外部表，并启用 Hive 自动分区；应用列级策略标记和行访问策略以实现合作伙伴特定的筛选。
- 理由：通过集中审计，在 BigQuery 和 Spark 之间实现统一的细粒度访问。分区裁剪减少了按日期筛选时的扫描成本。
将关键聚合数据加载到原生 BigQuery
- 对于热门仪表板，运行一个计划的 BigQuery 作业，将策管的 Parquet 外部表中最近 N 天的数据注入到一个原生的、经过聚类和分区的表中。
- 理由：原生存储可加速高并发 BI，而外部 BigLake 表则作为受治理的记录系统（system-of-record），用于更广泛的访问。
使用 Cloud Logging 和 Pub/Sub 进行监控和告警
- 创建一个日志接收器（log sink），将 Dataflow 和 BigQuery 加载作业的结果筛选到 Pub/Sub；与监控工具集成，以便在发生故障或错误行率升高时立即发出警报。
- 理由：无需轮询即可获得针对特定表的操作可见性；支持 SRE 实践。
优化存储类别和驻留位置
- 将策管的 Parquet 文件在 Standard 存储中保留 14 天，30 天后通过生命周期规则转换到 Coldline；将原始和策管存储桶都存储在与 BigQuery 数据集相同的区域，以避免出口流量费用。
- 理由：平衡了热数据读取性能与成本。同地部署可保持合规性，并最大限度地减少延迟和出口费用。
验证端到端数据质量
- 每次运行后，比较暂存表、策管外部表和原生 BigQuery 表之间的计数和哈希聚合值；隔离异常情况。
- 理由：及早发现 schema 变更或注入回归问题；加密或指纹哈希无需完全重新扫描即可提供轻量级保证。