Google PCA: 数据存储、数据库与分析架构 — 学习指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

概述

在 Google Cloud 上设计数据存储、数据库和分析时，需要将工作负载模式与服务相匹配，同时规划持久性、可用性、访问控制、成本和运营弹性。本节涵盖对象存储和生命周期治理；运营型数据库和缓存；分析型数仓和处理；数据注入架构；以及治理、保护和性能方面的实践。本节重点阐述了设计选择、运营考量以及常见的故障模式或权衡。

存储和对象架构

Cloud Storage 存储桶设计

位置：对于低延迟、成本敏感的工作负载，选择区域 (region)；为实现具有可预测故障切换的业务连续性，选择双区域 (dual-region)；为实现全局读取访问，选择多区域 (multi-region)。双区域提供可选的 Turbo Replication，可实现有 SLA 支持的低 RPO；否则，复制是异步的。
命名空间和分离：为不同的数据域、环境和敏感度级别使用独立的存储桶。采用统一的存储桶级访问权限和公共访问权限阻止策略，以确保权限的一致性。
存储类别：Standard 用于热数据；Nearline 用于不常访问（每月）的数据；Coldline 用于季度性访问的数据；Archive 用于长期保留。Autoclass 可以用最少的运营工作自动优化存储类别的放置。
生命周期策略：根据存在时间、存储类别或对象前缀自动执行转换和删除操作。例如，删除超过 90 天的对象： { “rule”: [ { “action”: {“type”: “Delete”}, “condition”: {“age”: 90} } ] } 使用以下命令应用： gsutil lifecycle set lifecycle.json gs://my-bucket
保留和合规性锁定：配置存储桶保留策略，并可选择锁定它们以防止缩短保留期（用于合规）。基于事件的锁定和对象版本控制可以从意外删除或覆盖中恢复数据。
复制：选择双区域以在 API 层面获得同步一致性语义，并在两个区域之间进行后台复制；使用存储桶到存储桶的复制（用于跨项目或跨位置的副本）来满足特定的 RPO/RTO 或职责分离要求。

故障模式和权衡

存储类别不匹配会增加成本和延迟。Autoclass 可以减少这种情况，但会增加每个对象的管理开销。
保留锁定是不可逆的；请在非生产环境中测试策略。
复制提高了持久性，但可能会增加写入延迟和成本；应针对特定位置设计读/写路径。

模式

数据湖：在 Cloud Storage 上建立原始数据区和治理数据区；通过 Dataplex 进行治理；在 Data Catalog 中管理外部化 schema。
归档：使用带有保留锁定的 Archive 类别以满足合规性要求，并结合 BigQuery 外部表或按需恢复来进行罕见的分析。
Lakehouse：使用 BigLake 统一对 Cloud Storage 和 BigQuery 的访问，并提供一致的安全性。

业务数据存储与缓存

Cloud SQL

高可用性：通过同步复制到备用实例实现区域级 HA；自动故障切换通常在几秒到几分钟内完成。实例端点保持不变，最大限度地减少应用更改。
只读副本：区域内或跨区域，异步复制；适用于读取横向扩展和灾难恢复 (DR)。监控复制延迟；过时读取会影响正确性。
备份与 PITR：计划备份加上使用事务日志进行时间点恢复（通常窗口期最长 7 天，具体取决于引擎）。定期测试恢复。
私有连接：通过 VPC 对等互连使用私有 IP，可降低暴露风险和延迟；规划 IP 范围以避免重叠。
迁移：Database Migration Service 支持从本地或其他云进行低停机时间迁移；对于高流量链路，优先选择 Dedicated Interconnect 或 Partner Interconnect 而非 VPN，以减少丢包和延迟。

权衡与故障模式

HA 故障切换会重置连接；应用程序必须采用退避策略重试。维护窗口期间性能可能会短暂下降。
长时间运行的事务会增加复制延迟和 PITR 恢复时间。
过度预配存储是一种廉价的保险；IOPS 配置不足会在峰值时导致潜在故障。

Cloud Spanner

全球规模与一致性：使用 TrueTime 和两阶段提交实现跨区域的强一致性读/写。选择区域级配置以获得最低的写入延迟；选择多区域配置以获得更高的可用性和全球读取能力。
事务：跨行和跨表的外部一致性与完全 ACID 特性；只读事务可在副本间扩展。
架构设计：选择能避免热点的主键；使用交错表以实现数据局部性；考虑二级索引的写入放大和回填行为。
区域性：主导区域的位置决定了写入延迟；多区域配置会增加法定数量成本和提交延迟。

权衡

写入延迟随地理覆盖范围的扩大而增长；除非高可用性和全球分布的需求证明其合理性，否则应避免使用多区域配置。
基准成本高于单节点虚拟机数据库；容量规划必须与服务等级目标 (SLO) 和增长预期保持一致。

Firestore、Bigtable、Memorystore 及选型

