跨 Google Cloud 区域迁移：为跨区域迁移准备数据和批量工作负载

Last reviewed 2023-12-08 UTC

本文档介绍如何在 Google Cloud 上设计数据平台，以最大限度地减少未来扩展到其他区域或进行区域间迁移的影响。本文档是系列文章中的一篇，可帮助您了解将数据平台扩展到其他区域的影响。本文档可帮助您了解如何执行以下操作：

  • 准备好迁移数据和数据流水线。
  • 在迁移阶段设置检查。
  • 通过分离数据存储和数据计算来创建灵活的迁移策略。

如果您不打算跨区域迁移或提前扩展到多个区域，则本系列中的指南也非常有用。在这种情况下，您可能需要花费额外的精力来准备基础架构、工作负载和数据，以便进行跨区域迁移以及扩展到多个区域。

本文档是以下系列文章中的一篇：

本系列假定您已阅读并熟悉以下文档：

下图说明了迁移过程的路径。

迁移路径包含四个阶段。

在每个迁移步骤中，您需要按照迁移到 Google Cloud：使用入门中定义的阶段执行操作：

  1. 评估和发现工作负载。
  2. 规划和构建基础。
  3. 部署工作负载。
  4. 优化您的环境。

Google Cloud 上的现代化数据平台

本部分介绍现代化数据平台的不同部分，以及在 Google Cloud 中通常如何构建它们。数据平台作为一般概念可以分为两个部分：

  • 数据存储层是保存数据的位置。要保存的数据可能采用文件形式，在这种情况下，您在 Hadoop 分布式文件系统 (HDFS) 或 Cloud Storage 等文件系统上管理实际字节，或者您可能使用网域特定语言 (DSL) 来管理数据库管理系统中的数据。
  • 数据计算层是您可以在存储系统之上激活的任何数据处理。与存储层一样，数据计算层有许多可能的实现，一些数据存储工具也处理数据计算。平台中数据计算层的作用是从存储层加载数据、处理数据，然后将结果保存到目标系统。目标系统可以是来源存储层。

某些数据平台对其数据存储层使用多个存储系统，对数据处理层使用多个数据计算系统。在大多数情况下，数据存储层与计算层是隔开的。例如，您可能使用以下 Google Cloud 服务实现了数据存储层：

您可能已经使用其他 Google Cloud 服务实现了数据计算层，例如以下服务：

为减少通信的时间和延迟时间、出站数据传输的费用以及存储层和计算层之间的 I/O 操作次数，我们建议您将数据存储在您处理数据的同一可用区。

我们还建议您将数据存储层与数据计算层隔开。将这些层分隔开可以提高更改计算层和迁移数据时的灵活性。将层分隔开可以减少资源使用量，因为您不必让计算层一直运行。因此，我们建议您在同一可用区和区域中的不同平台上部署数据存储和数据计算。例如，您可以将数据存储从 HDFS 移动到 Cloud Storage，并使用 Dataproc 集群进行计算。

评估您的环境

在评估阶段，您需要确定迁移已部署的批量数据流水线的要求和依赖项：

  1. 构建一个全面的数据流水线清单。
  2. 根据流水线的属性和依赖项对流水线进行分类。
  3. 为您的团队开展 Google Cloud 培训和指导
  4. 针对 Google Cloud 构建实验和概念验证。
  5. 计算目标环境的总拥有成本 (TCO)。
  6. 选择您首先要迁移的工作负载。

如需详细了解评估阶段和这些任务，请参阅迁移到 Google Cloud：评估和发现工作负载。以下部分基于该文档中的信息。

构建您的清单

如需确定迁移范围，您必须了解用于部署数据流水线的数据平台环境：

  1. 创建数据基础架构（即用于数据存储和批量数据处理的不同存储层和计算层）清单。
  2. 创建计划迁移的数据流水线的清单。
  3. 创建数据流水线正在读取且需要迁移的数据集的清单。

