灾难恢复

Azure Databricks 的灾难恢复（DR）可在不同云区域之间复制工作区、数据和配置，以便在区域性故障导致主要部署离线时，团队仍能继续工作。完整的 DR 计划不仅涵盖Azure Databricks，还包括数据源、引入工具、BI 工具和连接到的计划程序。

本页介绍设计和运行跨区域 DR 解决方案所需的概念、策略、工具和测试过程。

DR 规划新手？从灾难恢复行业术语开始，了解 RPO 和 RTO 的定义。

重要

使用托管灾难恢复。 Azure Databricks 建议在 AWS 和 Azure 上针对跨区域灾难恢复（DR）采用托管式灾难恢复方案。它按连续计划复制 Unity 目录元数据、托管表数据和工作区资产，提供一个在故障转移中幸存下来的稳定 URL，并允许从帐户控制台触发故障转移。无需编写或维护任何复制脚本。仅在以下情况下使用本页上的 DIY 指南：对于托管式 DR 不会复制的资源，或者在您需要主动-主动拓扑结构、跨云复制或对复制管道进行精细控制时。

区域内部高可用性保证

本页的其余部分介绍跨区域 DR，但Azure Databricks还在单个区域中提供高可用性（HA）。首先了解这些保证。它们决定是否需要单独的灾难恢复策略。

HA 和 DR 解决了不同的问题：

HA 在一个区域内采用可用区（AZ）冗余。如果一个区域失败，则服务会继续在其他区域中运行。
DR 使用区域间复制。在另一个区域运行辅助 Azure Databricks 工作区，并将数据和配置复制到这些工作区中，然后在发生区域中断时进行故障转移。

如果不需要多区域 DR，Azure Databricks HA 可能就足够了。 HA 可避免跨区域复杂性，但无法防止全区域中断。如果仅依赖于 HA 进行 DR，请验证云区域的分离和冗余。

区域内 HA 保证涵盖控制平面和计算平面。

Azure Databricks控制平面的可用性

Azure Databricks 控制平面能够承受可用区故障的影响，并会在发生可用区故障后约 15 分钟内自动恢复。常规区域故障测试会验证这一点。

所有无状态控制平面服务都可能会丢失单个 VM 或整个区域中的所有 VM，而无需关闭服务。工作区数据存储在区域中跨区域复制的数据库中。为 Databricks Runtime 映像提供服务的存储账户在区域内也采用冗余部署，并且所有区域都配有辅助存储账户，在主存储账户发生故障时接管服务。

注释

上述控制平面保证适用于Azure Databricks管理的基础结构。你负责计算平面区域冗余，例如，为工作区根存储桶选择区域冗余存储，并使用跨可用性区域的实例池。

某些Azure区域使用在配对区域中部署的控制平面。请参阅 Azure Databricks 区域。

区域故障复原最多支持一个正在关闭的区域，并且仅在支持多个区域的Azure区域中可用。

计算平面的可用性

工作区可用性取决于控制平面的可用性。

如果存储帐户配置了区域冗余存储（ZRS）或异地区域冗余存储（GZRS），则 DBFS 根数据不会受到影响。默认值为异地冗余存储（GRS）。

通过向 Azure 计算提供程序请求节点，可以从不同的可用区调配群集节点，前提是其余可用区具有足够的容量。如果某个节点丢失，群集管理器会从 Azure 计算提供程序请求替换节点，该提供程序会从可用的 AZ 中拉取这些节点。例外情况是驱动程序节点丢失时。在这种情况下，群集管理器将重启作业和群集。

若要确认多 AZ 支持，请参阅Azure 区域列表。对于计算平面的多可用区 (AZ) 复原能力，请使用区域冗余存储。

术语

与团队讨论 DR 时，请一致地使用这些定义。

区域术语

此页面使用以下区域定义：

主要区域：用户每天运行交互式和自动化数据分析工作负荷的区域。
次要区域：IT 团队在主要区域中断期间临时移动工作负荷的区域。
异地冗余存储：持久存储的异步跨区域复制。请参阅您所使用的云服务文档：

跨区域（Azure）的异地冗余存储。

重要

