Google ACE: 存储、数据库和数据服务 — 学习指南

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

概述

本节为 Google Cloud 存储、数据库和分析数据服务提供了一个以实际操作为重点的参考。内容重点介绍配置模式、访问控制、持久性机制、性能和成本特性以及安全恢复实践。其目标是帮助您针对给定的工作负载决定使用哪种服务，理解操作上的权衡，并预见常见的故障模式。

Cloud Storage 设计、访问、生命周期和保护

Cloud Storage 是用于存储非结构化数据和备份的持久、高可用的对象存储。

• 存储桶和对象：存储桶是位于某个位置（区域、双区域或多区域）的全局命名空间，其中包含不可变的对象版本。选择存储桶位置时应考虑尽量减少出站流量并满足数据驻留要求。
• 存储类别：根据访问频率使用 Standard（热）、Nearline（至少约 30 天）、Coldline（至少约 90 天）和 Archive（至少约 365 天）。对于灾难恢复备份，Coldline 是一个常见的默认选项。您可以在一个存储桶内为不同对象混合使用各种存储类别。
• 生命周期规则：通过 Age、CreatedBefore、MatchesStorageClass 和 NoncurrentVersion 等条件自动执行转换和删除操作。例如，在 90 天后转换为 Coldline 并在 365 天后删除：
  1. lifecycle.json:

undefined

2. 应用规则：

undefined

• 保留策略和合规保留：保留策略可防止对象在指定期限结束前被删除或修改；锁定策略是不可逆的操作。合规保留是针对单个对象的，必须先清除才能删除对象。

访问控制和共享：

• 统一与精细：优先使用统一存储桶级访问 (UBLA)，仅通过 IAM 管理权限。精细访问（对象 ACL）是旧版功能，会使可审计性和权限传播变得复杂。启用 UBLA 会禁用 ACL，并可能立即影响依赖 ACL 的现有集成。
• 签名 URL：对于无需 Google 身份的短期访问，请使用签名 URL。通过 IAM 签名来避免使用服务账号密钥文件：

undefined

确保该服务账号自身拥有“服务账号令牌创建者”角色，或通过签名者角色获得该权限。

• 加密：默认启用服务器端加密；当您需要控制密钥和审计跟踪时，可在存储桶或单个对象范围启用 CMEK。监控 KMS 密钥的可用性和轮替；CMEK 不可用将阻止上传和解密操作。
• 版本控制：启用对象版本控制，以便在覆盖或删除后保留非当前版本。结合生命周期规则来过期非当前版本，以控制存储增长。当存在大量版本时，请注意客户端的列出逻辑。

故障模式与缓解措施：

• 意外删除或覆盖：使用版本控制和保留策略。对于严格的合规性要求，请锁定保留策略。
• 公共访问配置错误：强制执行“公共访问权限阻止”和 UBLA。使用 Cloud Asset Inventory 和策略分析器定期进行审计。
• 成本超支：生命周期规则、对象级存储类别和“请求者付款”功能可减少意外费用。使用 Cloud Monitoring 指标和预算进行监控。

实用命令：

• 创建具有 UBLA 和保留策略的存储桶：

undefined

undefined

用于计算工作负载的块存储和文件存储

根据访问模式、性能需求以及对 Compute Engine 和 GKE 的持久性要求来选择存储。

• Persistent Disk (PD)：持久的块存储，可以是可用区级或区域级。类型包括：Standard (HDD) 用于顺序吞吐量；Balanced (pd-balanced) 和 SSD (pd-ssd) 用于低延迟和高 IOPS。区域级 PD 在可用区之间同步复制，从而实现更快的恢复。PD 可以创建快照、在线调整大小，并以只读模式挂载到多个虚拟机（读写模式下为单写入器）。
  • 权衡：SSD 的 IOPS 成本较高；HDD 性价比高，但随机 IO 延迟较高。区域级 PD 成本更高，但能降低 RTO。
• Local SSD：NVMe 或 SCSI 连接的临时存储，具有极高的 IOPS 和极低的延迟。虚拟机停止或主机维护时数据会丢失；仅将其用于临时缓存或已复制的数据。请在别处备份或复制数据以避免数据丢失。
• Filestore：用于实现 POSIX 共享文件语义的托管式 NFS。基本层级是可用区级的；企业及更高层级提供区域级高可用性 (HA)，具有同步复制和更高的 IOPS。非常适合 GCVE、HPC 暂存空间、媒体渲染以及需要共享文件锁定的应用。
  • 权衡：NFS 引入了客户端缓存和锁定语义；吞吐量和延迟因层级而异；不像 Local SSD 那样适合个位数微秒级延迟的小型随机 IO。

故障注意事项：

• 主机维护：Local SSD 数据会丢失；通过应用级复制来保护数据。
• 可用区中断：可用区级 PD 和基本层级 Filestore 会中断；使用区域级 PD 或 Filestore 企业版以实现高可用性。
• 快照一致性：要创建应用一致性的 PD 快照，需与文件系统冻结或数据库原生静默操作相协调，以避免出现崩溃恢复窗口。

