此架构提供了一个框架和参考部署，可帮助您制定 BigQuery 备份策略。这个推荐的框架及其自动化功能可帮助您的组织执行以下操作：
- 遵循贵组织的灾难恢复目标。
- 恢复因人为错误而丢失的数据。
- 遵守法规。
- 提高运营效率。
BigQuery 数据的范围可以包括（或排除）文件夹、项目、数据集和表。这个推荐的架构展示了如何大规模自动执行周期性备份操作。您可以为每个表使用两种备份方法：BigQuery 快照和从 BigQuery 导出到 Cloud Storage。
本文档面向希望在组织中定义和自动执行数据政策的云架构师、工程师和数据治理人员。
架构
下图展示了自动备份架构：
上图中显示的工作流包括以下阶段：
- Cloud Scheduler 通过 Pub/Sub 消息触发调度程序服务的运行，该消息包含要包含和排除的 BigQuery 数据范围。使用 Cron 表达式来安排运行。
- 调度程序服务基于 Cloud Run 构建，它使用 BigQuery API 列出 BigQuery 范围内的表。
- 调度程序服务通过 Pub/Sub 消息向配置器服务提交每个表的一个请求。
Cloud Run Configurator 服务会根据以下定义的选项之一计算表的备份政策：
- 由数据所有者定义的表级政策。
- 回退政策，由数据治理人员定义，适用于未定义政策的表。
如需详细了解备份政策，请参阅备份政策。
Configurator 服务会根据计算的备份政策，将每个表的一个请求提交给下一项服务。
根据备份方法，以下自定义 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 作为主数据仓库。即使您的公司遵循软件开发、代码审核和发布工程方面的最佳做法，仍存在因人为错误而导致数据丢失或数据损坏的风险。在受监管的行业中，您需要尽可能降低这种风险。
此类人为错误的示例包括：
- 意外删除表。
- 因数据流水线逻辑错误而导致的数据损坏。
这些类型的人为错误通常可以使用时间旅行功能解决。该功能允许您恢复七天前的数据。此外，BigQuery 还提供了故障安全期，在此期间，已删除的数据会在时间旅行窗口之后继续在故障安全存储空间中保留七天。这些数据可通过 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 数据，再由调度程序服务向配置器服务发送每个表的一个请求。Configurator 服务可以提取特定表所需的备份历史记录。然后，配置程序服务可以将其传递给 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 | 战略云工程师