此架构提供了一个框架和参考部署，可帮助您制定 BigQuery 备份策略。此推荐框架及其自动化功能可帮助您的组织执行以下操作：
- 遵守组织的灾难恢复目标。
- 恢复因人为错误而丢失的数据。
- 遵守法规。
- 提高运营效率。
BigQuery 数据的范围可以包含（或排除）文件夹、项目、数据集和表。此推荐的架构展示了如何大规模自动执行周期性备份操作。您可以为每个表使用两种备份方法：BigQuery 快照和将 BigQuery 导出到 Cloud Storage。
本文档面向希望在组织中定义和自动化数据政策的云架构师、工程师和数据治理官。
架构
下图展示了自动备份架构：
上图所示的工作流包含以下阶段：
- Cloud Scheduler 通过 Pub/Sub 消息触发调度程序服务运行，该消息包含纳入和排除的 BigQuery 数据范围。运行通过 cron 表达式进行调度。
- 调度程序服务基于 Cloud Run 构建，使用 BigQuery API 列出 BigQuery 范围内的表。
- 调度程序服务通过 Pub/Sub 消息为每个表向配置程序服务提交一个请求。
Cloud Run 配置器服务会根据以下定义的选项之一计算表的备份政策：
- 由数据所有者定义的表级政策。
- 由数据治理官员定义的后备政策，适用于未定义政策的表。
如需详细了解备份政策，请参阅备份政策。
配置器服务会根据计算出的备份政策，为每个表向下一个服务提交一个请求。
根据备份方法，以下某个自定义 Cloud Run 服务会向 BigQuery API 提交请求并运行备份进程：
- BigQuery 快照服务会将表备份为快照。
- 用于数据导出的服务会将表备份为导出到 Cloud Storage 的数据。
当备份方法为表数据导出时，Cloud Logging 日志接收器会监听导出作业完成事件，以便异步执行下一步。
备份服务完成操作后，Pub/Sub 会触发标记器服务。
对于每个表，标记器服务会记录备份服务的结果，并更新 Cloud Storage 元数据层中的备份状态。
使用的产品
此参考架构使用以下 Google Cloud 产品：
- BigQuery：一种企业数据仓库，可帮助您使用机器学习地理空间分析和商业智能等内置功能管理和分析数据。
- Cloud Logging：具有存储、搜索、分析和提醒功能的实时日志管理系统。
- Pub/Sub：一种异步且可伸缩的通讯服务，可将生成消息的服务与处理这些消息的服务分离开。
- Cloud Run：一个无服务器计算平台，可让您直接在 Google 可伸缩的基础设施之上运行容器。
- Cloud Storage：适用于各种数据类型的费用低廉且不受限制的对象存储。数据可从 Google Cloud内部和外部访问，并且跨位置进行复制以实现冗余。
- Cloud Scheduler：一项全托管式企业级 Cron 作业调度服务，可让您设置工作单元日程安排，以便在规定的时间或按一定的时间间隔执行这些工作。
- Datastore：一款扩容能力极强的 NoSQL 数据库，适用于 Web 应用和移动应用。
使用场景
本部分提供了一些可使用此架构的应用场景示例。
备份自动化
例如，您的公司可能在受监管的行业中运营，并使用 BigQuery 作为主要数据仓库。即使您的公司在软件开发、代码审核和发布工程方面遵循最佳实践，仍存在因人为错误而导致数据丢失或损坏的风险。在受监管的行业中，您需要尽可能降低此风险。
此类人为错误的示例包括：
- 意外删除表。
- 由于数据流水线逻辑有误而导致数据损坏。
这些人为错误通常可以通过时间旅行功能来解决，该功能可让您恢复最多 7 天前的数据。此外，BigQuery 还提供故障安全期，在该期间，已删除的数据会在时间旅行窗口结束后在故障安全存储空间中额外保留七天。您可以通过 Cloud Customer Care 获取这些数据，以进行紧急恢复。不过，如果贵公司未在此总时长内发现并修正此类错误，则已删除的数据将无法再从其上次稳定状态恢复。
为缓解此问题，我们建议您定期备份无法从源数据重建的任何 BigQuery 表（例如，历史记录或业务逻辑不断变化的 KPI）。
您的公司可以使用基本脚本备份数十个表。不过，如果您需要定期备份组织中的数百个或数千个表，则需要一种可扩缩的自动化解决方案，该解决方案能够执行以下操作：
- 处理不同的 Google Cloud API 限制。
- 提供用于定义备份政策的标准化框架。
- 为备份操作提供透明度和监控功能。
备份政策
您的公司可能还要求备份政策由以下人员群体定义：
- 数据所有者，他们最熟悉表，可以设置适当的表级备份政策。
- 数据治理团队，负责确保制定后备政策，以涵盖未设置表级政策的任何表。回退政策可确保备份某些数据集、项目和文件夹，以符合贵公司的数据保留法规。
在此参考架构的部署中，有两种方法可以定义表的备份政策，并且可以同时使用这两种方法：
数据所有者配置（去中心化）：手动附加到表的表级备份政策。
- 数据所有者定义一个存储在公共存储桶中的表级 JSON 文件。
- 当解决方案确定表的备份政策时，手动政策的优先级高于后备政策。
- 如需详细了解部署，请参阅设置表级备份政策。
组织默认配置（集中式）：一种后备政策，仅适用于未手动附加政策的表。
- 数据治理团队在 Terraform 中定义一个中央 JSON 文件，作为解决方案的一部分。
- 后备政策可在文件夹、项目、数据集和表级别提供默认备份策略。
- 如需了解部署方面的详细信息，请参阅定义后备备份政策。
备份与复制
备份流程会复制特定时间点的表数据，以便在数据丢失或损坏时进行恢复。备份可以作为一次性操作运行，也可以定期运行（通过预定查询或工作流）。在 BigQuery 中，可以使用快照实现时间点备份。 您可以使用快照在源数据所在的同一存储位置中保留超过 7 天时间旅行期的数据副本。BigQuery 快照特别有助于在因人为错误导致数据丢失或损坏后恢复数据，而不是从区域性故障中恢复数据。BigQuery 提供 99.9% 至 99.99% 的服务等级目标 (SLO)，具体取决于版本。
相比之下，复制是指将数据库更改持续复制到其他位置的辅助（或副本）数据库的过程。在 BigQuery 中，跨区域复制功能可在次要 Google Cloud 区域（与源数据区域不同）中创建只读数据副本，从而帮助提供地理冗余。不过，BigQuery 跨区域复制不适用于全区域服务中断场景，不能用作灾难恢复计划。 为了应对区域性灾难，请考虑使用 BigQuery 托管式灾难恢复。
BigQuery 跨区域复制功能可在靠近数据使用者的区域中提供同步的只读数据副本。这些数据副本可实现同地联接，避免跨区域流量和费用。 不过，如果数据因人为错误而损坏，仅靠复制无法帮助恢复，因为损坏的数据会自动复制到副本。在这种情况下，时间点备份（快照）是更好的选择。
下表简要比较了备份方法和复制：
| 方法 | 频率 | 存储位置 | 使用场景 | 费用 |
|---|---|---|---|---|
| 备份 （快照或 Cloud Storage 导出） |
一次性或定期 | 与源表数据相同 | 恢复时间旅行期以外的原始数据 | 快照仅针对快照中的数据更改产生存储费用 导出可能会产生标准存储费用 请参阅费用优化 |
| 跨区域复制 | 持续 | 远程 | 在其他区域中创建副本 区域之间的一次性迁移 |
产生存储数据的费用
在副本中 产生数据复制费用 |
设计考虑事项
本部分提供的指导可帮助您在使用此参考架构开发满足特定安全性、可靠性、费用优化、运营效率和性能要求的拓扑时考虑相关因素。
安全性、隐私权和合规性
该部署在设计和实现中采用了以下安全措施：
- Cloud Run 的网络入站流量设置仅接受内部流量，以限制来自互联网的访问。此外，它还允许只有经过身份验证的用户和服务账号才能调用服务。
- 每个 Cloud Run 服务和 Pub/Sub 订阅都使用单独的服务账号，该账号仅被分配了必需的权限。这样可以降低与为系统使用一个服务账号相关的风险，并遵循最小权限原则。
出于隐私方面的考虑，该解决方案不会收集或处理个人身份信息 (PII)。不过，如果源表包含公开的 PII，则这些表的备份也会包含这些公开的数据。源数据的所有者负责保护源表中的所有 PII（例如，通过应用列级安全性、数据遮盖或编辑）。 只有当源数据安全时，备份才是安全的。另一种方法是，确保包含公开的个人身份信息 (PII) 的备用数据的项目、数据集或存储桶具有所需的身份和访问权限管理 (IAM) 政策，以便仅限授权用户访问。
作为一种通用解决方案，参考部署不一定符合特定行业的具体要求。
可靠性
本部分介绍了可靠性功能和设计注意事项。
通过精细度缓解失败
如需备份数千个表，您可能会达到底层 Google Cloud 产品的 API 限制（例如，每个项目的快照和导出操作限制）。不过，如果某个表的备份因配置错误或其他暂时性问题而失败，这不应影响整体执行情况以及备份其他表的能力。
为了缓解潜在的故障，参考部署通过使用精细的 Cloud Run 服务并通过 Pub/Sub 连接这些服务来解耦处理步骤。如果表备份请求在最终标记器服务步骤中失败，Pub/Sub 只会重试此步骤，而不会重试整个流程。
将流程分解为多个 Cloud Run 服务，而不是将多个端点托管在一个 Cloud Run 服务下，有助于对每个服务配置进行精细控制。配置级别取决于服务的各项功能以及它所通信的 API。例如，调度程序服务每次运行一次，但需要大量时间才能列出 BigQuery 备份范围内的所有表。因此，调度程序服务需要更高的超时和内存设置。不过，用于 BigQuery 快照的 Cloud Run 服务在单次运行中针对每个表执行一次，并且完成时间比调度程序服务短。因此，Cloud Run 服务需要在服务级层进行不同的配置。
数据一致性
确保表和视图之间的数据一致性对于维持可靠的备份策略至关重要。由于数据会不断更新和修改，因此在不同时间点创建的备份可能会捕获数据集的不同状态。当您恢复数据时，这些处于不同状态的备份可能会导致不一致，尤其是对于属于同一功能数据集的表。例如，将销售表恢复到与相应库存表不同的时间点可能会导致可用库存不匹配。同样，汇总多个表中的数据的数据库视图对不一致性尤其敏感。恢复这些视图而不确保基础表处于一致状态可能会导致结果不准确或具有误导性。因此，在设计 BigQuery 备份政策和频率时，务必要考虑这种一致性，并确保恢复的数据能够准确反映数据集在特定时间点的实际状态。
例如，在此参考架构的部署中，数据一致性通过备份政策中的以下两项配置来控制。 这些配置通过时间旅行计算确切的表快照时间，而不一定同时备份所有表。
backup_cron：控制备份表的频率。运行的开始时间戳用作此运行中备份的所有表的时间旅行计算的参考点。backup_time_travel_offset_days：控制应从参考时间点（运行开始时间）减去多少天，以计算表的精确时间旅行版本。
自动备份恢复
虽然此参考架构侧重于大规模备份自动化，但您也可以考虑以自动方式恢复这些备份。这种额外的自动化功能可提供与备份自动化功能类似的优势，包括提高恢复效率和速度，并减少停机时间。由于该解决方案通过标记器服务跟踪所有备份参数和结果，因此您可以开发类似的架构来大规模应用恢复操作。
例如，您可以创建一个基于按需触发器的解决方案，该解决方案会将 BigQuery 数据范围发送到调度程序服务，然后调度程序服务会为每个表向配置程序服务调度一个请求。配置器服务可以提取您需要的特定表的备份历史记录。然后，配置器服务可以将该请求传递给 BigQuery 快照恢复服务或 Cloud Storage 恢复服务，以相应地应用恢复操作。最后，标记器服务可以将这些操作的结果存储在状态存储区中。这样一来，自动化恢复框架便可受益于本文档中详细介绍的备份框架的相同设计目标。
费用优化
此架构的框架提供备份政策，可设置以下参数以实现总体费用优化：
- 备份方法：框架提供以下两种备份方法：
- 快照过期：为单个表快照设置存留时间 (TTL)，以避免无限期地产生快照存储费用。如果表没有过期时间，存储空间费用可能会随着时间的推移而增加。
运营效率
本部分介绍了运营效率方面的功能和注意事项。
精细且可扩缩的备份政策
此框架的目标之一是提高运营效率，即在保持业务输入相对较低且可管理的情况下，扩大业务输出。例如，输出是大量定期备份的表，而输入是少量维护的备份政策和配置。
除了允许在表级设置备份政策之外，该框架还允许在数据集、项目、文件夹和全局级设置政策。这意味着，只需在更高级别（例如文件夹或项目级层）进行少量配置，即可大规模定期备份数百或数千个表。
可观测性
使用自动化框架时，务必要了解流程的状态。例如，您应该能够找到以下常见查询的信息：
- 系统为每个表使用的备份政策。
- 每个表的备份历史记录和备份位置。
- 单次运行的总体状态（已处理的表数和失败的表数）。
- 单次运行中发生的严重错误，以及发生这些错误的流程组件或步骤。
为了提供此信息，部署会在每个使用 Cloud Run 服务的执行步骤中将结构化日志写入 Cloud Logging。日志包含输入、输出和错误，以及其他进度检查点。日志接收器会将这些日志路由到 BigQuery 表。您可以运行多项查询，以监控运行情况并获取报告，从而实现常见的可观测性用例。如需详细了解 BigQuery 中的日志和查询，请参阅查看路由到 BigQuery 的日志。
性能优化
为了在每次运行时处理数千个表，解决方案会并行处理备份请求。调度程序服务会列出 BigQuery 备份范围内的所有表，并在每次运行时为每个表生成一个备份请求。这样，应用便可并行（而非按顺序）处理数千个请求和表。
这些请求中的一些请求可能会因临时原因而最初失败，例如达到底层 Google Cloud API 的限制或遇到网络问题。在请求完成之前，Pub/Sub 会自动使用指数退避算法重试政策来重试请求。如果出现致命错误（例如备份目标位置无效或缺少权限），系统会记录这些错误，并终止相应表格请求的执行，但不会影响整体运行。
限制
以下配额和限制适用于此架构。
对于表快照，以下内容适用于您指定的每个备份操作项目：
- 一个项目最多可以运行 100 个并发表快照作业。
- 一个项目每天最多可以运行 5 万个表快照作业。
- 一个项目每天最多可以为每个表运行 50 个表快照作业。
如需了解详情，请参阅表快照。
对于导出作业（导出到 Cloud Storage），以下内容适用：
- 使用共享槽池时，您每天最多可以从一个项目中导出 50 TiB 的数据。
- 一个项目每天最多可以运行 10 万个导出作业。如需延长此限制，请创建槽预留。
如需详细了解如何提高这些限制，请参阅导出作业。
关于并发限制，此架构使用 Pub/Sub 自动重试因这些限制而失败的请求，直到 API 处理这些请求为止。不过，对于每个项目每天的操作次数的其他限制，可以通过申请增加配额或将备份操作（快照或导出）分散到多个项目中来缓解。如需在多个项目中分散操作，请按照以下部署部分中的说明配置备份政策：
部署
如需部署此架构，请参阅部署可扩缩的 BigQuery 备份自动化。
后续步骤
- 详细了解 BigQuery：
- 如需查看更多参考架构、图表和最佳做法，请浏览云架构中心。
贡献者
作者：Karim Wadie | 云战略工程师
其他贡献者：
- Chris DeForeest | 站点可靠性工程师
- Eyal Ben Ivri | 云解决方案架构师
- Jason Davenport | 开发技术推广工程师
- Jaliya Ekanayake | 工程经理
- Muhammad Zain | 战略云工程师