托管数据库和数据服务

Cloud SQL (托管的 MySQL、PostgreSQL、SQL Server):

• 配置：选择机器规格、存储类型、连接方式（首选私有 IP）、若使用公共 IP 则需配置已授权的网络、维护窗口，以及用于性能诊断的 insights。使用连接池（例如 Cloud SQL Auth Proxy、PGbouncer）以避免超出连接数和 CPU 限制。
• 高可用性：区域级高可用性 (HA) 实例会在另一个可用区部署一个备用实例，并采用同步存储复制；故障切换是自动的。预计在故障切换期间会有短暂的写入不可用窗口。
• 副本：只读副本用于读取扩展和分流商业智能 (BI) 负载；外部复制用于迁移。监控副本延迟并设计幂等的读取器。
• 备份和 PITR：启用自动备份和二进制/WAL 日志记录以实现时间点恢复 (PITR)。定期测试恢复操作。

undefined

• 故障模式：长时间运行的事务会阻塞 vacuum/checkpointing；连接数激增会导致系统颠簸；如果配额不足，存储自动增长可能会停滞。为 CPU、内存、连接数、副本延迟和磁盘使用率设置告警。

Cloud Spanner:

• 规模和区域性：区域级或多区域实例，具有同步复制和全球强一致性。通过扩展节点来提升吞吐量和存储空间；领导者区域的位置会影响写入延迟。
• 架构和键：设计主键以避免热点；对于时间序列数据，使用带有哈希或随机前缀的复合键来分散写入负载。为查询模式使用二级索引，并考虑将频繁过滤的列存储在一起。保持事务简短且有界，以最大限度地减少锁争用。
• 事务：通过 TrueTime 实现外部一致性的强一致性分布式事务。写入延迟受法定数量 (quorum) 的限制；冲突会导致事务中止——使用退避策略重试。

Firestore 和 Bigtable:

• Firestore (Native 模式)：包含集合的文档存储，支持实时侦听器、每次事务最多可跨越 500 个文档的事务，以及文档读取和大多数查询的强一致性。最适合移动/Web 应用数据、分层 JSON 和事件驱动型应用。
• Bigtable：用于 PB 级规模和亚 10 毫秒延迟的宽列数据库。仅支持单行事务；设计行键以避免热点。是时间序列、物联网 (IoT)、个性化和大规模计数器的理想选择。不适用于即席连接或复杂聚合。

Memorystore:

• Redis 和 Memcached：用于实现微秒到毫秒级延迟的内存中缓存。基本层级不提供高可用性 (HA)；标准层级为 Redis 提供带自动故障切换的区域级高可用性。应视为临时存储；不要用作记录系统 (system of record)。

BigQuery:

• 数据集和表：按数据集组织；在项目、数据集、表、列和行级别控制访问。使用分区表和集群表来控制扫描的字节数和成本。
• 加载和查询作业：从 Cloud Storage、Cloud SQL 导出或流式插入加载数据。使用空运行 (dry run) 来估算成本：

undefined

• 访问控制：为只读使用者在数据集范围内授予 BigQuery Data Viewer 角色；使用授权视图或行级/列级安全性来实现最小权限原则。

数据移动、迁移、验证和运营权衡

迁移和传输：

• Database Migration Service (DMS)：用于通过复制将同构数据库以最小停机时间迁移到 Cloud SQL。通过延迟指标和校验和比较来验证切换。
• Cloud Storage 传输：Storage Transfer Service 用于重复性或事件驱动的传输；gsutil -m rsync 用于带校验和的一次性同步复制；Transfer Appliance 用于大规模离线迁移。
• 导入/导出：Cloud SQL 可导出到 Cloud Storage；重新导入支持 PITR 引导和数据验证。BigQuery 支持从 Cloud Storage 批量加载，并可导出为 Avro/Parquet 格式供下游使用。
• 验证：使用对象校验和 (CRC32C)、行数、抽样查询和应用层不变量。对于 BigQuery，比较源和目标之间 GROUP BY 的计数或哈希值。

性能、可用性、容量和成本的权衡：

• Cloud Storage：通过将计算资源共置来优化出口流量；根据访问频率选择存储类别；使用双区域/多区域以实现跨可用区恢复能力和更高的可用性，但存储成本也更高。
• PD/Filestore：SSD 用于低延迟 IO；HDD 用于高吞吐量；区域级复制用于 HA；合理规划 IOPS 以避免限流。
• Cloud SQL：垂直扩展简单但有限；只读副本分担读取流量；HA 增加了可用性但未增加读取容量；存储类别影响延迟和成本。
• Spanner：以强一致性水平扩展；其较高的成本被全局 RPO/RTO 和简化的分片所抵消。写入操作对键设计和主副本区域延迟很敏感。
• Firestore/Bigtable/Memorystore：根据延迟、数据模型和一致性进行选择。内存中缓存可减少数据库负载，但增加了缓存失效的复杂性。
• BigQuery：按需付费的成本与扫描的字节数成正比；分区/聚类和谓词下推可减少开销。固定费率预留以承诺换取成本的可预测性。