请勿依赖异地冗余存储来跨区域复制 Azure Databricks 根存储（例如，Azure Databricks 为每个工作区创建的 ADLS；对于 2023 年 3 月 6 日之前创建的工作区，则为 Azure Blob 存储）。若要复制托管表数据，请使用 Delta Deep Clone；对于非 Delta 数据，请尽可能先将其转换为 Delta 格式。

部署状态术语

此页面使用以下部署状态定义：

活动部署 （有时称为 热部署）：用户连接到它并运行工作负荷。作业和数据流按计划在此处运行。
被动部署 （有时称为 冷部署）：此处未运行任何进程。 IT 团队通过自动部署代码、配置和其他Azure Databricks对象来使其准备就绪。仅当主动部署出现故障时，被动部署才会变为主动部署。

重要

项目可以包括不同区域中的多个被动部署，以便实现额外的复原能力。

大多数团队同一时间只运行一个活动部署，即主动-被动策略。不太常见的主动-主动策略运行两个同时处于活动状态的部署。

灾难恢复行业术语

在团队中定义这两个行业术语：

恢复点目标（RPO）：服务在重大事件期间可以容忍的最大数据丢失期。

Azure Databricks不会存储主要客户数据。其存储在 ADLS 中（对于 2023 年 3 月 6 日之前创建的工作区，则存储在 Azure Blob 存储中），或存储在其他由你控制的系统中。 Azure Databricks 的控制平面会存储某些对象（例如作业和笔记本），因此，Azure Databricks 的 RPO 是这些对象的更改可能丢失的最长时间段。你负责在 ADLS 中为客户数据定义 RPO（对于在 2023 年 3 月 6 日之前创建的工作区，Azure Blob 存储）以及你控制的其他数据源。
恢复时间目标（RTO）：在发生灾难后必须还原业务流程的最长时间。

灾难恢复和数据损坏

DR 解决方案不会缓解数据损坏。主要区域中损坏的数据将复制到次要区域，并且在这两个区域中都已损坏。若要缓解此类故障，请使用增量时间旅行、类似工具或数据备份工具。

典型恢复工作流

Azure Databricks DR 方案通常如下所示：

故障在主要区域中命中关键服务：数据源、网络或其他Azure Databricks部署依赖的依赖项。
你与云服务提供商一起进行调查。
如果等待是不能接受的，则决定故障转移到次要区域。
确认相同的问题不会影响次要区域。
故障转移（有关详细步骤，请参阅测试故障转移）：
1. 停止所有工作区活动。用户可尽可能停止工作负荷并备份最近的更改。作业会停止运行（如果此次中断还没有先一步导致它们失败）。
2. 运行次要区域恢复过程以更新路由和重定向连接和网络流量。
3. 将下游系统（BI 工具、计划程序、第三方集成）重新指向辅助工作区并恢复其连接。
4. 测试完成后，声明次要区域可运行。用户登录到现已激活的部署，并重新触发计划作业或延迟执行的作业。
在主区域中的问题得到缓解后，请确认修复已生效。
故障回复（有关详细信息，请参阅测试还原（故障回复））：
1. 停止次要区域中的所有工作。
2. 运行主要区域恢复过程以重定向回路由。
3. 将任何新数据复制回主要区域。尽量减少需要复制的内容。例如，在辅助部署中运行的只读作业可能不需要写回。
4. 测试主要区域部署。
5. 声明主要区域处于活动状态并恢复生产工作负荷。

重要

这些步骤中可能会发生一些数据丢失。定义组织可接受的损失量，以及如何缓解损失。

步骤 1：了解你的业务需求

确定哪些数据服务至关重要，并定义其目标 RPO 和 RTO。研究每个系统在实际环境中的容差范围。

DR、故障转移和故障回复会带来实际成本和风险，包括数据损坏、数据重复（写入错误存储位置）和用户在错误区域中进行更改。

梳理所有影响您业务的 Azure Databricks 集成点，并选择您的计划中使用的工具和沟通渠道。

要映射的集成点

DR 解决方案是否需要适应交互式进程、自动化流程或两者？
你使用哪些数据服务？有些可能是本地部署的。
输入数据如何到达云？
谁会使用此数据？哪些过程在下游使用了该数据？
是否有需要知悉 DR 变更的第三方集成？

用于规划的工具和通信

是否可以预定义配置并将其模块化，以自然且可维护的方式容纳 DR 解决方案？
哪些通信工具和渠道用于通知内部团队和第三方（集成方、下游消费者）有关灾难恢复（DR）故障转移和故障回切变更的信息？如何确认他们的确认？
在完成恢复之前，是否关闭了哪些服务（如果有）？

步骤 2：选择可满足业务需求的过程

默认使用托管灾难恢复。 它无需自定义脚本即可支持工作区复制、Unity Catalog 元数据、托管表数据以及故障转移编排。仅当您的需求超出上述指导的适用范围时，才使用下面的 DIY 指南，例如托管式 DR 未复制的资源、主主拓扑、跨云复制，或者需要对复制流水线进行细粒度控制。

DIY 解决方案必须跨控制平面、计算平面和数据源复制正确的数据。冗余工作区映射到不同区域中的不同控制平面，因此可以将它们与基于脚本的解决方案（同步工具或 CI/CD 工作流）保持同步。对于数据本身，大多数团队使用 Azure Databricks 作业（通常按计划运行）或 Delta Deep Clone 在不同区域之间复制表。不需要从计算平面内部同步数据（例如从 Databricks Runtime 工作器）。

如果使用 VNet 注入功能（不适用于所有订阅和部署类型），请使用基于模板的工具（如 Terraform）在两个区域中一致地部署网络。

根据需要跨区域复制数据源。

DR 解决方案通常涉及两个（或更多）工作区。根据您必须容忍的中断时长、运维工作量以及故障回切到主区域的成本，在以下策略中进行选择。

常规最佳做法

一般最佳做法

成功的 DR 计划的一般最佳做法包括：

了解哪些流程对业务至关重要，必须在 DR 中运行。
明确标识涉及哪些服务、正在处理哪些数据、数据流是什么以及存储到何处。
尽可能隔离服务和数据。例如，为 DR 数据创建特殊的云存储容器，或将灾难期间所需的Azure Databricks对象移动到单独的工作区。
你负责维护主部署和辅助部署之间的完整性，这些对象不存储在Azure Databricks控制平面中。
对于数据源，请尽可能使用本机Azure工具将数据复制到 DR 区域。

警告

请勿将数据存储在用于 DBFS 根访问的 ADLS 根目录中（对于 2023 年 3 月 6 日之前创建的工作区，则为 Azure Blob 存储）。生产客户数据不支持 DBFS 根存储。 Azure Databricks 还建议不要在其中存储库文件、配置文件或初始化脚本。

主动-被动解决方案策略

本部分重点介绍主动-被动策略，因为它是最常见的、最简单的和最经济高效的策略。主动-被动方案会将数据及对象变更从您的主动部署同步到次要区域中的被动部署。在 DR 事件期间，被动部署将变为主动。

两个常见变体：

统一（企业范围）：一组主动和被动部署支持整个组织。
按部门或项目：每个域都维护自己的 DR 解决方案，主要区域和次要区域根据需求定制。

还可以对不修改数据或Azure Databricks对象的只读工作负荷（例如用户查询）使用被动部署。

主动-主动解决方案策略

在主动-主动架构中，所有数据处理流程始终在两个区域并行运行。只有在两个区域中成功后，运营团队才能将每个作业标记为已完成。对象在生产环境中不可更改，并且必须遵循从开发/预发布到生产环境的严格 CI/CD 晋升流程。

主动-主动是最复杂且成本更高的策略，因为作业会在两个区域同时运行，但它可提供最低的 RTO 和 RPO。

您可以在整个企业范围内部署主动-主动模式，也可以按部门部署。你不需要为每个工作负载都创建一个单独的工作区。例如，开发或预发布工作区通常更容易通过开发流水线重新创建，而不是让其始终保持同步。

选择工具

在主要区域和次要区域中的工作区之间保持数据同步有两种主要方法：

从主要区域复制到次要区域的同步客户端：同步客户端将生产数据和资产从主要区域推送到次要区域。通常，这会按预定计划运行，而计划执行频率取决于您的目标 RTO 和 RPO。
用于并行部署的 CI/CD 工具：对于生产代码和资产，请使用 CI/CD 工具将更改同时推送到两个区域。例如，在将代码和资产从过渡/开发推送到生产时，CI/CD 系统会使其同时在两个区域中可用。核心理念是将 Azure Databricks 工作区中的所有项目都视为基础结构即代码。大多数工件可以同时部署到主工作区和辅助工作区，而某些工件可能需要在发生灾难恢复事件后才进行部署。有关工具，请参阅自动化脚本、示例和原型。

