可扩缩的 BigQuery 备份自动化

Last reviewed 2024-09-17 UTC

此架构提供了一个框架和参考部署,可帮助您制定 BigQuery 备份策略。此推荐框架及其自动化功能可帮助贵组织实现以下目标:

  • 遵循贵组织的灾难恢复目标。
  • 恢复因人为错误而丢失的数据。
  • 遵守相关法规。
  • 提高运营效率。

BigQuery 数据的范围可以包括(或排除)文件夹、项目、数据集和表。此推荐架构介绍了如何大规模自动执行周期性备份操作。您可以对每个表使用两种备份方法:BigQuery 快照将 BigQuery 数据导出到 Cloud Storage

本文档面向希望在组织中定义和自动执行数据政策的云架构师、工程师和数据治理官员。

下图展示了自动备份架构:

自动化备份解决方案的架构。

上图中显示的工作流包含以下阶段:

  1. Cloud Scheduler 通过 Pub/Sub 消息触发对调度程序服务的运行,其中包含要包含和排除的 BigQuery 数据的范围。运行作业是通过使用 cron 表达式进行安排的。
  2. 调度程序服务基于 Cloud Run 构建,使用 BigQuery API 列出 BigQuery 范围内的表。
  3. 调度程序服务会通过 Pub/Sub 消息向配置器服务提交每个表的请求。
  4. Cloud Run 配置器服务会根据以下定义的选项之一计算表的备份政策:

    1. 表级政策,由数据所有者定义。
    2. 回退政策,由数据治理官员为没有定义政策的表定义。

    如需详细了解备份政策,请参阅备份政策

  5. 配置器服务会根据计算出的备份政策,向下一个服务针对每个表提交一个请求。

  6. 根据备份方法,以下某个自定义 Cloud Run 服务会向 BigQuery API 提交请求并运行备份流程:

    1. BigQuery 快照服务会将表备份为快照
    2. 数据导出服务会将表备份为导出到 Cloud Storage 的数据
  7. 当备份方法为表数据导出时,Cloud Logging 日志接收器会监听导出作业完成事件,以便异步执行后续步骤。

  8. 备份服务完成操作后,Pub/Sub 会触发标记服务。

  9. 对于每个表,标记器服务都会记录备份服务的结果,并更新 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 提供 99.9% 到 99.99% 的服务等级目标 (SLO),具体取决于版本。

相比之下,复制是指将数据库更改持续复制到位于其他位置的次要(或副本)数据库的过程。在 BigQuery 中,跨区域复制可在与源数据区域不同的次要 Google Cloud 区域中创建数据的只读副本,从而帮助提供地理冗余。不过,BigQuery 跨区域复制不适用于全区域服务中断场景的灾难恢复计划。如需针对区域性灾难提供弹性恢复能力,请考虑使用 BigQuery 托管式灾难恢复

BigQuery 跨区域复制功能可在靠近数据使用方所在区域提供数据的同步只读副本。这些数据副本支持共置联接,并避免跨区域流量和费用。但是,如果数据因人为错误而损坏,仅复制无法帮助恢复,因为损坏的数据会自动复制到副本。在这种情况下,时间点备份(快照)是更好的选择。

下表简要比较了备份方法和复制:

方法 频率 存储位置 使用场景 费用
备份

(快照或 Cloud Storage 导出)
一次性或周期性 与源表数据相同 恢复超出时间旅行期限的原始数据 快照仅会因快照中的数据更改而产生存储费用

导出操作可能会产生标准存储费用

请参阅费用优化
跨区域复制 持续 远程 在其他区域中创建副本

在区域之间进行一次性迁移
在副本中存储数据需要付费

会产生数据复制费用

设计考虑事项

本部分提供了一些指导,可帮助您在使用此参考架构开发拓扑时考虑满足特定安全性、可靠性、费用优化、运营效率和性能要求。

安全性、隐私权和合规性

该部署在设计和实现中纳入了以下安全措施:

  • Cloud Run 的网络入站流量设置仅接受内部流量,以限制来自互联网的访问。此外,它还允许仅经过身份验证的用户和服务账号调用服务。
  • 每个 Cloud Run 服务和 Pub/Sub 订阅都使用单独的服务账号,并且该服务账号仅具有分配给它的必需权限。这可降低为系统使用一个服务账号所带来的风险,并遵循最小权限原则