如需构建数据平台清单，对于数据基础设施的每个部分，请考虑以下事项：

  • 存储层。除了 Cloud Storage 等标准存储平台之外，还请考虑使用其他存储层（如 Firebase、BigQuery、Bigtable 和 Postgres 等数据库）或 Apache Kafka 等其他集群。每个存储平台都有自己完成迁移的策略和方法。例如，Cloud Storage 具有数据迁移服务，而数据库可能具有内置的迁移工具。确保用于数据存储的每款产品在目标环境中都可用，或者您拥有兼容的替代产品。练习并验证每个涉及的存储平台的技术数据传输过程。
  • 计算层。对于每个计算平台，请验证部署计划，并验证您可能对不同平台所做的任何配置更改。
  • 网络延迟。测试并验证来源环境与目标环境之间的网络延迟时间。请务必了解复制数据需要多长时间。您还需要测试从客户端和外部环境（例如本地环境）到目标环境的网络延迟时间（相较于来源环境）。

  • 配置和部署。每个数据基础架构产品都有自己的设置方法。清点您为每个组件创建的自定义配置，以及您为每个平台使用了哪些组件的默认版本（例如，使用的是哪个 Dataproc 版本或 Apache Kafka 版本）。确保这些配置可在自动部署流程中部署。

    您需要了解每个组件的配置方式，因为计算引擎的配置不同，其行为可能也会有所不同，尤其是处理层框架在迁移期间发生更改时。例如，如果目标环境运行的是不同版本的 Apache Spark，则 Spark 框架的某些配置可能因版本而异。此类配置更改可能会导致输出、序列化和计算发生变化。

    在迁移期间，我们建议您使用自动部署来确保版本和配置保持不变。如果您无法使版本和配置保持不变，则确保使用测试来验证框架计算的数据输出。

  • 集群大小。对于自行管理的集群（例如长效的 Dataproc 集群或在 Compute Engine 上运行的 Apache Kafka 集群），请记下集群中节点和 CPU 的数量以及每个节点的内存。迁移到另一个区域可能会导致您的部署使用的处理器发生更改。因此，我们建议您在将迁移后的基础架构部署到生产环境后剖析和优化工作负载。如果某个组件是全托管式或无服务器组件（例如 Dataflow），则容量将是每个作业而不是集群本身的一部分。

您在清单中评估的以下内容侧重于数据流水线：

  • 数据源和数据接收器。确保考虑到每个数据流水线用于读取和写入数据的来源和接收器。
  • 服务等级协议 (SLA) 和服务等级目标 (SLO)。批量数据流水线 SLA 和 SLO 通常在完成时测量，但也可以通过其他方式（例如使用的计算能力）进行测量。此业务元数据对于推动业务连续性和灾难恢复计划流程 (BCDR) 非常重要，例如在发生可用区级或区域级故障时将一部分最重要的流水线故障切换到另一个区域。
  • 数据流水线依赖项。某些数据流水线依赖于由其他数据流水线生成的数据。将流水线拆分为迁移 Sprint 时，请务必考虑数据依赖项。
  • 生成和使用的数据集。对于每个数据流水线，确定流水线使用的数据集及其生成的数据集。这样做可帮助您识别流水线之间以及整个架构中其他系统或组件之间的依赖项。

您在清单中评估的以下内容侧重于要迁移的数据集：

  • 数据集。确定需要迁移到目标环境的数据集。如果数据被归档并且未在使用中，您可能认为某些历史数据不需要迁移或在其他时间进行迁移。通过定义迁移过程和迁移 Sprint 的范围，可以降低迁移风险。
  • 数据大小。如果您打算在转移文件之前将其压缩，请务必在压缩前后记下文件大小。数据的大小会影响将数据从来源复制到目标位置所需的时间和费用。考虑这些因素有助于您在停机时间策略之间进行选择，如本文档后面所述。
  • 数据结构。对要迁移的每个数据集进行分类，同时确保您了解数据是结构化、半结构化还是非结构化数据。了解数据结构后，策略就知道如何验证数据是否正确且完整地迁移。

完成评估