根据你的需求，你可以组合这些方法。例如，将 CI/CD 用于笔记本源代码，但将同步用于配置（如池和访问控制）。

下表介绍了如何使用每个工具选项处理每种类型的数据。

说明	如何使用 CI/CD 工具进行处理	如何使用同步工具进行处理
源代码：笔记本源代码导出和打包库的源代码	将两者共同部署到主要区域和次要区域。	将源代码从主要区域同步到次要区域。
用户和组	在 Git 中将元数据作为配置进行管理。或者，两个工作区都使用相同的身份提供商 (IdP)。将用户和组数据共同部署到主要部署和辅助部署。	为两个区域使用其他自动化。不建议手动创建，但如果使用，则必须同时进行这两个操作。如果使用手动设置，请创建计划的自动化过程，以比较两个部署之间的用户和组列表。
池配置	可以是 Git 中的模板。同时部署到主节点和备用节点。但是，在发生灾难恢复（DR）事件之前，次要副本中的 `min_idle_instances` 必须为零。	使用 API 或 CLI 将池同步到次要工作区时，使用任何 `min_idle_instances` 创建的池。
作业配置	使用 Databricks 资产捆绑包并结合按环境划分的目标（例如 `prod` 和 `dr`），将同一作业定义部署到这两个区域。对于次要部署，请将并发设置为零，使作业处于暂存状态而不运行。在次级部署激活后更改并发值。	如果作业由于某种原因在现有 `<interactive>` 群集上运行，则同步客户端需要映射到次要工作区中的相应 `cluster_id`。
访问控制列表 (ACL)	可以是 Git 中的模板。同时部署到笔记本、文件夹和群集的主要和次要部署环境。不过，请保留作业数据，直到发生灾难恢复（DR）事件。	权限 API 可以为群集、作业、池、笔记本和文件夹设置访问控制。同步客户端需要映射到备用工作区中每个对象的相应对象 ID。 Databricks 建议创建对象 ID 从主要工作区到次要工作区的映射，同时在复制访问控制之前同步这些对象。
软件库	包含在源代码和群集/作业模板中。	从集中式存储库、DBFS 或云存储（可以装载）中同步自定义库。
群集初始化脚本	如果您愿意，可以包含在源代码中。	为了简化同步，将 init 脚本存储在主要工作区的公用文件夹或一小部分文件夹中（如果可能）。
装入点	如果仅通过基于笔记本的作业或命令 API 创建，则将其包含到源代码中。	使用作业，这些作业可以作为 Azure 数据工厂 (ADF) 活动运行。请注意，假设工作区位于不同区域，则存储终结点可能会发生更改。这在很大程度上取决于数据 DR 策略。
表元数据	对于 Unity Catalog 对象（目录、架构、表、卷和授权），请与 Databricks Terraform provider 或 Databricks Asset Bundles 一并部署。对于旧版 Hive 元存储表，如果这些表是通过基于笔记本的作业或 Command API 创建的，请一并包含源代码和 CREATE TABLE 语句。	对于 Unity Catalog 对象，请从系统表或 `information_schema` 读取源元数据，并使用 Databricks SDK 将其复制到辅助工作区。对于旧版 Hive 元存储表，请通过笔记本或脚本，使用 Spark 目录 API 或 `SHOW CREATE TABLE` 比较不同元存储之间的元数据定义。基础存储路径可以基于区域，在元存储实例之间可能有所不同。
机密	如果仅通过命令 API 创建，则包含在源代码中。请注意，某些机密内容可能需要在主要区域和次要区域之间进行更改。	机密是通过 API 在两个工作区中创建的。请注意，某些机密内容可能需要在主要区域和次要区域之间进行更改。
群集配置	可以是 Git 中的模板。共同部署到主要部署和辅助部署，尽管辅助部署中的部署应终止，直到 DR 事件为止。	使用 API 或 CLI 将群集同步到次要工作区后，便可以创建群集。如果需要，可以根据自动终止设置显式终止这些群集。
笔记本、作业和文件夹权限	可以是 Git 中的模板。同时部署到主部署和次级部署。	使用权限 API 进行复制。

选择区域和多个辅助工作区

选择区域和多个次要工作区

您可以控制何时触发灾难恢复（DR），以及故障转移到哪个次要区域。你还负责在恢复正常操作之前稳定 DR 环境。这通常意味着为生产和 DR 创建多个Azure Databricks工作区，然后选择次要故障转移区域。

在选择次要区域之前，请确认你依赖的所有资源和服务（计算类型、产品、集成）都可用。某些Azure Databricks服务仅在特定区域中可用。

另请检查数据复制和 VM 类型可用性。

步骤 3：准备多个工作区并进行一次性复制

首先，在您选择的次要区域中部署一个或多个次要 Azure Databricks 工作区及其配套元存储。辅助工作区必须镜像主帐户、区域和标识配置，然后才能将数据或资产复制到其中。

如果您使用了托管式灾难恢复，则 Azure Databricks 会在创建故障转移组时，负责完成纳入范围的目录和工作区资产的初始引导。无需为这些资源运行一次性副本。对于托管式 DR 不复制的任何数据源或资产，请继续参阅本节的其余内容。

对于在托管式灾难恢复（DR）范围之外运行的生产工作区，请执行一次性复制，使被动部署与主动部署保持同步。此复制操作处理：

数据复制：使用云复制解决方案或 Delta Deep Clone。
令牌生成：使用生成的令牌自动执行复制和将来的工作负荷。
工作区复制：使用步骤 4：准备数据源的方法进行复制。
工作区验证：测试工作区和进程，确认它们成功执行并生成预期结果。

后续同步的运行速度比初始副本快，并且工具记录了更改的内容和时间。

步骤 4：准备数据源

Azure Databricks 可以使用批处理或数据流来处理大量各种数据源。

从数据源进行批处理

批处理数据通常驻留在可以复制或传送到另一个区域的源中。

例如，数据通常按计划上传到云存储。在 DR 模式下，将这些上传操作指向辅助区域存储，并更新工作负载，使其从该存储读取并写入该存储。

数据流

处理数据流是一项更大的挑战。流数据可以从各种来源获取、处理并传输到流媒体解决方案：

消息队列，如 Kafka
数据库变更数据捕获流
基于文件的连续处理
基于文件的计划处理，也称为一次性触发

在所有这些情况下，都必须配置数据源，使其支持 DR 模式，并使用次要区域中的辅助部署。

流编写器可存储检查点，以及有关已处理数据的信息。此检查点可以包含一个数据位置（通常是云存储），必须将其修改为新位置，以确保成功重启流。例如，检查点下的 source 子文件夹可能会存储基于文件的云文件夹。

必须及时复制此检查点。考虑将检查点间隔与任何新的云复制解决方案同步。

检查点更新是编写器的一项功能，因此适用于数据流引入或在另一个流式传输源上处理和存储数据流。

对于流式处理工作负载，请确保在客户管理的存储中配置了检查点，以便将其复制到次要区域，使工作负载能够从上次的故障点恢复。您还可以选择让次要流媒体处理过程与主要处理过程并行运行。

步骤 5：实现和测试解决方案

如果使用托管灾难恢复，可以从帐户控制台触发计划的故障转移，以验证设置是否以端到端方式工作。同一流程适用于 DR 测试和实际中断。

定期测试 DR 设置。未经测试的 DR 计划在真正需要时往往无法奏效。某些团队每隔几个月按计划切换活动区域，以验证假设、练习过程，并使团队熟悉 Runbook。

重要

定期在实际条件下测试 DR 解决方案。

如果测试显示缺少的对象或模板，请更新计划：删除依赖项，将其复制到辅助工作区，或使其以其他方式可用。

也要测试组织结构和配置方面的更改。 DR 计划会影响部署管道，因此团队必须知道要同步哪些内容。设置 DR 工作区后，确认基础结构、作业、笔记本、库和其他工作区对象在次要区域中可用。

展开标准工作流程和配置管道，将更改部署到所有工作区。跨工作区管理用户标识，并为新工作区配置作业自动化和监视。

规划和测试配置工具的更改。

计划和测试的配置更改