故障排查和安全恢复：

• Cloud Storage：使用对象版本控制和保留策略进行恢复；检查 Cloud Logging 数据访问日志以审计读/写事件；确保在恢复期间启用了 CMEK 密钥。
• PD/Filestore：从快照或备份中恢复；运行 fsck 和数据库恢复模式；在创建快照前通过应用层静默来确保一致性。
• Cloud SQL：为实现 PITR，恢复到一个新实例以避免主实例数据丢失；通过只读测试进行验证；维护防火墙和私有 DNS 以实现安全的切换模式。
• Spanner/Bigtable：通过键访问倾斜调查热点问题；使用 Monitoring 跟踪延迟和限流；为中止的事务或被速率限制的操作实现退避和重试。
• BigQuery：通过执行详情诊断慢查询；添加分区和聚类；限制 SELECT *；在适当时机物化中间结果。在时间旅行窗口内通过恢复快照或从快照时间点复制来恢复已删除的表。

实际问题场景

Contoso Retail 正在整合备份和分析数据，同时加强访问控制并为其事务系统启用时间点恢复 (PITR)。他们需要：存储具有自动分层功能的应用备份，向第三方提供短期文件共享，为小型关系型工作负载启用 PITR，并在执行前估算分析查询的成本。

方法：

1. 创建一个启用了 UBLA、保留策略和生命周期的区域级 Cloud Storage 存储桶。

   • 命令： gcloud storage buckets create gs://contoso-backups –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://contoso-backups –retention-period=365d gsutil lifecycle set lifecycle.json gs://contoso-backups
   • 理由：UBLA 将授权集中在 IAM 中，提高了可审计性。一年的保留期可防止意外删除。生命周期策略在 90 天后将备份转移到 Coldline，并在到期时删除，以控制成本。

2. 通过专用服务账号为备份作业授予只写访问权限。

   • 命令： gcloud storage buckets add-iam-policy-binding gs://contoso-backups –member=serviceAccount:backup-writer@contoso.iam.gserviceaccount.com –role=roles/storage.objectCreator
   • 理由：storage.objectCreator 角色可防止元数据篡改和敏感备份的回读，遵循最小权限原则。

3. 使用签名 URL 与供应商共享一个敏感备份，有效期为四小时，无需分发密钥。

   • 命令： gcloud storage sign-url gs://contoso-backups/db-dump-2024-09-30.sql.gz –duration=4h –impersonate-service-account share-signer@contoso.iam.gserviceaccount.com
   • 理由：有时间限制的、无身份的访问避免了创建外部身份或长期有效的密钥。模拟服务账号使用了由 KMS 支持的集中式签名，消除了密钥泄露的风险。

4. 为订单数据库启用 Cloud SQL 备份和 PITR。

   • 命令： gcloud sql instances patch orders-sql –backup-start-time=02:00 –enable-bin-log
   • 理由：自动备份加上二进制/WAL 日志记录，可在保留窗口内的任何一秒提供恢复点，以防止逻辑损坏和操作员失误。

5. 通过恢复到新实例并在切换前验证数据来测试恢复过程。

   • 命令： gcloud sql backups list –instance=orders-sql gcloud sql instances restore-backup orders-restore –backup-id=LATEST –destination-instance=orders-restore
   • 理由：恢复到独立实例可避免影响生产环境，并允许在进行任何 DNS 或应用层切换之前，通过校验和及抽样查询进行验证。

6. 通过试运行估算 BigQuery 查询成本，并使用分区进行优化。

   • 命令： bq query –use_legacy_sql=false –dry_run=true ‘SELECT COUNT(*) FROM contoso.analytics.sales WHERE sale_date >= “2026-01-01”’
   • 理由：试运行会显示将要扫描的字节数；确保 sale_date 是一个带有范围限制谓词的分区列，可以减少扫描的字节数并控制按需付费的成本。

7. 监控和审计访问。

   • 步骤：
     • 为 Cloud Storage 和 BigQuery 启用数据访问日志。
     • 为 Cloud SQL 连接、磁盘使用和备份失败配置 Cloud Monitoring 警报。
   • 理由：数据访问日志提供对象级别的读/写可见性以满足合规要求。主动警报可缩短 MTTR，并确保备份和 PITR 持续有效。

8. 记录故障模式和操作手册 (runbook)。

   • 步骤：
     • 记录对象版本恢复、签名 URL 撤销、Cloud SQL PITR 以及使用时间旅行恢复 BigQuery 表的程序。
   • 理由：清晰、经过测试的操作手册可在事件发生时降低运营风险，并在团队间标准化安全恢复实践。

← VPC 网络、连接性和流量管理 · 所有领域 · 部署、配置和自动化 →

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

浏览 Google →