构建与 Kubernetes 集群和工作负载相关的清单后，请完成迁移到 Google Cloud：评估和发现工作负载中的评估阶段的其余活动。

规划和构建基础

迁移到 Google Cloud 的计划和构建阶段包括以下任务：

  1. 构建资源层次结构。
  2. 配置 Identity and Access Management (IAM)。
  3. 设置结算功能。
  4. 设置网络连接。
  5. 强化安全性。
  6. 设置日志记录、监控和提醒。

如需详细了解这些任务，请参阅迁移到 Google Cloud：规划和构建基础。

迁移数据和数据流水线

以下部分描述了数据和批量数据流水线迁移计划的一些方面。它定义了一些有关数据流水线特征的概念，您在创建迁移计划时务必了解这些概念。此外，本部分还讨论了一些数据测试概念，有助于提升您对数据迁移的信心。

迁移计划

在迁移计划中，您需要留出时间来完成数据传输。您的计划应考虑到网络延迟时间、测试数据完整性所需的时间、获取迁移失败的所有数据所需的时间以及任何网络费用。由于数据将从一个区域复制到另一个区域，因此网络费用计划应包括区域间网络费用。

我们建议您将不同的流水线和数据集划分为 Sprint 并单独迁移。此方法有助于降低每个迁移 Sprint 的风险，并且有助于在每次 Sprint 中进行改进。如需改进迁移策略并尽早发现问题，我们建议您先迁移较小的非关键工作负载，然后再迁移较大的更关键的工作负载。

迁移计划的另一个重要部分是描述计算层中不同数据流水线的策略、依赖项和性质。如果您的数据存储层和数据计算层基于同一系统构建，我们建议您在复制数据时监控系统的性能。通常，复制大量数据的行为可能会导致系统产生 I/O 开销，并降低计算层的性能。例如，如果您运行一个从 Kafka 集群批量提取数据的工作负载，则读取大量数据的额外 I/O 操作可能会导致仍在来源环境中运行的活跃数据流水线性能下降。在这种情况下，您应该使用任何内置或自定义指标来监控系统的性能。为避免系统过载，我们建议您制定一份计划，以在数据复制过程中停用一些工作负载或限制复制阶段。

由于复制数据会使迁移过程长时间运行，因此我们建议您制定应急计划，以解决迁移期间可能出现的问题。例如，如果移动数据所需的时间超出预期，或者在将新系统上线之前完整性测试失败，请考虑是回滚还是尝试修复并重试失败的操作。虽然回滚是更简洁的解决方案，但多次复制大型数据集可能非常耗时且昂贵。建议您要有一个清晰的了解并预定义测试，以便决定在哪些条件下执行哪些操作、允许花多长时间尝试创建补丁，以及何时执行完全回滚。

区分用于迁移的工具和脚本与您复制的数据非常重要。回滚数据移动意味着您必须重新复制数据，并替换或删除您已复制的数据。回滚对工具和脚本所做的更改可能更轻松，费用也更低，但回滚对工具所做的更改可能会迫使您重新复制数据。例如，如果您在动态生成 Cloud Storage 位置的脚本中创建新的目标路径，则可能需要重新复制数据。为了帮助避免重新复制数据，构建的脚本应支持可恢复性和幂等性。

数据流水线特征

为了创建最佳迁移计划，您需要了解不同数据流水线的特征。请务必注意，写入数据的批量流水线与读取数据的批量流水线不同：

  • 写入数据的数据流水线：由于它会更改来源系统的状态，因此很难在将数据复制到目标环境的同时将数据写入来源环境。请考虑写入数据的流水线运行时，并尝试在整个过程的早期确定其迁移优先级。这样，您就可以在迁移读取数据的流水线之前在目标环境中准备好数据。
  • 读取数据的数据流水线：读取数据的流水线可能对数据新鲜度有不同的要求。如果生成数据的流水线在来源系统上停止，则读取数据的流水线可能会在数据复制到目标环境时运行。

数据是状态，在区域之间复制数据并不是一项原子操作。因此，在复制数据时，您需要注意状态的变化。

