灾难恢复使用场景：受限于位置的数据分析应用

本文档是介绍 Google Cloud 中的灾难恢复 (DR) 的系列文章中的一篇。本文档介绍如何将为受限于位置的工作负载设计灾难恢复架构文档中的位置限制应用于数据分析应用。具体而言，本文档介绍了您在数据分析平台中使用的组件如何融入灾难恢复架构，以满足您的应用或数据可能受到的位置限制。

该系列包含以下部分：

• 灾难恢复规划指南
• 灾难恢复组件
• 数据灾难恢复方案
• 应用灾难恢复场景
• 为受限于位置的工作负载设计灾难恢复架构
• 针对云基础架构服务中断设计灾难恢复架构
• 灾难恢复使用场景：受限于位置的数据分析应用（本文档）

本文档面向系统架构师和 IT 经理。本文档假定您具备以下知识和技能：

• 基本熟悉 Google Cloud 数据分析服务，例如 Dataflow、Dataproc、Cloud Composer、Pub/Sub、Cloud Storage 和 BigQuery。
• 基本熟悉 Google Cloud 网络服务，例如 Cloud Interconnect 和 Cloud VPN。
• 熟悉灾难恢复规划。
• 熟悉 Apache Hive 和 Apache Spark。

数据分析平台的位置要求

数据分析平台通常是存储静态数据的复杂多层应用。这些应用会生成事件，以在分析系统中进行处理并存储。应用本身和存储在系统中的数据可能受到位置法规的约束。这些法规不仅仅适用于国家/地区，还适用于整个行业。因此，在开始设计灾难恢复架构之前，您应该清楚了解数据存放区域要求。

您可以通过回答以下两个问题来确定您的数据分析平台是否有任何位置要求：

• 您的应用是否需要部署到特定区域？
• 您的静态数据是否只限于特定区域？

如果您对这两个问题的回答都是“否”，则您的数据分析平台没有任何特定于位置的要求。由于您的平台没有位置要求，因此请遵循灾难恢复规划指南中关于合规服务和产品的灾难恢复指南。

但是，如果您对以上任一问题的回答为“是”，则表示您的应用受限于位置。由于您的分析平台受限于位置，因此您必须提出以下问题：您可以使用加密技术来缓解静态数据要求吗？

如果您能够使用加密技术，则可以使用 Cloud External Key Manager 和 Cloud Key Management Service 的多区域和双区域服务。然后，您还可以遵循数据的灾难恢复场景中所述的标准高可用性和灾难恢复 (HA/DR) 技术。

如果您无法使用加密技术，则必须使用自定义解决方案或合作伙伴产品进行灾难恢复规划。如需详细了解如何处理 DR 场景的位置限制，请参阅为受限于位置的工作负载设计灾难恢复架构。

数据分析平台中的组件

了解位置要求后，下一步是了解数据分析平台所使用的组件。数据分析平台的一些常见组件包括数据库、数据湖、处理流水线和数据仓库，具体如以下列表所述：

• Google Cloud 具有一组适用于不同使用场景的数据库服务。
• 数据湖、数据仓库和处理流水线的定义可能略有不同。本文档使用一组引用 Google Cloud 服务的定义：
  • 数据湖是一个可扩缩的安全平台，用于从多个系统提取和存储数据。典型的数据湖可能使用 Cloud Storage 作为中央存储库。
  • 处理流水线是一个端到端的流程，它从一个或多个系统获取数据或事件，转换该数据或事件，并将其加载到另一个系统中。流水线可以遵循提取、转换和加载 (ETL) 或提取、加载和转换 (ELT) 流程。通常，加载已处理数据的系统是一个数据仓库。Pub/Sub、Dataflow 和 Dataproc 是处理流水线的常用组件。
  • 数据仓库是一种用于分析和报告数据的数据企业系统，通常来自运营数据库。BigQuery 是一种在 Google Cloud 上运行的常用数据仓库系统。

根据位置要求和您使用的数据分析组件，实际的灾难恢复实现会有所不同。以下部分通过两个用例演示了此不同。

批处理用例：定期 ETL 作业

第一个用例描述了一个批处理过程，在该过程中，零售平台会定期从各个商店以文件形式收集销售事件，然后将文件写入 Cloud Storage 存储桶。下图展示了零售商的批量作业的数据分析架构。

该架构包括以下阶段和组件：

• 注入阶段包括将其销售终端 (POS) 数据发送到 Cloud Storage 的商店。这些注入的数据会等待处理。
• 编排阶段使用 Cloud Composer 来编排端到端批处理流水线。
• 处理阶段涉及在 Dataproc 集群上运行的 Apache Spark 作业。Apache Spark 作业对提取的数据执行 ETL 流程。此 ETL 流程提供了业务指标。
• 数据湖阶段接受已处理的数据并将信息存储在以下组件中：
  • 已处理的数据通常以列式格式（例如 Parquet 和 ORC）存储在 Cloud Storage 中，因为这些格式可实现高效存储和更快的访问来处理分析工作负载。
  • 有关流程数据（例如数据库、表、列和分区）的元数据存储在 Dataproc Metastore 提供的 Hive Metastore 服务中。

在受位置限制的场景中，可能很难提供冗余处理和编排容量来保持可用性。由于数据是批量处理的，因此可以重新创建处理和编排流水线，并且可以在解决灾难场景后重启批量作业。因此，对于灾难恢复，核心重点是恢复实际数据：提取的 POS 数据、存储在数据湖中的已处理数据以及存储在数据湖中的元数据。

注入到 Cloud Storage

首先考虑的应该是用于从 POS 系统注入数据的 Cloud Storage 存储桶的位置要求。在考虑以下方案时，请使用此位置信息：

• 如果位置要求允许静态数据驻留在多区域位置或双区域位置之一，请在创建 Cloud Storage 存储桶时选择相应的位置类型。您选择的位置类型定义了哪些 Google Cloud 区域用于复制静态数据。如果其中一个区域发生中断，则多区域或双区域存储桶中的数据仍然可以访问。
• Cloud Storage 还支持客户管理的加密密钥 (CMEK) 和客户提供的加密密钥 (CSEK)。使用 CMEK 或 CSEK 进行密钥管理时，某些位置规则允许将静态数据存储在多个位置。如果您的位置规则允许使用 CMEK 或 CSEK，您可以设计灾难恢复架构以使用 Cloud Storage 区域。
• 您的位置要求可能不允许您使用位置类型或加密密钥管理。如果您无法使用位置类型或加密密钥管理，可以使用 gsutil rsync 命令将数据同步到其他位置，例如其他云提供商的本地存储或存储解决方案。

如果发生灾难，则 Cloud Storage 存储桶中注入的 POS 数据可能包含尚未处理并导入数据湖的数据。或者，POS 数据可能无法注入到 Cloud Storage 存储桶中。对于这些情况，您可以使用以下灾难恢复方案：

• 让 POS 系统重试。如果系统无法将 POS 数据写入 Cloud Storage，则数据注入过程将失败。为了缓解这种情况，您可以实现截断指数退避算法，以允许 POS 系统重试数据注入操作。由于 Cloud Storage 可提供“11 个 9”级的耐用性，因此在 Cloud Storage 服务恢复后，数据注入和后续处理流水线会继续，并且几乎不会丢失数据。

• 创建提取的数据的副本。Cloud Storage 支持多区域和双区域位置类型。根据您的数据位置要求，您可以设置多区域或双区域 Cloud Storage 存储桶以提高数据可用性。您还可以使用 gsutil 等工具在 Cloud Storage 和其他位置之间同步数据。

编排和处理注入的 POS 数据

在批处理用例的架构图中，Cloud Composer 会执行以下步骤：

• 验证新文件是否已上传到了 Cloud Storage 注入存储桶。
• 启动临时 Dataproc 集群。
• 启动 Apache Spark 作业来处理数据。
• 在作业结束时删除 Dataproc 集群。

Cloud Composer 使用有向无环图 (DAG) 文件来定义这一系列步骤。这些 DAG 文件存储在 Cloud Storage 存储桶中，架构图中未显示该存储桶。就双区域和多区域位置而言，DAG 文件存储桶的灾难恢复注意事项与针对注入存储桶讨论的灾难恢复注意事项相同。

Dataproc 集群是临时性的。也就是说，集群仅在处理阶段运行时存在。这种短暂性意味着您不必为 Dataproc 集群明确执行灾难恢复。

将数据湖存储与 Cloud Storage 结合使用

您用于数据湖的 Cloud Storage 存储桶的位置注意事项与针对注入存储桶讨论的位置注意事项相同：双区域和多区域注意事项、加密的使用以及 gsutil rsync 的使用。

在为数据湖设计灾难恢复规划时，请考虑以下方面：

• 数据大小。 数据湖中的数据量可能很大。恢复大量数据需要花费一定的时间。在灾难恢复方案中，您需要考虑数据湖的量对将数据
  恢复到满足以下条件的点所需的时间量的影响：

  • 您的应用可用。
  • 达到恢复时间目标 (RTO) 值。
  • 获得达到恢复点目标 (RPO) 值所需的数据检查点。

  对于当前的批处理用例，Cloud Storage 会用于数据湖位置，并提供“11 个 9”级的耐用性。但是，勒索软件攻击正在增加。为确保您能够从此类攻击中恢复，明智的做法是遵循Cloud Storage 如何提供“11 个 9”级的耐用性中列出的最佳做法。

• 数据依赖项。数据湖中的数据通常供数据分析系统的其他组件（例如处理流水线）使用。在灾难恢复方案中，处理流水线及其依赖的数据应共享相同的 RTO。在这种情况下，请专注于您可以将系统不可用的时间。

• 数据存在时间。历史数据可能允许更高的 RPO。此类数据可能已被其他数据分析组件分析或处理，并且可能已保存在具有自己的 DR 策略的其他组件中。例如，导出到 Cloud Storage 的销售记录每天都会导入 BigQuery 中进行分析。针对 BigQuery 应用适当的灾难恢复策略后，已导入 BigQuery 的历史销售记录可能低于尚未导入的恢复目标。

将数据湖元数据存储与 Dataproc Metastore 结合使用

Dataproc Metastore 是一个 Apache Hive Metastore，具备全代管式高可用性、自动修复和无服务器功能。Metastore 提供数据抽象和数据发现功能。在发生灾难时，Metastore 可以备份和恢复。Dataproc Metastore 服务还允许您导出和导入元数据。您可以添加任务以导出 Metastore 以及维护外部备份和 ETL 作业。

如果遇到元数据不匹配的情况，您可以使用 MSCK 命令通过数据本身重新创建 Metastore。

流处理用例：使用 ELT 进行变更数据捕获

第二个用例描述了一个使用变更数据捕获 (CDC) 来更新后端库存系统和跟踪实时销售指标的零售平台。下图展示了一个架构，在该架构中处理来自事务型数据库（例如 Cloud SQL）的事件，然后将其存储在数据仓库中。

该架构包括以下阶段和组件：

• 提取阶段包括推送到 Pub/Sub 的传入更改事件。作为消息传送服务，Pub/Sub 可用于可靠地提取和分发流式分析数据。Pub/Sub 具有可伸缩且无服务器的额外优势。
• 处理阶段涉及使用 Dataflow 对注入的事件执行 ELT 流程。
• 数据仓库阶段使用 BigQuery 存储已处理的事件。合并操作会在 BigQuery 中插入或更新记录。此操作允许存储在 BigQuery 中的信息与事务型数据库保持同步。

虽然此 CDC 架构不依赖于 Cloud Composer，但某些 CDC 架构需要 Cloud Composer 将数据流的集成编排到批量工作负载中。在这些情况下，Cloud Composer 工作流会实现由于延迟限制而无法实时完成的完整性检查、回填和投影。Cloud Composer 的灾难恢复技术将在本文档前面讨论的批处理使用场景中进行讨论。

对于流处理数据流水线，您应在规划灾难恢复架构时考虑以下事项：

• 流水线依赖项。处理流水线从一个或多个系统（源）获取输入。然后，流水线会处理、转换这些输入并将其存储到一些其他系统（接收器）中。设计灾难恢复架构以实现端到端 RTO 非常重要。您需要确保数据源和接收器的 RPO 允许您满足 RTO。除了设计云架构来满足您的位置要求之外，您还需要设计源 CDC 源，以满足端到端 RTO。
• 加密和位置。如果加密使您能够缓解位置限制，则可以使用 Cloud KMS 实现以下目标：
  • 管理您自己的加密密钥。
  • 利用个别服务的加密功能。
  • 在由于位置限制而无法使用的区域中部署服务。
• 有关移动中数据的位置规则。某些位置规则可能仅适用于静态数据，而不适用于移动中数据。如果位置规则不适用于动态数据，请设计灾难恢复架构以利用其他区域中的资源来提高恢复目标。您可以通过集成加密技术来补充区域方法。

注入到 Pub/Sub

如果没有位置限制，您可以将消息发布到全球 Pub/Sub 端点。您可以从任何 Google Cloud 位置查看和访问全球 Pub/Sub 端点。

如果您的位置要求允许使用加密，则您可以配置 Pub/Sub，实现与全球端点类似的高可用性级别。虽然 Pub/Sub 消息默认使用 Google 管理的密钥进行加密，但您可以将 Pub/Sub 配置为使用 CMEK。通过将 Pub/Sub 与 CMEK 搭配使用，您可以满足有关加密的位置规则，同时仍保持高可用性。

某些位置规则要求消息即使在加密后仍保留在特定位置。如果您的位置规则具有此限制，则您可以指定 Pub/Sub 主题的消息存储政策，并将其限制在一个区域。如果您使用此消息存储方法，则发布到主题的消息绝不会保留在您指定的那组 Google Cloud 区域之外。如果您的位置规则允许使用多个 Google Cloud 区域，则您可以通过在 Pub/Sub 主题中启用这些区域来提高服务可用性。您需要注意，实施消息存储政策来限制 Pub/Sub 资源位置也会存在一些有关可用性的弊端。

通过 Pub/Sub 订阅，您可以将未确认的消息存储长达 7 天的时间，对消息数量没有任何限制。如果您的服务等级协议允许延迟数据，流水线又停止运行，您可以缓冲 Pub/Sub 订阅中的数据。当流水线再次运行时，您可以处理备份事件。此设计的优势在于具有较低的 RPO。如需详细了解 Pub/Sub 的资源限制，请参阅 Pub/Sub 配额的资源限制。

使用 Dataflow 进行事件处理

Dataflow 是一种用于执行各种数据处理模式的代管式服务。Apache Beam SDK 是一个开源编程模型，既可用于开发批处理流水线，又可用于开发流处理流水线。您可以使用 Apache Beam 程序创建流水线，然后在 Dataflow 服务上运行这些流水线。

在设计位置限制时，您需要考虑来源、接收器和临时文件的位置。如果这些文件位置在作业的区域之外，则数据可能跨区域发送。如果位置规则允许在其他位置处理数据，请设计您的灾难恢复架构，以便在其他 Google Cloud 区域中部署工作器以提供高可用性。

如果您的位置限制限制为单个位置处理，则可以创建仅限于特定区域或可用区的 Dataflow 作业。提交 Dataflow 作业时，您可以指定区域端点、工作器区域和工作器区域参数。这些参数控制工作器的部署位置以及作业元数据的存储位置。

Apache Beam 提供了一个框架，可让您在各种运行程序中执行流水线。您可以设计灾难恢复架构以利用此功能。例如，您可以使用 Apache Spark Runner 设计灾难恢复架构，使其具有在本地 Spark 集群上运行的备份流水线。如需了解特定运行程序是否能够执行某些流水线操作，请参阅 Beam 功能矩阵。

如果加密可让您缓解位置限制，您可以使用 Dataflow 中的 CMEK 加密流水线状态工件，以及访问受 Cloud KMS 密钥保护的来源和接收器。通过加密，您可以设计一个灾难恢复架构，该架构使用由于位置限制而无法使用的区域。

基于 BigQuery 构建的数据仓库

数据仓库支持分析和决策。除了包含分析数据库之外，数据仓库还包含多个分析组件和过程。

在为数据仓库设计灾难恢复规划时，请考虑以下特征：

• 大小。数据仓库比在线事务处理 (OLTP) 系统要大得多。数据仓库具有 TB 级到 PB 级数据的情况很常见。您需要考虑恢复此数据所需的时间，以实现 RPO 和 RTO 值。在规划灾难恢复策略时，您还必须考虑恢复 TB 级数据的费用。如需详细了解 BigQuery 的灾难恢复缓解技术，请参阅关于 Google Cloud 上的代管式数据库服务的备份和恢复机制部分中的 BigQuery 信息。