Firestore：适用于移动/Web 后端的文档数据库；对单个文档提供强一致性；细粒度的安全性；自动索引。注意频繁更新文档上的争用问题；使用分布式计数器和批量写入。
Bigtable：宽列数据库，支持 PB 级规模、超低延迟的时间序列和物联网场景；设计行键以避免热点（例如，哈希或加盐）；通过节点和集群进行扩展；使用多集群路由实现高可用性。复制是异步的；强一致性是集群级别的。
Memorystore for Redis：内存缓存；基本层级是单实例（无 HA）；标准层级提供副本和自动故障切换（可能出现短暂断连）。应将其视为缓存，而非事实来源；持久化特性可降低易失性，但不能替代数据库备份。

基于工作负载的选型

需要联接/ACID 和中等规模的关系型数据库：Cloud SQL。
需要水平扩展和外部一致性的全球关系型数据库：Cloud Spanner。
高吞吐量的时间序列/遥测数据或超大规模键值存储：Bigtable。
以应用为中心的文档模型，支持分层查询：Firestore。
临时加速和速率限制：Memorystore。

分析、注入与处理

BigQuery

数据集 (Datasets)：逻辑上的安全和计费边界；按业务领域和生命周期阶段采用命名约定。
分区 (Partitioning)：基于注入时间或列进行时间过滤；也支持整数范围分区。对 event_ts 字段使用时间单位分区以裁剪扫描。
聚类 (Clustering)：最多可对四个列进行聚类，将相关数据共同存放在存储中；可提高选择性查询的性能并降低成本。
预留 (Reservations)：通过预留和分配来管理专用槽；使用弹性槽进行突发性实验；隔离关键工作负载以避免资源饿死。
访问控制：项目和数据集级别的 IAM；通过行级策略和策略标签实现表/列控制；通过授权视图和例程共享经过整理的数据。

实用示例： bq mk –dataset myproj:analytics bq mk –table –time_partitioning_field=event_ts –clustering_fields=user_id,device_type myproj:analytics.events ./schema.json

权衡与故障模式

不佳的分区策略会导致全表扫描和失控的成本。
仅当筛选或联接条件包含聚类列时，聚类才有效；频繁的数据重组会降低其效益。
槽位配置不足会导致作业排队；过度配置则会增加成本。监控槽位利用率和溢出到磁盘的 shuffle 数据。

数据注入与处理

Pub/Sub：全球性、持久、至少一次交付；排序键可强制实现按键排序，但这会带来吞吐量上的权衡。设计幂等的消费者。
Dataflow：统一的批处理和流处理，具备自动扩缩、精确一次有状态处理、窗口化和触发器功能；Streaming Engine 可分流状态管理。使用死信主题和可重放的数据源。
Dataproc：托管的 Spark/Hadoop 服务，适用于现有代码和生态系统；支持临时集群或自动扩缩；当需要使用特定 ML 库或移植成本高昂时可采用。

批处理与流处理的权衡

流处理可降低延迟并支持实时分析，但会增加复杂性（状态管理、水印、延迟数据）和持续成本。
批处理简化了正确性保证和成本控制；在服务等级协议 (SLA) 容忍延迟的情况下是可接受的。
混合模式：将原始事件落地到 Cloud Storage，将聚合后的 KPI 流式传输到 BigQuery，并运行夜间批处理重计算以确保准确性。

数仓模式

数据仓库 (Warehouse)：将 BigQuery 作为分析系统；使用物化视图和计划查询为 BI 提供服务。
湖仓一体 (Lakehouse)：在 Cloud Storage 中以开放格式管理数据；通过 BigLake 将其暴露给 BigQuery，并实现一致的安全性。

治理、保护和性能

数据治理与安全

元数据和沿袭：使用 Data Catalog 管理技术和业务元数据；启用从 Dataflow、BigQuery 和 Dataproc 捕获沿袭以追踪依赖关系。
质量：使用 Dataplex 数据质量功能强制执行规则，并在 Composer 或 Dataform 中编排检查；隔离不良记录。
访问边界：围绕 BigQuery 和 Cloud Storage 设置 VPC Service Controls 以降低数据渗漏风险；使用 IAM Conditions 实现上下文感知访问；使用 CMEK 进行加密控制；使用策略标签实现列级限制。
保留：使 Cloud Storage 存储桶保留策略、BigQuery 表时间旅行（可配置长达 7 天）以及数据集/表过期时间与法律要求保持一致。

备份、PITR 和删除保护

验证备份：定期将 Cloud SQL 和 Spanner 备份恢复到隔离环境中，并运行校验和及应用级验证。
Bigtable：启用 PITR 以便能恢复到所配置保留期内的任一时间戳；测试表级或集群级恢复。
Spanner：使用备份进行灾难恢复；在版本保留期内利用过时读取（stale reads）进行审计查询。
Cloud Storage：启用对象版本控制和存储桶保留锁定，以防止意外删除；复制到独立的项目以隔离操作员错误。
BigQuery：使用时间旅行和表快照；通过要求审批和设置数据集级删除保护，避免在生产数据集上执行删除操作。