在迁移计划中区分系统也很重要。您的系统可能有不同的功能性和非功能性要求（例如，一个系统用于批处理，另一个系统用于流式传输）。因此，您的计划应包含用于迁移各个系统的不同策略。请务必在系统之间指定依赖项，并指定在迁移的每个阶段如何缩短每个系统的停机时间。

典型的 Sprint 迁移计划应包含以下内容：

  • 一般策略。介绍用于在此 Sprint 中处理迁移的策略。如需了解常见策略，请参阅部署工作负载。
  • 数据复制和资源部署的工具和方法列表。指定您计划用于复制数据或将资源部署到目标环境的任何工具。该列表应包含用于复制 Cloud Storage 资产的自定义脚本、标准工具（如 Google Cloud CLI）和 Google Cloud 工具（如迁移服务）。
  • 要部署到目标环境的资源列表。列出需要在目标环境中部署的所有资源。此列表应包含所有数据基础架构组件，例如 Cloud Storage 存储桶、BigQuery 数据集和 Dataproc 集群。在某些情况下，早期迁移 Sprint 将包括小容量部署大小固定的集群（如 Dataproc 集群），而后期的 Sprint 将包括根据新工作负载调整大小。确保您的计划包含可能的大小调整。
  • 要复制的数据集的列表。对于每个数据集，请务必指定以下信息：
    • 复制顺序（如适用）：对于大多数策略，操作顺序可能很重要。本文档后续部分介绍的计划性维护策略是一个例外。
    • 大小
    • 关键统计信息：绘制关键统计信息（例如行号）的图表，以帮助您验证数据集是否已成功复制。
    • 预计复制时间：完成数据传输所需的时间，具体取决于迁移计划。
    • 复制方法：请参阅本文档前面介绍的工具和方法列表。
    • 验证测试：明确列出您计划完成的测试，以验证数据是否已完整复制。
    • 应急计划：说明在验证测试失败时的应对措施。您的应急计划应指定何时重试和恢复复制或填补缺口，以及何时执行完整回滚并重新复制整个数据集。

测试

本部分介绍您可以规划的一些典型测试类型。这些测试有助于确保数据完整性。还可以帮助您确保计算层按预期工作并准备好运行数据流水线。

  • 摘要或哈希比较：为了在复制数据后验证数据完整性，您需要将原始数据集与目标环境中的新副本进行比较。如果数据在 BigQuery 表中进行结构化，则您不能联接查询中的两个表来查看所有数据是否存在，因为这些表位于不同的区域。出于费用和延迟时间方面的原因，BigQuery 不允许查询跨区域联接数据。相反，比较方法必须汇总每个数据集并比较结果。汇总方法可能因数据集结构而异。例如，BigQuery 表可能使用聚合查询，但 Cloud Storage 上的一组文件可能使用 Spark 流水线来计算每个文件的哈希值，然后聚合哈希值。

  • Canary 流：Canary 流激活为验证数据完整性而构建的作业。在继续处理数据分析等业务应用场景之前，运行 Canary 流作业以确保输入数据符合一组前提条件会很有用。您可以将 Canary 流作为自定义数据流水线实现，也可以作为基于 Cloud Composer 的 DAG 中的流实现。Canary 流可帮助您完成某些任务，例如验证某些字段是否没有缺失值，或者验证特定数据集的行数与预期的数量是否一致。

    您还可以使用 Canary 流创建列或数据子集的摘要或其他聚合。然后，您可以使用 Canary 流将数据与从数据副本中获取的类似摘要或聚合进行比较。

    如果您需要评估以文件格式（例如 Cloud Storage 之上的 Avro 文件）存储和复制的数据的准确率，Canary 流方法非常有用。Canary 流通常不会生成新数据，但如果输入数据不满足某组规则，它们就会失败。

  • 测试环境：完成迁移计划后，您应该在测试环境中测试计划。测试环境应包括将抽样数据或预演数据复制到另一个区域，以估算通过网络复制数据所需的时间。此测试可帮助您识别迁移计划出现的任何问题，并验证数据是否可以成功迁移。测试应包括功能测试和非功能测试。功能测试会验证数据是否已正确迁移。非功能测试会验证迁移是否满足性能、安全性和其他非功能性要求。计划中的每个迁移步骤都应包含一个验证条件，其中详细说明了此步骤何时可以视作完成。