出于隐私保护考虑,该解决方案不会收集或处理个人身份信息 (PII)。不过,如果源表泄露了个人身份信息 (PII),则对这些表执行的备份也包含这些泄露的数据。来源数据的所有者负责保护来源表中的所有个人身份信息 (PII)(例如,通过应用列级安全性数据遮盖隐去)。只有在源数据安全的情况下,备份才会安全。另一种方法是,确保包含已泄露个人身份信息 (PII) 的备份数据的项目、数据集或存储分区采用了必要的 Identity and Access Management (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 恢复服务,以相应地应用恢复操作。最后,标记器服务可以将这些操作的结果存储在状态存储区中。这样一来,自动恢复框架便可受益于与本文档中详述的备份框架相同的设计目标。

费用优化

此架构的框架提供了备用政策,用于设置以下参数以实现整体费用优化:

  • 备份方法:该框架提供以下两种备份方法:
    • BigQuery 快照:与基表相比,更新和删除的数据会产生存储费用。因此,对于只写入或更新有限的表,快照更具成本效益。
    • BigQuery 导出到 Cloud Storage,这会产生标准存储费用。不过,对于采用截断和加载方法的大表,将其作为导出内容备份到费用较低的存储类别中更具成本效益。
  • 快照到期:为单个表快照设置存留时间 (TTL),以避免无限期为快照产生存储费用。如果表没有过期时间,存储空间费用可能会随时间推移而增加。

运营效率

本部分介绍了有关运营效率的功能和注意事项。

精细且可伸缩的备份政策

此框架的目标之一是通过扩大业务输出,同时将业务输入保持在相对较低且可管理的水平,从而提高运营效率。例如,输出是大量定期备份的表,而输入是少量维护的备份政策和配置。

除了允许在表级设置备份政策之外,该框架还允许在数据集、项目、文件夹和全局级设置政策。这意味着,只需在更高级别(例如文件夹级别或项目级别)进行一些配置,即可定期大规模备份数百或数千个表。

可观测性

使用自动化框架时,您必须了解流程的状态。例如,您应该能够找到以下常见查询的信息:

  • 系统为每个表使用的备份政策。
  • 每个表的备份历史记录和备份位置。
  • 单次运行的整体状态(已处理的表和失败的表的数量)。
  • 单次运行期间发生的严重错误,以及发生这些错误的进程的组件或步骤。

为了提供此类信息,部署会在使用 Cloud Run 服务的每个执行步骤中将结构化日志写入 Cloud Logging。日志包含输入、输出和错误,以及其他进度检查点。日志接收器会将这些日志路由到 BigQuery 表。您可以运行多个查询,以便针对常见的可观测性用例监控运行作业并获取报告。如需详细了解 BigQuery 中的日志和查询,请参阅查看路由到 BigQuery 的日志

性能优化

为了在每次运行时处理数千个表,该解决方案会并行处理备份请求。调度程序服务会列出 BigQuery 备份范围内包含的所有表,并且每次运行时,系统会为每个表生成一个备份请求。这样,应用就可以并行(而非顺序)处理数千个请求和表。

这些请求中的一些请求最初可能会因临时原因而失败,例如达到底层 API 的限制或遇到网络问题。 Google Cloud 在请求完成之前,Pub/Sub 会使用指数退避算法重试策略自动重试请求。如果存在致命错误(例如备份目的地无效或缺少权限),系统会记录错误,并终止相应表请求的执行,而不会影响整体运行。

限制

以下配额和限制适用于此架构。

对于表快照,您指定的每个备份操作项目都适用以下规则:

  • 一个项目最多可以运行 100 个并发表快照作业。
  • 一个项目每天最多可以运行 5 万个表快照作业。
  • 一个项目每天最多可为每个表运行 50 个表快照作业。

如需了解详情,请参阅表快照

对于导出作业(导出到 Cloud Storage),适用以下规则:

  • 使用共享槽池时,您每天最多可以从一个项目中免费导出 50 TiB 的数据。
  • 一个项目每天最多可以运行 10 万个导出作业。如需延长此时限,请创建槽预留。

如需详细了解如何延长这些限制,请参阅导出作业

关于并发限制,此架构使用 Pub/Sub 自动重试因这些限制而失败的请求,直到 API 处理这些请求为止。不过,对于每个项目每天的其他操作数限制,您可以通过配额增加请求或将备份操作(快照或导出)分散到多个项目来缓解这些限制。如需将操作分散到多个项目中,请按照以下部署部分中所述的方式配置备份政策:

部署

如需部署此架构,请参阅部署可伸缩的 BigQuery 备份自动化功能

后续步骤

贡献者

作者:Karim Wadie | 云战略工程师

其他贡献者: