灾难恢复
清晰的灾难恢复模式对于Databricks等云原生数据分析平台至关重要。bob体育客户端下载对于一些公司来说，即使是由于飓风、地震等区域性灾难或其他原因造成的区域性服务范围内的云服务提供商中断，您的数据团队也能够使用Databricks平台，这一点bob体育客户端下载至关重要。
Databricks通常是整个数据生态系统的核心部分，其中包括许多服务，包括上游数据摄取服务(批处理/流处理)、云本地存储(如Amazon S3)、下游工具和服务(如商业智能应用程序)以及编排工具。有些用例可能对区域性服务范围的停机特别敏感。
本文描述了Databricks Unified Analytics平台的成功灾难恢复解决方案的概念和最佳实践。bob体育亚洲版bob体育客户端下载每个组织都是不同的，因此如果您在部署自己的解决方案时有任何问题，请与Databricks代表联系。
重要的
这篇文章提到了这个术语数据平面，是Databricks平台的计算层。bob体育客户端下载在本文上下文中，数据平面指的是AWS帐户中的经典数据平面。相比之下，支持无服务器数据平面的无服务器SQL仓库(公开预览)在Databricks AWS帐户中运行。要了解BOB低频彩更多信息，请参见Serverless计算．
容灾概述
灾难恢复涉及一套政策、工具和程序，能够在自然或人为灾害发生后恢复或继续重要的技术基础设施和系统。像AWS这样的大型云服务为许多客户提供服务，并且内置了防止单一故障的保护措施。例如，一个区域是连接到不同电源的一组建筑物，以确保一次电力损失不会使该区域关闭。但是，云区域可能发生故障，中断的程度及其对组织的影响可能不同。
在实施灾难恢复计划之前，了解两者之间的区别非常重要灾难恢复(博士),高可用性(公顷)。
高可用性是系统的弹性特征。高可用性确保最低水平的操作性能，通常是根据一致的正常运行时间或正常运行时间的百分比来定义的。通过将高可用性设计为主系统的一个特性，在适当的位置(与主系统在同一区域)实现高可用性。例如，像AWS这样的云服务有高可用性服务，比如Amazon S3。高可用性不需要Databricks客户进行重要的显式准备。
相反，灾难恢复Plan要求适用于您的特定组织的决策和解决方案，以处理关键系统的较大区域停机。本文讨论常用的灾难恢复术语、常用的解决方案，以及Databricks用于灾难恢复计划的一些最佳实践。
术语
地区的术语
本文对区域使用以下定义:
主要地区:用户运行典型的日常交互和自动化数据分析工作负载的地理区域。
二级区域: IT团队在主要区域停机期间临时移动数据分析工作负载的地理区域。
Geo-redundant存储: AWS有跨区域的地理冗余存储对于使用异步存储复制进程的持久化桶。
重要的
对于灾难恢复进程，Databricks建议您这样做不依赖于地理冗余存储来实现跨区域的数据复制，例如根S3桶。一般来说，对于Delta表使用Deep Clone，如果可能的话，将数据转换为Delta格式，以便对其他数据格式使用Deep Clone。
部署状态术语
本文使用部署状态的以下定义:
积极部署:用户可以连接到Databricks工作空间的活动部署并运行工作负载。使用Databricks调度器或其他机制定期调度作业。数据流也可以在此部署上执行。某些文档可能将活动部署称为热部署．
被动的部署:进程不运行在被动部署上。IT团队可以设置自动化的过程，将代码、配置和其他Databricks对象部署到被动部署。部署变为活动状态只有如果当前活动部署已关闭。有些文档可能将被动部署称为寒冷的部署．
重要的
一个项目可以在不同区域包含多个被动部署，以提供解决区域中断的额外选项。
一般来说，一个团队在同一时间只有一个活动部署，即所谓的部署主被动灾难恢复策略。有一种不太常见的灾难恢复解决方案策略称为active - active，其中有两个同时的活动部署。
灾难恢复行业术语
有两个重要的行业术语，你必须为你的团队理解和定义:
恢复点目标:一个恢复点目标是由于重大事件而可能从IT服务中丢失数据(事务)的最大目标期限。Databricks部署不存储主要客户数据。这些数据存储在单独的系统中，如Amazon S3或您控制下的其他数据源。Databricks控制平面可以部分或全部存储对象，如job、notebook等。对于Databricks, RPO定义为可以丢失作业和笔记本更改等对象的最大目标周期。此外，您还负责为Amazon S3或您控制下的其他数据源中的您自己的客户数据定义RPO。
恢复时间目标:恢复时间目标(RTO)是灾难发生后业务流程必须恢复的目标持续时间和服务级别。
灾难恢复和数据损坏
灾难恢复解决方案可以不减少数据损坏。主区域中的损坏数据将从主区域复制到辅助区域，并且在两个区域中都被损坏。例如，还有其他方法可以减轻这种失败时间旅行．
典型的恢复工作流程
Databricks灾难恢复场景通常采用以下方式:
您在主要区域中使用的关键服务发生故障。这可以是影响Databricks部署的数据源服务或网络。
您与云提供商一起调查情况。
如果您认为您的公司不能等待主要区域中的问题得到解决，那么您可能决定需要将故障转移到次要区域。
验证相同的问题不会影响次要区域。
故障转移到辅助区域。
停止工作区中的所有活动。用户停止工作。如果可能的话，指示用户或管理员备份最近的更改。如果作业还没有因为停机而失败，那么它们将被关闭。
启动从区域的恢复过程。恢复过程将连接和网络流量的路由和重命名更新到次要区域。
测试之后，宣布二级区域可运行。生产工作负载现在可以恢复。用户可以登录到当前激活的部署。您可以重新触发已计划或延迟的作业。
有关Databricks上下文中的详细步骤，请参见测试故障转移．
在某一时刻，主区域的问题得到了缓解，您确认了这一事实。
恢复(故障恢复)到主区域。
停止辅助区域上的所有工作。
在主区域启动恢复过程。恢复过程处理将连接和网络流量路由和重命名回主区域。
根据需要将数据复制回主区域。为了降低复杂性，可能需要最小化需要复制的数据量。例如，如果某些作业在辅助部署中运行时是只读的，则可能不需要将该数据复制回主区域中的主要部署。但是，您可能有一个需要运行的生产作业，并且可能需要将数据复制回主区域。
在主区域中测试部署。
宣布您的主要区域处于运行状态，并且它是您的活动部署。恢复生产工作负载。
有关恢复到主区域的详细信息，请参见测试恢复(failback)．
重要的
在这些步骤中，可能会发生一些数据丢失。您的组织必须定义可接受的数据丢失量，以及可以采取哪些措施来减轻这种损失。
第一步:了解你的业务需求
你的第一步是定义和理解你的业务需求。定义哪些数据服务是关键的，以及它们的预期是什么RPO和RTO．
研究每个系统的实际容忍度，并记住，灾难恢复故障转移和故障恢复可能代价高昂并带来其他风险。其他风险可能包括数据损坏、写入错误的存储位置导致的数据复制，以及用户登录并在错误的位置进行更改。
映射所有影响您业务的Databricks集成点:
您的灾难恢复解决方案需要适应交互式流程、自动化流程，还是两者都需要?
您使用哪些数据服务?有些可能是预置的。
输入数据如何进入云?
谁使用这些数据?哪些流程在下游消耗它?
是否存在需要了解灾难恢复更改的第三方集成?
确定可以支持灾难恢复计划的工具或通信策略:
您将使用什么工具来快速修改网络配置?
您能否预定义您的配置并使其模块化，以自然和可维护的方式适应灾难恢复解决方案?
哪些通信工具和渠道将灾难恢复故障转移和故障恢复更改通知内部团队和第三方(集成、下游消费者)?你将如何确认他们的确认?
需要什么工具或特殊支持?
在完全恢复到位之前，将关闭哪些服务(如果有的话)?
步骤2:选择一个满足您业务需求的流程
您的解决方案必须在控制平面、数据平面和数据源中复制正确的数据。容灾冗余工作区必须映射到不同区域的不同控制平面。您也必须使用基于脚本的解决方案定期保持数据同步一个同步工具或CI/CD工作流．不需要从数据平面网络本身同步数据，比如从Databricks Runtime worker同步数据。
如果您使用客户管理的VPC特性(并非所有订阅和部署类型都可用)，您可以使用基于模板的工具在两个区域一致地部署这些网络，例如起程拓殖．
此外，您需要确保在需要时跨区域复制数据源。
一般最佳实践
成功的灾难恢复计划的一般最佳实践包括:
了解哪些流程对业务至关重要，并且必须在灾难恢复中运行。
清楚地确定涉及哪些服务、正在处理哪些数据、数据流是什么以及数据流存储在哪里
尽可能地隔离服务和数据。例如，为用于灾难恢复的数据创建一个特殊的云存储容器，或者将灾难期间需要的Databricks对象移动到单独的工作空间。
为没有存储在Databricks控制平面中的其他对象维护主部署和辅助部署之间的完整性是您的责任。
警告
这是一种最佳实践不在根Amazon S3桶中存储用于工作区的根DBFS访问的任何数据元素。生产客户数据不支持根DBFS存储。但是，您可以存储其他对象，例如库、配置文件、初始化脚本和类似的数据。要么开发一个自动化的流程来复制这些对象，要么记住准备好流程来更新辅助部署以进行手动部署。
对于数据源，在可能的情况下，建议使用本地AWS工具进行复制和冗余，将数据复制到灾难恢复区域。
选择恢复解决方案策略
典型的灾难恢复解决方案涉及两个(或更多)工作空间。你可以选择几种策略。考虑中断的潜在长度(几小时甚至一天)，确保工作空间完全可操作的工作，以及恢复(故障恢复)到主要区域的工作。
主备解决方案策略
主动-被动解决方案是最常见和最简单的解决方案，这类解决方案是本文的重点。主-被动解决方案将数据和对象更改从主动部署同步到被动部署。如果您愿意，可以在不同的区域进行多个被动部署，但本文主要关注单一的被动部署方法。在灾难恢复事件期间，次要区域中的被动部署将成为您的主动部署。
这种策略主要有两种变体:
统一(企业级)解决方案:支持整个组织的完全一组主动和被动部署。
按部门或项目解决方案:每个部门或项目域维护一个独立的容灾解决方案。一些组织希望在部门之间分离灾难恢复细节，并根据每个团队的独特需求为每个团队使用不同的主要和次要区域。
还有其他变体，例如对只读用例使用被动部署。如果您的工作负载是只读的，例如用户查询，如果它们不修改数据或Databricks对象(如笔记本或作业)，则可以随时在被动解决方案上运行。
双活解决方案策略
在active-active解决方案中，您可以始终并行地在两个区域中运行所有数据进程。您的操作团队必须确保数据流程(例如作业)仅被标记为完成当它成功地完成两个区域．对象不能在生产中更改，必须遵循从开发/登台到生产的严格CI/CD升级。
active-active解决方案是最复杂的策略，由于作业在两个区域运行，因此会产生额外的财务成本。
与主动-被动策略一样，您可以将其作为统一的组织解决方案或按部门实现。
根据您的工作流，您可能不需要在辅助系统中为所有工作空间使用相同的工作空间。例如，开发或登台工作空间可能不需要副本。有了一个设计良好的开发管道，如果需要的话，您可以很容易地重构这些工作空间。
选择您的工具
有两种主要的方法可以让工具在你的主区域和辅助区域的工作区之间保持尽可能相似的数据:
从主服务器拷贝到从服务器的同步客户端:同步客户端将生产数据和资产从主区域推送到从区域。通常这是在预定的基础上运行的。
用于并行部署的CI/CD工具:对于产品代码和资产，使用CI / CD的工具这促使两个地区同时对生产系统进行更改。例如，当将代码和资产从登台/开发推到生产时，CI/CD系统使其同时在两个区域可用。其核心思想是将Databricks工作区中的所有工件视为基础设施即代码。大多数工件可以同时部署到主工作区和辅助工作区，而有些工件可能只需要在灾难恢复事件发生后部署。有关工具，请参见自动化脚本、示例和原型．
下面的图表对比了这两种方法。
根据您的需要，您可以结合使用这些方法。例如，对笔记本源代码使用CI/CD，但对池和访问控制等配置使用同步。
下表描述了如何使用每个工具选项处理不同类型的数据。
描述 |
如何处理CI/CD工具 |
如何处理与同步工具 |
|---|---|---|
源代码:笔记本源代码导出和打包库的源代码 |
同时部署到主要和次要设备。 |
将源代码从主服务器同步到备用服务器。 |
用户和组 |
在Git中以配置方式管理元数据。或者，对两个工作空间使用相同的标识提供程序(IdP)。将用户和组数据共同部署到主部署和辅助部署。 |
使用SCIM或者这两个区域的其他自动化。手动创建是不建议使用，但如果使用必须同时进行。如果您使用手动设置，请创建一个预定的自动化流程来比较两个部署之间的用户和组列表。 |
池配置 |
可以是Git中的模板。同时部署到主要和次要设备。然而, |
使用任何创建的池 |
工作配置 |
可以是Git中的模板。对于主部署，按原样部署作业定义。对于辅助部署，部署作业并将并发数设置为0。这将禁用此部署中的作业，并防止额外运行。在辅助部署激活后更改并发值。 |
如果作业运行在现有的 |
访问控制列表(acl) |
可以是Git中的模板。共同部署到笔记本电脑、文件夹和集群的主要和次要部署。但是，在灾难恢复事件发生之前，请保留作业的数据。 |
的权限API 2.0可以为集群、作业、池、笔记本和文件夹设置访问控制。同步客户端需要映射到辅助工作空间中每个对象的对应对象id。Databricks建议在同步这些对象时创建从主工作区到辅助工作区的对象id映射之前复制访问控制。 |
库 |
包括在源代码和集群/作业模板中。 |
从集中式存储库、DBFS或云存储(可以挂载)同步自定义库。 |
包括在源代码中，如果你喜欢。 |
为了更简单的同步，请将init脚本存储在主工作空间中的一个普通文件夹中，如果可能的话，可以将init脚本存储在一个小的文件夹集中。 |
|
挂载点 |
如果仅通过基于笔记本的作业创建，则包含在源代码中命令API． |
使用工作。注意，存储端点可能会发生变化，因为工作空间位于不同的区域。这在很大程度上也取决于您的数据灾难恢复策略。 |
表元数据 |
如果仅通过基于笔记本的作业或命令API．这适用于内部Databricks metastore或外部配置的metastore。 |
比较亚metastores之间的元数据定义Spark Catalog API或通过笔记本或脚本显示创建表。注意，底层存储的表可以是基于区域的，并且在metastore实例之间会有所不同。 |
秘密 |
包括在源代码中，如果只创建通过命令API．请注意，某些机密内容可能需要在主服务器和辅助服务器之间更改。 |
秘密是通过API在两个工作区中创建的。请注意，某些机密内容可能需要在主服务器和辅助服务器之间更改。 |
集群配置 |
可以是Git中的模板。同时部署到主部署和辅助部署，但是应该终止辅助部署中的部署，直到发生灾难恢复事件。 |
集群是在使用API或CLI将它们同步到辅助工作空间之后创建的。根据自动终止设置，可以显式地终止这些操作。 |
笔记本、作业和文件夹权限 |
可以是Git中的模板。共同部署到主要和次要部署。 |
使用权限API 2.0． |
选择区域和多个辅助工作区
您需要完全控制灾难恢复触发器。您可以决定在任何时间或出于任何原因触发此操作。在重新启动操作failback(正常生产)模式之前，您必须负责灾难恢复稳定。通常，这意味着您需要创建多个Databricks工作区来满足您的生产和灾难恢复需求，并选择辅助故障转移区域。
在AWS中，您可以完全控制所选的辅助区域。确保您的所有资源和产品都可用，例如EC2。部分Databricks服务可用只在部分地区．如果您的Databricks帐户位于平台的E2版本上，则必须为平台的E2版本在受支持的AWS区域中进行选择。bob体育客户端下载
步骤3:准备好工作空间，一次性复制
如果工作空间已经在生产环境中，则通常运行一次性复制操作将被动部署与主动部署同步。这一次拷贝处理以下:
数据复制:使用云复制解决方案或Delta深度克隆操作进行复制。
令牌生成:使用令牌生成来自动化复制和未来的工作负载。
工作区复制:使用中描述的方法使用工作区复制步骤4:准备数据源．
工作区验证-测试以确保工作空间和流程能够成功执行，并提供预期的结果。
在您最初的一次性复制操作之后，后续的复制和同步操作会更快，并且您的工具中的任何日志记录也是更改内容和更改时间的日志。
步骤4:准备数据源
数据库可以使用批处理或数据流处理大量的数据源。
从数据源进行批处理
在批量处理数据时，数据通常位于可以轻松复制或交付到另一个区域的数据源中。
例如，数据可能会定期上传到云存储位置。在二级区域的灾难恢复模式下，必须确保将文件上传到二级区域存储。工作负载必须读取二级区域存储，并写入二级区域存储。
数据流
处理数据流是一个更大的挑战。流数据可以从各种来源摄取，并被处理和发送到流解决方案:
消息队列如Kafka
数据库变更数据捕获流
基于文件的连续处理
基于文件的计划处理，也称为触发一次
在所有这些情况下，您必须配置数据源以处理灾难恢复模式，并在次要区域中使用次要部署。
流写入器存储一个带有已处理数据信息的检查点。这个检查点可以包含一个数据位置(通常是云存储)，必须将其修改为一个新位置，以确保流成功重新启动。例如，源检查点下的子文件夹可能存储基于文件的云文件夹。
必须及时复制该检查点。考虑与任何新的云复制解决方案同步检查点间隔。
检查点更新是写入器的一个功能，因此适用于数据流摄取或处理并存储在另一个流源上。
对于流工作负载，请确保在客户管理的存储中配置了检查点，以便可以将它们复制到次要区域，以便从最后一个故障点恢复工作负载。您还可以选择在主进程的同时运行辅助流进程。
步骤5:实现并测试您的解决方案
定期测试灾难恢复设置，以确保其正常工作。如果在需要时不能使用灾难恢复解决方案，那么维护它就没有任何价值。一些公司每隔几个月就会在不同地区之间切换。定期切换区域可以测试您的假设和流程，并确保它们满足您的恢复需求。这还可以确保您的组织熟悉紧急情况的政策和程序。
重要的
在实际环境中定期测试您的灾难恢复解决方案。
如果您发现丢失了一个对象或模板，并且仍然需要依赖存储在主要工作空间中的信息，请修改计划以消除这些障碍，在辅助系统中复制此信息，或者以其他方式使其可用。
测试您的流程和配置的任何所需的组织更改。您的灾难恢复计划会影响您的部署管道，您的团队知道需要保持同步的内容是很重要的。设置灾难恢复工作空间后，必须确保二级区域中的基础设施(手册或代码)、作业、笔记本电脑、库和其他工作空间对象可用。
与您的团队讨论如何扩展标准工作流程和配置管道，以便将更改部署到所有工作区。管理所有工作区中的用户身份。记得为新工作区配置作业自动化和监视等工具。
计划并测试配置工具的更改:
摄取:了解您的数据源在哪里，以及这些数据源从哪里获得数据。在可能的情况下，将源参数化，并确保您有一个单独的配置模板用于辅助部署和辅助区域。准备一个故障转移计划并测试所有假设。
执行更改:如果您有一个调度器来触发作业或其他操作，那么您可能需要配置一个单独的调度器，用于辅助部署或其数据源。准备一个故障转移计划并测试所有假设。
交互连接性:考虑在使用REST api、CLI工具或其他服务(如JDBC/ODBC)时，配置、身份验证和网络连接可能会受到区域性中断的影响。准备一个故障转移计划并测试所有假设。
自动化更改:对于所有自动化工具，准备一个故障转移计划并测试所有假设。
输出:对于生成输出数据或日志的任何工具，准备一个故障转移计划并测试所有假设。
测试故障转移
灾难恢复可以由许多不同的场景触发。它可以由意外的中断触发。一些核心功能可能会关闭，包括云网络、云存储或其他核心服务。您没有权限安全地关闭系统，必须尝试恢复。但是，该过程可能由关机或计划中断触发，甚至由在两个区域之间定期切换活动部署触发。
在测试故障转移时，连接到系统并运行关机过程。确保所有作业都已完成，集群已终止。
同步客户端(或CI/CD工具)可以将相关的Databricks对象和资源复制到辅助工作空间。要激活次要工作区，您的流程可能包括以下部分或全部:
运行测试以确认平台是最新的。bob体育客户端下载
禁用主区域上的池和集群，以便在失败的服务恢复在线时，主区域不会开始处理新数据。
恢复过程:
查看最近一次同步数据的日期。看到灾难恢复行业术语．此步骤的细节根据同步数据的方式和独特的业务需求而有所不同。
稳定数据源并确保它们都可用。包括所有外部数据源，例如AWS RDS，以及您的Delta Lake、Parquet或其他文件。
找到你的流恢复点。设置流程从那里重新启动，并准备好一个流程来识别和消除潜在的重复项(Delta Lake Lake使这更容易)。
完成数据流流程并通知用户。
启动相关池(或增加
min_idle_instances相关号码)。启动相关集群(如果没有终止)。
更改作业的并发运行并运行相关作业。这些可以是一次性运行，也可以是周期性运行。
对于为Databricks工作空间使用URL或域名的任何外部工具，请更新配置以适应新的控制平面。例如，更新REST api和JDBC/ODBC连接的url。当控制平面更改时，Databricks web应用程序面向客户的URL也会更改，因此请将新URL通知组织的用户。
测试恢复(failback)
Failback更容易控制，可以在维护窗口中完成。该计划可以包括以下部分或全部内容:
确认主区域已恢复。
禁用辅助区域上的池和集群，以便它不会开始处理新数据。
将辅助工作空间中的任何新的或修改过的资产同步回主部署。根据故障转移脚本的设计，您可能能够运行相同的脚本来将对象从辅助(灾难恢复)区域同步到主(生产)区域。
将任何新的数据更新同步回主部署。您可以使用日志和Delta表的审计跟踪来确保不会丢失数据。
关闭灾备区域中的所有工作负载。
将作业和用户URL更改为主区域。
运行测试以确认平台是最新的。bob体育客户端下载
启动相关池(或增加
min_idle_instances到相关的号码)。启动相关集群(如果没有终止)。
更改作业的并发运行，并运行相关作业。这些可以是一次性运行，也可以是周期性运行。
根据需要，再次设置二级区域，以便将来进行灾难恢复。
自动化脚本、示例和原型
为灾难恢复项目考虑的自动化脚本:
Databricks建议您使用Databricks Terraform Provider来帮助开发您自己的同步流程。
另请参阅Databricks工作空间迁移工具用于示例自动化和原型脚本。
的Databricks Sync (DBSync)project是一个对象同步工具，用于备份、恢复和同步Databricks工作区。