为帮助验证数据，您可以使用数据验证工具 (DVT)。该工具会执行多级数据验证函数（从表级别到行级别），并帮助您比较来源系统和目标系统的结果。

您的测试应验证计算层的部署并测试复制的数据集。完成此操作的一种方法是构建这样一个测试流水线，该流水线可以计算复制的数据集的一些聚合，并确保来源数据集和目标数据集匹配。当您在区域之间复制的文件不是来源系统和目标系统之间精确的字节副本表示形式时（例如，当您更改文件格式或文件压缩时），来源数据集和目标数据集不一致的问题更常见。

例如，假设一个数据集由以换行符分隔的 JSON 文件组成。这些文件存储在 Cloud Storage 存储桶中，并作为外部表装载到 BigQuery 中。如需减少通过网络移动的数据量，您可以先在迁移过程中执行 Avro 压缩，然后再将文件复制到目标环境。这种转换有许多优点，但也存在一些风险，因为写入目标环境的文件不是来源环境中文件的字节副本表示形式。

为了降低转换场景带来的风险，您可以创建 Dataflow 作业，或使用 BigQuery 计算数据集的部分聚合和校验和哈希（例如，通过计算每个数字列的总和、平均数或分位数）。对于字符串列，您可以在字符串长度之上或该字符串的哈希代码上计算聚合。对于每一行，您都可以计算所有其他列的组合的聚合哈希，这样可以高度精确地验证某一行是否与其来源相同。这些计算在来源环境和目标环境中进行，然后进行比较。在某些情况下（例如，数据集存储在 BigQuery 中时），您无法联接来源环境和目标环境中的表，因为它们位于不同的区域，因此需要使用可以连接到这两个环境的客户端。

您可以在 BigQuery 中或以批量作业（如 Dataflow）形式实现上述测试方法。然后，可以运行聚合作业，并将为来源环境计算的结果与为目标环境计算的结果进行比较。此方法有助于确保数据完整且准确。

测试计算层的另一个重要方面是运行包含各种处理引擎和计算方法的流水线。对于 BigQuery 或 Dataflow 等代管式计算引擎，流水线的测试并不重要。但测试非代管式计算引擎（如 Dataproc）的流水线非常重要。例如，如果您的 Dataproc 集群处理多种不同类型的计算（例如 Apache Spark、Apache Hive、Apache Flink 或 Apache MapReduce），则应测试每个运行时，确保不同的工作负载类型已准备好进行转移。

迁移策略

通过适当的测试验证迁移计划后，便可以迁移数据。迁移数据时，您可以对不同的工作负载使用不同的策略。以下是您可以按原样使用或根据需要进行自定义的迁移策略示例：

  • 计划性维护：您可以计划切换期发生的时间。如果数据经常更改，但 SLO 和 SLA 可以承受一些停机时间，则此策略非常有用。此策略可确保已转移的数据的置信度较高，因为数据在复制时已完全过时。如需了解详情，请参阅“迁移到 Google Cloud：转移大型数据集”中的计划性维护。
  • 只读切换：它与计划性维护策略略有不同，在这种策略中，来源系统数据平台允许只读数据流水线在复制数据时继续读取数据。此策略非常有用，因为某些数据流水线可以继续运行并为终端系统提供数据分析。此策略的缺点是生成的数据在迁移期间会过时，因为来源数据并不会更新。因此，您可能需要在迁移后采用同步策略，以考虑终端系统中过时的数据。
  • 完全活跃：您可以在特定时间戳复制数据，而来源环境仍然保持活跃状态（针对读取和写入数据流水线）。复制数据并切换到新部署后，执行增量复制阶段以获取在来源环境中的迁移时间戳之后生成的数据。与其他策略相比，此方法需要的协调工作和考虑事项更多。因此，您的迁移计划必须包含源数据更新和删除操作的处理方式。
  • 双重写入：在复制数据时，数据流水线可以在来源环境和目标环境中运行。此策略可避免使用完全活跃或只读策略时回填数据所需的增量复制阶段。但是，为帮助确保数据流水线生成相同的结果，双重写入策略需要您在迁移之前执行更多测试。如果未执行高级测试，则在尝试整合脑裂场景时可能会遇到问题。如果在不同区域运行两次相同的工作负载，双重写入策略还会产生潜在的费用。此策略可以在不产生停机时间的情况下迁移平台，但需要完成更多协调工作才能正确执行。

迁移后测试

迁移完成后，您应该测试数据完整性并测试数据流水线的有效性。如果您以 Sprint 形式完成迁移，则需要在每个 Sprint 完成后执行这些测试。您在此阶段执行的测试与集成测试类似：即测试运行业务用例的数据流水线的有效性（将完整生产级数据作为输入），然后检查输出的有效性。通过在来源环境和目标环境中运行相同的数据流水线，您可以将集成测试的输出与来源环境的输出进行比较。仅当数据流水线是确定的并且您可以确保两个环境的输入相同时，这种类型的测试才有效。

当数据满足一组预先确定的标准（来源环境中的数据与目标环境中的数据相等或足够相似）时，可以确认数据是完整的。根据您在上一部分中使用的策略，数据可能无法一对一匹配。因此，您需要预先确定相应标准来描述使用场景的数据完整性。例如，对于时序数据，如果最新记录不超过当前时间戳五分钟，则可以认为数据是完整的。

切换

在目标环境中验证和测试数据和数据流水线后，便可以启动切换阶段。启动此阶段意味着客户端可能需要更改其配置才能引用新系统。在某些情况下，配置不能与指向来源系统的配置相同。例如，如果服务需要从 Cloud Storage 存储桶读取数据，则客户端需要更改要使用的存储桶的配置。Cloud Storage 存储桶名称是全局唯一的，因此您的目标环境 Cloud Storage 存储桶与来源环境不同。

在切换阶段，您应该停用和取消安排来源环境工作负载。我们建议您将来源环境数据保留一段时间，以防需要回滚。

迁移前测试阶段并不像数据流水线的生产运行那样完整。因此，在切换完成并且目标系统正常运行后，您需要监控数据流水线的指标、运行时和语义输出。此监控可帮助您捕获测试阶段可能遗漏的错误，并帮助确保迁移成功。

优化您的环境

优化是迁移的最后一个阶段。在此阶段，您将对可重复的循环执行多次迭代，直到环境满足您的优化要求，从而使环境更加高效：

  1. 评估您的当前环境、团队和优化循环。
  2. 确定优化要求和目标。
  3. 优化您的环境和团队。
  4. 调整优化循环。

如需详细了解如何优化 Google Cloud 环境，请参阅迁移到 Google Cloud：优化您的环境。

准备 Google Cloud 数据和计算资源，以便跨区域进行迁移

本部分简要介绍了 Google Cloud 上的数据和计算资源，以及相关设计原则，以便为跨区域迁移做好准备。

BigQuery

由于 BigQuery 是一个无服务器 SQL 数据仓库，因此您无需部署计算层。如果您的某些 BigQuery 客户端指定了处理区域，则需要调整这些客户端。否则，BigQuery 在来源环境和目标环境中相同。BigQuery 数据存储在两种表中：

  • BigQuery 表：BigQuery 格式的表。BigQuery 会为您管理数据文件。如需详细了解如何迁移 BigQuery 格式的数据，请参阅管理数据集。
  • BigQuery 外部表：将数据存储在 BigQuery 外部的表。移动数据后，您需要在新的目标位置中重新创建外部表。如需详细了解如何迁移外部表，请参阅外部表简介。

Cloud Storage

Cloud Storage 提供可帮助您迁移数据的 Storage Transfer Service。

Dataflow（批量）

