此架构提供了一个框架和参考部署，可帮助您制定 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 还提供故障安全期，在该期间，已删除的数据会在时间旅行窗口之后在故障安全存储空间中额外保留 7 天。您可以通过 Cloud Customer Care 获取这些数据，以便进行紧急恢复。但是，如果贵公司未在此总时间范围内发现并修正此类错误，则无法再从上次稳定状态恢复已删除的数据。
为缓解这种情况，我们建议您定期备份无法从源数据重建的任何 BigQuery 表（例如，具有不断演变的业务逻辑的历史记录或 KPI）。
您的公司可以使用基本脚本备份数十个表。但是，如果您需要定期备份整个组织中的数百或数千个表，则需要一个可扩展的自动化解决方案，该解决方案可以执行以下操作：
- 处理不同的 Google Cloud API 限制。
- 提供用于定义备份政策的标准化框架。
- 为备份操作提供透明度和监控功能。
备份政策
贵公司可能还会要求备用政策由以下人员组定义：
- 数据所有者，他们最熟悉这些表，并且可以设置适当的表级备份政策。
- 数据治理团队，确保回退政策适用于没有表级政策的所有表。回退政策可确保某些数据集、项目和文件夹会备份，以符合贵公司的保留数据法规。
在部署此参考架构时，您可以通过以下两种方式定义表的备用政策，并且可以将这两种方式结合使用：
数据所有者配置（分散式）：表级备用政策，可手动附加到表中。
- 数据所有者定义一个存储在公共存储桶中的表级 JSON 文件。
- 当解决方案确定表的备用政策时，手动政策优先于回退政策。
- 如需详细了解部署，请参阅设置表级备份政策。
组织默认配置（集中式）：后备政策，仅适用于未手动附加政策的表。
- 数据治理团队在 Terraform 中定义了一个中心 JSON 文件，作为解决方案的一部分。
- 回退策略在文件夹、项目、数据集和表级别提供默认的备份策略。
- 如需了解部署的详细信息，请参阅定义回退备用政策。
备份与复制
备份流程会在特定时间点复制表数据，以便在数据丢失或损坏时进行恢复。备份可以作为一次性操作运行，也可以定期（通过预定查询或工作流）运行。在 BigQuery 中，可以使用快照实现时间点备份。您可以使用快照将数据副本保留在超过 7 天时间旅行窗口的同一存储位置，与源数据位于同一位置。BigQuery 快照对于在人为错误导致数据丢失或损坏后恢复数据（而不是从区域故障中恢复数据）特别有用。BigQuery 提供的服务等级目标 (SLO) 为 99.9% 到 99.99%，具体取决于版本。
相比之下，复制是一个持续的过程，即将数据库更改复制到位于不同位置的辅助（或副本）数据库。在 BigQuery 中，跨区域复制可在次要 Google Cloud 区域（与来源数据区域不同）创建数据的只读副本，从而帮助提供地理冗余。不过，BigQuery 跨区域复制不适合用作全区域服务中断场景的灾难恢复计划。如需应对区域性灾害，请考虑使用 BigQuery 托管式灾难恢复。
BigQuery 跨区域复制功能可在靠近数据使用方所在区域提供数据的同步只读副本。这些数据副本可实现联合查询，并避免跨区域流量和费用。但是，如果数据损坏是由于人为错误造成的，单独的复制无法帮助恢复数据，因为损坏的数据会自动复制到副本中。在这种情况下，时间点备份（快照）是更好的选择。
下表总结了备份方法和复制之间的对比：
| 方法 | 频率 | 存储位置 | 使用场景 | 费用 |
|---|---|---|---|---|
| 备份 （快照或 Cloud Storage 导出） |
一次性或定期 | 与来源表数据相同 | 恢复超出时间旅行期间的原始数据 | 快照仅会因快照中的数据更改而产生存储费用 导出可能会产生标准存储费用 请参阅成本优化 |
| 跨区域复制 | 持续 | 远程 | 在其他区域创建副本 在区域之间进行一次性迁移 |
在副本中存储数据会产生费用 产生数据复制费用 |
设计考虑事项
本部分提供的指导可帮助您在使用此参考架构开发满足安全性、可靠性、费用优化、运营效率和性能方面的特定要求的拓扑时加以考虑。
安全性、隐私权和合规性
该部署在设计和实现中纳入了以下安全措施：
- Cloud Run 的网络入口设置仅接受内部流量，以限制从互联网访问。此外，它还允许经过身份验证的用户和服务账号调用服务。
- 每个 Cloud Run 服务和 Pub/Sub 订阅都使用单独的服务账号，该账号仅具有分配给它的必需权限。这样可以降低为系统使用一个服务账号所带来的风险，并遵循最小权限原则。
出于隐私保护方面的考虑，该解决方案不会收集或处理个人身份信息 (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 | 云战略工程师