数据性能和成本控制

避免热键：分散 Bigtable 行键（使用哈希前缀），选择能随机化领导者选举的 Spanner 主键，对 Firestore 计数器进行分片。
索引：维护必要的 SQL 和 NoSQL 索引；在 BigQuery 中，基于常用过滤器进行聚类；在 Cloud SQL 中，监控慢查询并定期对 Postgres 执行 vacuum/analyze。
容量规划：通过负载测试建立基线；设置 SLO 和错误预算；监控 BigQuery 槽利用率、Bigtable CPU/读-改-写延迟、Cloud SQL CPU/IOPS 以及 Pub/Sub 积压。
成本控制：对稳定工作负载使用 BigQuery 槽承诺，对 Cloud Storage 使用 Autoclass，压缩 Bigtable 表并调整布隆过滤器，使旧分区和数据集过期，并实施按团队的预算和警报。

实践问题场景

Acme 零售集团需要一个统一的、低延迟的点击流和订单分析平台。需求：10 秒内提供实时 KPI，支持对五年内的数据进行 SQL 历史分析，恢复目标小于一小时，严格要求数据驻留在美国，并防止意外数据丢失。

落地原始事件并实现持久化注入

在 us-central1/us-east1 创建双区域 Cloud Storage 存储桶，用于存放原始区和策展区的数据；在原始区启用 Autoclass 和对象版本控制。
基本原理：双区域满足持久性和驻留性要求；版本控制可防止错误的数据回填；Autoclass 自动优化存储成本。

使用 Pub/Sub 和 Dataflow 可靠地流式传输事件

将点击流和订单事件发布到 Pub/Sub 主题，并按 user_id 设置排序键；实施一个 Dataflow 流水线，用于验证、去重、丰富数据，并将输出分支到 BigQuery（用于热门 KPI）和 Cloud Storage（在策展区存放 parquet 文件）。
基本原理：Pub/Sub 提供全局、持久化的至少一次交付；Dataflow 提供精确一次的状态处理和自动扩缩；分支输出维持了一种湖仓一体（lakehouse）模式，便于数据再处理。

在 Bigtable 和 Redis 中提供实时特征

将一部分丰富后的事件写入 Bigtable，行键采用加盐的 user_id#timestamp 格式；使用 Memorystore for Redis 作为前端缓存，用于缓存最近的会话。
基本原理：Bigtable 为时间序列数据提供低延迟、高吞吐量的写入；加盐可避免热点；Redis 为实时个性化推荐降低了尾部延迟。

在 BigQuery 中构建数仓并优化查询

创建按 event_date 分区、并按 user_id 和 channel 聚类的数据集。使用物化视图生成 KPI，并为小文件加载安排定期合并操作；购买基线槽预留，并带少量弹性槽缓冲区以应对突发流量。
基本原理：分区和聚类可以裁剪扫描，从而降低成本；物化视图可加速仪表板；预留可以限制成本，并保护关键工作负载免于排队。

治理访问并防止数据渗漏

为分析师组应用数据集级别的 IAM；使用策略标签限制 PII 列的访问，并为供应商访问提供授权视图。在 BigQuery 和 Cloud Storage 周围强制执行 VPC Service Controls；对受监管的数据集使用 CMEK。
基本原理：在数据集和列级别实现最小权限；VPC SC 降低了数据渗漏风险；CMEK 满足了加密控制的要求。

实施备份、PITR 和恢复测试

为 Bigtable 启用 7-14 天的 PITR；为事务性订单存储（如 Spanner 或 Cloud SQL）创建每周备份；每日快照 BigQuery 关键表，并依赖时间旅行来纠正错误。每季度在隔离的项目中进行恢复演练。
基本原理：分层的恢复选项可应对逻辑错误和灾难；定期的演练可验证 RPO/RTO 和操作手册。

控制数据保留和生命周期

应用生命周期规则，在 30 天后清除原始对象，在五年后清除策展区数据；锁定一个满足合规性要求的存储桶级保留策略。为临时数据集设置 BigQuery 数据集/表的默认过期时间。
基本原理：自动强制执行可降低操作风险；保留锁定可防止意外或未经授权的策略削弱。

监控性能和成本，并缓解热点

跟踪 BigQuery 的槽利用率、扫描字节数和 BI 查询并发度；监控 Bigtable 的 CPU 和读-改-写延迟；对 Pub/Sub 积压设置警报。如果出现以 user_id 为基础的热点，增加盐的宽度并通过 Dataflow 回填键。
基本原理：持续的遥测能及早发现瓶颈；主动的键策略变更可在不进行大规模重构的情况下保持 SLO。

提供私有连接和隔离

对于混合云依赖，使用 Partner Interconnect 或 Dedicated Interconnect 配合 Cloud Router；确保 IP 范围不重叠；使用 Private Service Connect 连接托管服务端点。
基本原理：私有路径可减少延迟和丢包；清晰的 IP 规划和 PSC 可强制实现隔离和可预测的路由。