Dataflow 是一个由 Google 管理的数据处理引擎。为了帮助简化 Dataflow 迁移并确保作业可以轻松部署到任何区域，您应该将所有输入和输出作为参数注入作业。我们建议您将 Cloud Storage 路径和数据库连接字符串作为实参或形参传递，而不是在源代码中写入输入和输出数据位置。

Dataproc

Dataproc 是一个托管式 Apache Hadoop 环境，该环境可以运行与 Apache Hadoop 框架兼容的任何工作负载。它与 Apache Spark、Apache Flink 和 Apache Hive 等框架兼容。

您可以通过以下方式使用 Dataproc，这会影响您跨区域迁移 Dataproc 环境的方式：

  • Cloud Storage 上包含数据的临时集群：集群是为了运行特定作业而构建的，会在作业完成后被销毁。这意味着 HDFS 层或集群的任何其他状态也会被销毁。如果您的配置符合以下条件，则与其他使用类型相比，这种使用类型更易于迁移：
    • 作业的输入和输出并未硬编码到源代码中。相反，作业将接收输入和输出作为参数。
    • Dataproc 环境预配是一项自动化操作，包括您的环境使用的各个框架的配置。
  • 具有外部数据的长效集群：您有一个或多个集群，但它们是长效集群 - 即使集群上没有正在运行的作业，集群也仍然正常运行。数据与计算是分开的，因为数据保存在 Google Cloud 解决方案（如 Cloud Storage 或 BigQuery）上的集群外部。如果集群上始终有运行的作业，则此模型通常有效，因此，像在临时模型中那样清理和设置集群是没有意义的。由于数据和计算是分开的，因此迁移类似于临时模型的迁移。
  • 集群中具有数据的长效集群：集群是长效集群，但集群也在集群内部保留状态和/或数据，最常见的是保留为 HDFS 上的数据。这类使用会使迁移工作复杂化，因为数据和计算不是分开的：如果您只迁移其中一个而不迁移另一个，则很可能出现不一致的情况。在这种情况下，请考虑在迁移之前将数据和状态移到集群外部，以将两者分开。如果无法采用此方法，我们建议您使用计划性维护策略来降低造成数据不一致的风险。

由于存在许多潜在的框架并且它们有多种版本和配置，因此在执行迁移计划之前，您需要进行全面测试。

Cloud Composer

Cloud Composer 是 Google Cloud 的代管式 Apache Airflow 版本，用于编排和安排流。DAG、配置和日志在 Cloud Storage 存储桶中进行管理，该存储储桶应与您的 Cloud Composer 部署一起迁移。如需迁移 Cloud Composer 部署的状态，您可以保存和加载环境快照。

如果您已将任何自定义插件部署到 Cloud Composer 实例，我们建议您应用基础架构即代码方法，以完全自动化的方式重新创建环境。

Cloud Composer 不会管理数据，但会激活其他数据处理框架和平台。因此，Cloud Composer 的迁移与数据完全隔离。Cloud Composer 也不会处理数据，因此您的部署不需要与数据位于同一区域。因此，您可以在目标环境中创建 Cloud Composer 部署，并且仍在来源环境中运行流水线。在某些情况下，当正在迁移整个平台时，这样做对于在不同区域操作不同的流水线很有用。

Cloud Data Fusion

Cloud Data Fusion 是一种可视化集成工具，可帮助您使用可视化编辑器构建数据流水线。Cloud Data Fusion 基于开源项目 CDAP。与 Cloud Composer 一样，Cloud Data Fusion 本身不管理数据，但会激活其他数据处理框架和平台。您应该从来源环境导出 Cloud Data Fusion 流水线，并通过以下方式之一将其导入到目标环境：

根据需要迁移的流数量，您可能偏好其中一种方法。使用 CDAP API 构建迁移脚本可能很难，并且需要更多软件工程技能。但如果您有许多流，或者流变化得相对频繁，自动化过程可能是最佳方法。

后续步骤

贡献者

作者：Eyal Ben Ivri | 云解决方案架构师

其他贡献者：Marco Ferrari | 云解决方案架构师