• 可用性。创建 BigQuery 数据集时，请选择存储数据的位置：单区域或多区域。单区域位置是单个特定的地理位置，例如爱荷华州 (us-central1) 或蒙特利尔 (northamerica-northeast1)。多区域位置是至少包含两个地理位置的大型地理区域，例如美国 (US) 或欧洲 (EU)。

  在设计灾难恢复计划以满足位置限制时，故障域（即故障是在机器级、可用区级还是区域级发生）会直接影响您能否实现定义的 RTO。如需详细了解这些故障域及其对可用性的影响，请参阅 BigQuery 的可用性和耐用性。

• 数据的性质。数据仓库包含历史信息，并且大多数旧数据通常是静态的。许多数据仓库设计为仅附加。如果您的数据仓库仅限附加数据，您可以通过仅恢复附加的数据来实现 RTO。在此方法中，您只需备份此附加数据。如果发生灾难，您可以恢复附加的数据，并让数据仓库可供使用，但具有部分数据。

• 数据添加和更新模式。数据仓库通常使用 ETL 或 ELT 模式进行更新。控制更新路径后，您可以从备用来源重现最近的更新事件。

您的位置要求可能会限制您的数据仓库是使用单个区域还是多个区域。虽然 BigQuery 数据集可以是区域性数据集，但多区域存储是发生灾难时确保数据可用性的最简单、最具成本效益的方法。如果您的区域中不提供多区域存储，但您可以使用其他区域，请使用 BigQuery Data Transfer Service 将数据集复制到其他区域。如果您可以使用加密来缓解位置要求，则可以使用 Cloud KMS 和 BigQuery 管理自己的加密密钥。

如果只能使用一个区域，请考虑备份 BigQuery 表格。备份表的最经济实惠的解决方案是使用 BigQuery 导出。使用 Cloud Scheduler 或 Cloud Composer 定期安排导出作业以写入 Cloud Storage。您可以使用格式，例如采用 SNAPPY 压缩的 Avro 或采用 GZIP 压缩的 JSON。在设计导出策略时，请注意导出的相关限制。

您可能还需要以列式格式（如 Parquet 和 ORC）存储 BigQuery 备份。它们提供高压缩能力，并允许与许多本地系统中可能存在的开源引擎（例如 Hive 和 Presto）进行互操作。下图概述了将 BigQuery 数据导出到列式格式以便存储在本地位置的过程。

具体而言，将 BigQuery 数据导出到本地存储位置的这个过程包括以下步骤：

• BigQuery 数据会发送到 Dataproc 上的 Apache Spark 作业。使用 Apache Spark 作业允许架构演变。
• 在 Dataproc 作业处理完 BigQuery 文件后，处理后的文件会写入 Cloud Storage，然后转移到本地灾难恢复位置。
• Cloud Interconnect 用于将 Virtual Private Cloud 网络连接到本地网络。
• 将数据转移到本地灾难恢复位置可通过 Spark 作业进行。

如果您的仓库设计为仅用于附加，并且按日期分区，您需要在新表上运行 BigQuery 导出作业之前在新表中创建所需分区的副本。然后，您可以使用 gsutil 等工具将更新后的文件转移到本地或其他云中的备份位置。（当您从 Google Cloud 转移数据时，可能会产生出站流量费用。）

例如，您有一个销售数据仓库，由一个仅附加 orders 的表组成，其中新订单附加到表示当前日期的分区。但是，退货政策可能允许在 7 天内退货。因此，过去 7 天内 orders 表中的记录可能会更新。您的导出策略需要考虑退货政策。在此示例中，任何备份 orders 表的导出作业还需要导出表示过去 7 天内订单的分区，以避免因退货而导致缺失更新。

后续步骤

• 阅读本 DR 系列中的其他文章：
  • 灾难恢复规划指南
  • 灾难恢复组件
  • 数据灾难恢复方案
  • 应用灾难恢复场景
  • 为受限于位置的工作负载设计灾难恢复架构
  • 针对云基础架构服务中断设计灾难恢复架构
• 阅读白皮书：了解 Google Cloud 欧洲客户的数据驻留情况、运维透明度和隐私权。
• 探索有关 Google Cloud 的参考架构、图表和最佳做法。查看我们的 Cloud Architecture Center。