对于以下每一项，请准备故障转移计划并测试所有假设：

引入：了解数据源的位置以及这些源获取其数据的位置。如果可能，请参数化源，并为辅助部署和区域使用单独的配置模板。
执行更改：如果你有一个计划程序来触发作业或其他操作，则可能需要一个单独的计划程序来处理辅助部署或其数据源。
交互式连接：考虑配置、身份验证和网络连接如何受到区域中断的影响，以使用 REST API、CLI 工具或其他服务（如 JDBC/ODBC）。
自动化变更：适用于所有自动化工具。
输出：对于生成输出数据或日志的任何工具。
下游更改：对于从 Azure Databricks 读取数据或向其写入数据的 BI 工具、仪表板、调度程序和第三方集成，请规划如何将其重新指向辅助工作区，并通知其所有者。

测试故障转移

许多场景都可能触发 DR：例如，云网络、云存储或其他核心服务发生意外中断，导致你无法正常关停；计划内停机或中断；或者甚至作为测试周期的一部分，定期在不同区域之间切换。

若要测试故障转移，请连接到该系统并执行关机操作。确认所有作业均已完成，且群集已终止。

同步客户端（或 CI/CD 工具）将相关的Azure Databricks对象和资源复制到辅助工作区。若要激活辅助工作区，你的进程可能包括以下部分或全部内容：

运行测试，确认平台是否为最新版本。
禁用主要区域中的池和群集，以便在失败的服务恢复联机状态时，主要区域不会开始处理新数据。
运行数据源的恢复过程（请参阅下文）。
启动相关的池（或将 min_idle_instances 增加到相关数目）。
启动相关群集（如果未终止）。
更改作业的并发运行并运行相关作业。可以一次性运行这些作业，也可以定期运行这些作业。
对于任何将 URL 或域名用于 Azure Databricks 工作区的外部工具，请更新配置以说明新的控制平面。例如，更新 REST API 和 JDBC/ODBC 连接的 URL。当控制平面更改时，Azure Databricks Web 应用程序的面向客户的 URL 也会更改，请向组织的用户告知新 URL。

恢复过程详细信息

检查最新同步数据的日期。请参阅灾难恢复行业术语。此步骤的详细信息因同步数据的方式和独特的业务需求而异。
使数据源稳定，并确保它们均可用。包括所有外部数据源，例如 Azure Cloud SQL 和 Delta Lake、Parquet 或其他文件。
查找流媒体恢复点。设置进程以从该处重启，并让进程准备好识别并消除潜在的重复项（Delta Lake 可简化此作）。
完成数据流过程并通知用户。

测试还原（故障回复）

测试恢复（回退）

故障恢复更容易控制，并且可以在维护时段内完成。规划以下步骤中的部分或全部步骤：

确认主要区域已还原。
禁用次要区域中的池和集群，以免其开始处理新数据。
将次要工作区中的所有新资产或已修改资产同步回主要部署。根据故障转移脚本的设计，可以运行相同的脚本，将对象从次要（DR）区域同步到主要（生产）区域。
将所有新数据更新同步回主要部署。可以使用日志和 Delta 表的审核线索来确保不会丢失数据。
停止 DR 区域中的所有工作负载。
将作业和用户 URL 更改为主要区域，并将下游连接（BI 工具、计划程序、第三方集成）重新指向它。
运行测试，确认平台是否为最新版本。
启动相关的池（或将 min_idle_instances 增加到相关数目）。
启动相关群集（如果未终止）。
更改作业的并发运行设置，并执行相关作业。可以一次性运行这些作业，也可以定期运行这些作业。
根据需要，重新设置次要区域，以用于后续灾难恢复。

自动化脚本、示例和原型

对于 AWS 和Azure，托管灾难恢复无需自定义自动化即可处理工作区和托管表复制。以下参考资料仅适用于在托管式 DR 适用范围之外构建 DIY 解决方案的情况。

对于 DIY DR 管道，请使用 Databricks Terraform 提供程序将工作区资产作为代码管理，并共同部署到主要区域和次要区域。

如果您通过 Azure 数据工厂对 Azure Databricks 进行编排，请复制相关的 ADF 管道，以便它们引用映射到次要工作区的链接服务。

其他资源

Last updated on 2026-07-14