災難恢複
清晰的災難恢複模式對於像Databricks這樣的雲本地數據分析平台至關重要。Beplay体育安卓版本對於一些公司來說，即使是在罕見的區域性全服務雲服務提供商中斷的情況下，您的數據團隊能夠使用Databricks平台是至關重要的，無論這種中斷是由區域性災難(Beplay体育安卓版本如颶風、地震或其他來源)引起的。
Databricks通常是整個數據生態係統的核心部分，該生態係統包括許多服務，包括上遊數據吸收服務(批處理/流媒體)、雲本地存儲(如Amazon S3)、下遊工具和服務(如商業智能應用程序)和編配工具。您的一些用例可能對區域性服務範圍的中斷特別敏感。
本文描述了Databricks Unified Analytics平台成功的災難恢複解決方案的概念和最佳實踐。Beplay体育安卓版本每個組織都是不同的，所以如果您在部署自己的解決方案時有問題，請聯係您的Databricks代表。
重要的
這篇文章提到了這個術語數據平麵，是Databricks平台的計算層。Beplay体育安卓版本在本文中，數據平麵指的是AWS帳戶中的Classic數據平麵。相比之下，支持的Serverless數據平麵無服務器SQL倉庫(公開預覽版)運行在Databricks AWS帳戶。要了解更多，請參見Serverless計算．
災難恢複的概述
災難恢複涉及一組政策、工具和程序，這些政策、工具和程序使關鍵技術基礎設施和係統在自然或人為災難之後能夠恢複或繼續。像AWS這樣的大型雲服務為許多客戶提供服務，並且內置了防止單一故障的保護措施。beplay体育app下载地址例如，一個區域是連接到不同電源的一組建築物，以確保單個電力損失不會關閉一個區域。但是，雲區域故障可能會發生，並且破壞的程度及其對組織的影響可能不同。
在實施災難恢複計劃之前，了解兩者之間的區別很重要災難恢複(博士),高可用性(公頃)。
高可用性是係統的彈性特性。高可用性確保最低水平的操作性能，通常根據一致的正常運行時間或正常運行時間百分比來定義。通過將高可用性設計為主係統的一個特性，就可以實現高可用性(在與主係統相同的區域)。例如，AWS這樣的雲服務具有Amazon S3這樣的高可用性服務。高可用性不需要Databricks客戶顯式的準備。
相比之下,一個災難恢複計劃要求您的特定組織能夠處理關鍵係統的較大區域中斷的決策和解決方案。本文討論了使用Databricks進行災難恢複的常見術語、常見解決方案和一些最佳實踐。
術語
地區的術語
本文對區域使用了以下定義:
主要地區:用戶運行典型的日常交互式和自動化數據分析工作負載的地理區域。
二級區域: IT團隊在主要區域停電期間臨時移動數據分析工作負載的地理區域。
Geo-redundant存儲: AWS跨區域的兩地三中心冗餘存儲對於使用異步存儲複製過程的持久化桶。
重要的
對於災難恢複過程，Databricks建議您這樣做不依賴於兩地三中心冗餘存儲來跨區域複製數據，例如您的根S3桶。一般情況下，Delta表使用Deep Clone，如果其他數據格式可以使用Deep Clone，則將數據轉換為Delta格式。
部署狀態的術語
本文使用以下對部署狀態的定義:
積極部署:用戶可以連接到Databricks工作區的活動部署，並運行工作負載。作業使用Databricks調度器或其他機製定期調度。數據流也可以在這個部署中執行。一些文檔可能將活動部署稱為熱部署．
被動的部署:進程不會在被動部署中運行。IT團隊可以設置自動化過程，將代碼、配置和其他Databricks對象部署到被動部署中。部署變為活動的隻有如果當前的活動部署關閉。一些文檔可能將被動部署稱為寒冷的部署．
重要的
一個項目可以在不同的區域選擇多個被動部署，為解決區域中斷提供額外的選項。
一般來說，一個團隊一次隻有一個活動部署，即所謂的主被動災難恢複策略。有一種不太常見的災難恢複解決方案策略稱為active - active，其中有兩個同時進行的部署。
災難恢複行業術語
有兩個重要的行業術語您必須理解並為您的團隊定義:
恢複點目標:一個恢複點目標(RPO)是IT服務由於重大事件可能丟失數據(事務)的最長目標時間。您的Databricks部署不存儲您的主要客戶數據。它存儲在獨立的係統中，如Amazon S3或您控製下的其他數據源。Databricks控製平麵部分或全部存儲一些對象，如作業和筆記本電腦。對於Databricks, RPO被定義為作業和筆記本更改等對象可能丟失的最大目標周期。此外，您還負責為您自己的客戶數據在Amazon S3或您控製的其他數據源中定義RPO。
恢複時間目標:恢複時間目標(RTO)是災後業務流程必須在其中恢複的目標持續時間和服務級別。
災難恢複和數據損壞
災難恢複解決方案可以不減少數據丟失。主區域中已損壞的數據從主區域複製到輔助區域，並且在兩個區域中均已損壞。例如，還有其他方法可以減輕這種失敗三角洲時間旅行．
典型的複蘇工作流
典型的Databricks災難恢複場景是這樣的:
在主區域中使用的關鍵服務發生故障。這可以是影響Databricks部署的數據源服務或網絡。
您可以向雲提供商調查情況。
如果您認為您的公司不能等待主區域的問題得到修複，那麼您可能決定需要故障轉移到輔助區域。
驗證相同的問題是否也不會影響您的次要區域。
故障轉移到次要區域。
停止工作空間中的所有活動。用戶停止工作負載。提示用戶或管理員盡可能對最近的更改進行備份。如果作業還沒有因為中斷而失敗，則會關閉它們。
在備區域啟動恢複操作。恢複過程更新路由和重命名連接和網絡流量到輔助區域。
測試後，聲明二級區域運行。生產工作負載現在可以恢複了。用戶可以登錄到現在活動的部署。可以重新觸發計劃的或延遲的作業。
有關Databricks上下文的詳細步驟，請參見測試故障轉移．
在某種程度上，主要區域的問題得到了緩解，您確認了這一事實。
將(故障恢複)恢複到主要區域。
停止對次要區域的所有工作。
在主區域啟動恢複操作。恢複過程處理路由和重命名連接和網絡流量回到主區域。
根據需要將數據複製回主區域。為了降低複雜性，也許可以盡量減少需要複製的數據量。例如，如果一些作業在輔助部署中運行時是隻讀的，則可能不需要將這些數據複製回主區域中的主部署。但是，您可能有一個生產作業需要運行，並且可能需要將數據複製回主區域。
測試主區域的部署。
聲明您的主要區域是可操作的，並且它是您的活動部署。恢複生產工作負載。
有關恢複到主要區域的詳細信息，請參見測試恢複(退回)．
重要的
在這些步驟中，可能會發生一些數據丟失。您的組織必須定義多少數據丟失是可以接受的，以及您可以采取什麼措施來減少這種損失。
第一步:了解您的業務需求
您的第一步是定義和理解您的業務需求。定義哪些數據服務是關鍵的，以及它們的期望是什麼RPO, RTO．
研究每個係統的實際容忍度，記住災難恢複故障轉移和故障恢複的成本可能很高，並可能帶來其他風險。其他風險可能包括數據損壞、數據複製(如果寫入錯誤的存儲位置)，以及用戶登錄並在錯誤的位置進行更改。
映射所有影響您業務的Databricks集成點:
您的災難恢複解決方案需要適應交互過程、自動化過程，還是兩者兼有?
您使用哪些數據服務?有些可能是內部的。
輸入數據是如何到達雲的?
誰使用這些數據?哪些工序在下遊消耗它?
第三方集成是否需要知道災難恢複更改?
確定支持災難恢複計劃的工具或通信策略:
您將使用什麼工具來快速修改網絡配置?
是否可以預定義配置並將其模塊化，以自然和可維護的方式適應災難恢複解決方案?
哪些通信工具和渠道將通知內部團隊和第三方(集成、下遊用戶)災難恢複故障轉移和故障恢複更改?你如何確認他們的確認?
需要什麼工具或特殊支持?
在完全恢複到位之前，哪些服務(如有)將被關閉?
步驟2:選擇一個滿足您的業務需求的流程
您的解決方案必須在控製平麵、數據平麵和數據源中複製正確的數據。用於災難恢複的冗餘工作區必須映射到不同區域的不同控製平麵。您也必須使用基於腳本的解決方案定期保持數據的同步同步工具或CI/CD工作流．不需要從數據平麵內部同步數據，比如Databricks Runtime worker。
如果使用客管VPC特性(不支持所有訂閱和部署類型)，則可以通過模板工具(如起程拓殖．
此外，您需要確保根據需要跨區域複製數據源。
一般的最佳實踐
成功的災難恢複計劃的最佳實踐包括:
了解哪些流程對業務至關重要，並且必須在災難恢複中運行。
清楚地確定涉及哪些服務、正在處理哪些數據、數據流是什麼以及數據流存儲在哪裏
盡可能隔離服務和數據。例如，為災難恢複所需的數據創建一個特殊的雲存儲容器，或者將災難期間所需的Databricks對象移動到單獨的工作區。
您有責任維護未存儲在數據ricks控製平麵中的其他對象的主和從部署之間的完整性。
警告
這是一種最佳實踐不將用於工作空間的根DBFS訪問的任何數據元素存儲在Amazon S3根桶中。生產客戶數據不支持這個根DBFS存儲。但是，您可以存儲其他對象，如庫、配置文件、初始化腳本和類似的數據。要麼開發一個自動流程來複製這些對象，要麼記住要有流程來更新次要部署以進行手動部署。
對於數據源，在可能的情況下，建議使用本地AWS工具進行複製和冗餘，將數據複製到災難恢複區域。
選擇一個恢複解決方案策略
典型的災難恢複解決方案涉及兩個(或更多)工作空間。有幾種策略你可以選擇。考慮中斷的潛在長度(幾個小時或者甚至一天)，確保工作空間完全可操作的工作，以及恢複(故障返回)到主要區域的工作。
主被動解決方案策略
主動-被動解決方案是最常見和最簡單的解決方案，這類解決方案是本文的重點。主動-被動解決方案將數據和對象更改從主動部署同步到被動部署。如果您願意，可以在不同的地區進行多個被動部署，但是本文主要關注單一的被動部署方法。在災難恢複事件期間，輔助區域中的被動部署將成為主動部署。
這一策略有兩種主要變體:
統一(企業級)解決方案:一套完全支持整個組織的主動和被動部署。
按部門或項目劃分:每個部門或項目域維護一個獨立的容災解決方案。有些組織希望分離部門之間的災難恢複細節，並根據每個團隊的獨特需求為每個團隊使用不同的主區域和次區域。
還有其他變體，例如為隻讀用例使用被動部署。如果您的工作負載是隻讀的，例如用戶查詢，如果它們不修改數據或Databricks對象(如筆記本或作業)，則可以隨時在被動解決方案上運行。
active - active解決方案策略
在active-active解決方案中，您可以始終並行地運行兩個區域中的所有數據處理。操作團隊必須確保作業等數據處理隻被標記為完成當它在兩個區域成功完成時．對象不能在生產中更改，必須遵循嚴格的CI/CD從開發/階段到生產的提升。
主動-主動解決方案是最複雜的策略，由於兩個地區都有作業，因此會產生額外的財務成本。
與主動-被動策略一樣，您可以將其作為統一的組織解決方案或按部門實現。
根據您的工作流程，您可能不需要在輔助係統中為所有工作空間提供等效的工作空間。例如，開發或臨時工作空間可能不需要副本。有了設計良好的開發管道，如果需要，您可能能夠輕鬆地重構那些工作空間。
選擇你的工具
工具有兩種主要的方法來保持主區域和副區域的工作區之間的數據盡可能相似:
從主服務器複製到從服務器的同步客戶端:同步客戶端將生產數據和資產從主區域推送到副區域。這通常是有計劃地運行的。
用於並行部署的CI/CD工具:對於生產代碼和資產，使用CI / CD的工具這將在兩個地區同時對生產係統進行更改。例如，當將代碼和資產從階段/開發推到生產時，CI/CD係統使其同時在兩個區域可用。其核心思想是將Databricks工作區中的所有工件視為基礎設施-代碼。大多數工件可以同時部署到主工作區和輔助工作區，而有些工件可能隻需要在災難恢複事件發生後部署。工具,請參閱自動化腳本、示例和原型．
下圖對比了這兩種方法。
根據您的需要，您可以結合使用這兩種方法。例如，對筆記本源代碼使用CI/CD，但對池和訪問控製等配置使用同步。
下表描述了如何使用每個工具選項處理不同類型的數據。
描述 |
如何處理CI/CD模具 |
如何處理同步工具 |
|---|---|---|
源代碼:筆記本源代碼導出和打包庫的源代碼 |
將它們共同部署到主服務器和備用服務器。 |
將主程序的源代碼同步到輔助程序。 |
用戶和組 |
在Git中作為配置管理元數據。或者，對兩個工作區使用相同的身份提供程序(IdP)。將用戶和組數據共同部署到主要和次要部署中。 |
使用SCIM或者兩個地區的其他自動化。手動創建不推薦使用，但如果使用必須同時做兩者。如果使用手動設置，則創建一個計劃的自動化流程來比較兩個部署之間的用戶和組列表。 |
池配置 |
可以是Git中的模板。共同部署到主次服務器。然而, |
使用任意創建的池 |
工作配置 |
可以是Git中的模板。對於主要部署，按原樣部署作業定義。對於二次部署，部署作業並將並發數設置為零。這將禁用此部署中的作業並防止額外運行。備用部署激活後，修改concurrencies的值。 |
如果作業運行在現有的 |
訪問控製列表(acl) |
可以是Git中的模板。共同部署到筆記本、文件夾和集群的主要和次要部署。但是，在災難恢複事件發生之前，保留用於作業的數據。 |
的權限API 2.0可以對集群、作業、池、筆記本和文件夾設置訪問控製。同步客戶端需要映射到輔助工作空間中每個對象對應的對象id。Databricks建議在同步這些對象時創建主工作區到輔助工作區的對象id映射之前正在複製訪問控製。 |
庫 |
包含在源代碼和集群/工作模板中。 |
從集中存儲庫、DBFS或雲存儲(可以掛載)同步定製庫。 |
如果您喜歡，可以包含在源代碼中。 |
為了實現更簡單的同步，可以將初始化腳本存儲在主工作區中的一個公共文件夾中，或者如果可能的話，存儲在一小組文件夾中。 |
|
掛載點 |
包括在源代碼中，如果隻通過基於筆記本的工作或命令API． |
使用工作。注意，如果工作區位於不同的區域，存儲端點可能會發生變化。這在很大程度上也取決於您的數據災難恢複策略。 |
表元數據 |
包括源代碼，如果隻通過基於筆記本的工作或創建命令API．這適用於內部的Databricks metastore或外部配置metastore。 |
比較metastore之間使用的元數據定義火花目錄API或通過筆記本或腳本顯示創建表。注意，底層存儲的表可以是基於區域的，並且在metastore實例之間是不同的。 |
秘密 |
如果僅通過創建，則包含在源代碼中命令API．請注意，可能需要在主服務器和輔助服務器之間更改一些機密內容。 |
秘密是通過API在兩個工作區中創建的。請注意，可能需要在主服務器和輔助服務器之間更改一些機密內容。 |
集群配置 |
可以是Git中的模板。將它們共同部署到主部署和輔助部署中，但是在發生災難恢複事件之前，應該終止輔助部署中的部署。 |
在使用API或CLI將集群同步到輔助工作區之後，將創建集群。根據自動終止設置，可以顯式終止這些設置。 |
筆記本、作業和文件夾權限 |
可以是Git中的模板。共同部署到主要和次要部署。 |
複製使用權限API 2.0． |
選擇區域和多個輔助工作區
您需要完全控製災難恢複觸發器。您可以決定在任何時間或出於任何原因觸發此操作。在重新啟動操作故障恢複(正常生產)模式之前，必須對災難恢複穩定負責。這通常意味著您需要創建多個Databricks工作區來滿足您的生產和災難恢複需求，並選擇次要故障轉移區域。
在AWS中，您可以完全控製所選擇的次要區域。確保您的所有資源和產品都在那裏可用，例如EC2。已提供部分Databricks服務隻是在一些地區．如果您的Databricks帳戶是平台E2版本的，您必須在平台E2版本支持的AWS區域中進行選擇。Beplay体育安卓版本
步驟3:準備工作區，複製一次
如果工作空間已經在生產環境中，那麼通常會運行一次性複製操作，使被動部署與主動部署同步。這個一次性複製處理以下內容:
數據複製:采用雲複製方案或增量深度克隆方式進行複製。
令牌生成:使用令牌生成來自動化複製和未來的工作負載。
工作區複製:使用中描述的方法使用工作區複製步驟4:準備數據源．
工作區驗證: -測試以確保工作空間和流程能夠成功執行並提供預期結果。
在初始的一次性複製操作之後，後續的複製和同步操作會更快，工具上的任何日誌記錄也是更改內容和更改時間的日誌。
步驟4:準備數據源
數據ricks可以使用批處理或數據流處理大量不同的數據源。
來自數據源的批處理
在批量處理數據時，數據通常駐留在可以輕鬆複製或交付到另一個區域的數據源中。
例如，數據可能會定期上傳到雲存儲位置。在輔助區域的災難恢複模式下，必須確保文件被上傳到輔助區域存儲中。工作負載必須讀取二級區域存儲並寫入二級區域存儲。
數據流
處理數據流是一個更大的挑戰。流數據可以從各種來源攝取，並被處理和發送到流解決方案:
消息隊列，如Kafka
數據庫更改數據捕獲流
基於文件的連續處理
基於文件的調度處理，也稱為一次觸發
在所有這些情況下，都必須配置數據源以處理災難恢複模式，並在輔助區域中使用輔助部署。
流寫入器存儲關於已處理數據的信息的檢查點。這個檢查點可以包含一個數據位置(通常是雲存儲)，必須將其修改為一個新的位置，以確保流成功地重新啟動。例如,源檢查點下的子文件夾可能存儲基於文件的雲文件夾。
此檢查點必須及時複製。考慮與任何新的雲複製解決方案同步檢查點間隔。
檢查點更新是寫入器的一個功能，因此適用於數據流攝取或處理並存儲在另一個流源上。
對於流工作負載，確保在客戶管理的存儲中配置檢查點，以便將它們複製到次要區域，以便從上次故障點恢複工作負載。您還可以選擇與主進程並行運行輔助流進程。
步驟5:執行並測試你的解決方案
定期測試災難恢複設置，確保其正確運行。如果在需要時無法使用災難恢複解決方案，那麼維護它就沒有任何價值。有些公司每隔幾個月就會在不同地區之間切換。定期切換區域將測試您的假設和流程，並確保它們滿足您的恢複需求。這還可以確保您的組織熟悉應對緊急情況的政策和程序。
重要的
在現實環境中定期測試災難恢複解決方案。
如果您發現丟失了一個對象或模板，並且仍然需要依賴存儲在主工作區中的信息，那麼就修改您的計劃，以消除這些障礙，在輔助係統中複製這些信息，或者以其他方式使其可用。
一般來說，測試對流程和配置的任何必要的組織更改。災難恢複計劃會影響部署管道，因此團隊必須知道需要保持同步的內容。在設置災難恢複工作區之後，您必須確保您的基礎設施(手動或代碼)、作業、筆記本、庫和其他工作區對象在次要區域中可用。
與您的團隊討論如何擴展標準工作流程和配置管道，以將更改部署到所有工作區。在所有工作空間中管理用戶身份。記住為新工作區配置一些工具，比如作業自動化和監視。
計劃並測試對配置工具的更改:
攝取:了解您的數據源在哪裏，以及這些數據源從哪裏獲取數據。在可能的情況下，將源參數化，並確保有一個單獨的配置模板，用於處理次要部署和次要區域。準備故障轉移計劃並測試所有假設。
執行更改:如果您有一個調度器來觸發作業或其他操作，則可能需要配置一個單獨的調度器來處理輔助部署或其數據源。準備故障轉移計劃並測試所有假設。
交互式連接:考慮在使用REST api、CLI工具或JDBC/ODBC等其他服務時，區域中斷會如何影響配置、身份驗證和網絡連接。準備故障轉移計劃並測試所有假設。
自動化變更:對於所有自動化工具，準備故障轉移計劃並測試所有假設。
輸出:對於任何生成輸出數據或日誌的工具，準備故障轉移計劃並測試所有假設。
測試故障轉移
災難恢複可以由許多不同的場景觸發。它可能由意外的破裂引發。一些核心功能可能會中斷，包括雲網絡、雲存儲或其他核心服務。您無法正常關閉係統，必須嚐試恢複。但是，該過程可以通過關閉或計劃停用來觸發，甚至可以通過在兩個區域之間定期切換活動部署來觸發。
在測試故障轉移時，連接到係統並運行一個關閉進程。確保所有作業都完成並終止集群。
同步客戶端(或CI/CD工具)可以將相關的Databricks對象和資源複製到輔助工作區。要激活輔助工作空間，您的過程可能包括以下部分或全部:
運行測試以確認平台是最新的。Beplay体育安卓版本
在主區域上禁用池和集群，以便在失敗的服務恢複在線時，主區域不會開始處理新數據。
恢複過程:
檢查最近一次同步數據的日期。看到災難恢複行業術語．此步驟的詳細信息根據同步數據的方式和獨特的業務需求而有所不同。
穩定數據源並確保它們都是可用的。包括所有外部數據源(如AWS RDS)以及Delta Lake、Parquet或其他文件。
找到你的流恢複點。設置過程以從那裏重新啟動，並準備一個過程來識別和消除潛在的重複(Delta Lake Lake使這變得更容易)。
完成數據流流程並告知用戶。
啟動相關池(或增加
min_idle_instances相關數字)。啟動相關集群(如果沒有終止)。
更改作業的並發運行，並運行相關的作業。可以是一次性運行，也可以是周期性運行。
對於任何使用URL或域名作為Databricks工作區的外部工具，請更新配置以說明新的控製平麵。例如，更新REST api和JDBC/ODBC連接的url。當控製平麵發生變化時，Databricks web應用程序的麵向客戶的URL也會發生變化，所以要通知組織的用戶新的URL。
測試恢複(退回)
故障恢複更容易控製，可以在維護窗口中完成。這個計劃可以包括以下部分或全部:
確認主區域已恢複。
禁用輔助區域上的池和集群，這樣它就不會開始處理新數據。
將輔助工作空間中的任何新的或修改過的資產同步回主要部署。根據故障轉移腳本的設計，可以運行相同的腳本將對象從次要(災難恢複)區域同步到主要(生產)區域。
將任何新數據更新同步回主要部署。您可以使用日誌和Delta表的審計跟蹤來保證不丟失數據。
關閉災難恢複區域中的所有工作負載。
將作業和用戶URL更改為主要區域。
運行測試以確認平台是最新的。Beplay体育安卓版本
啟動相關池(或增加
min_idle_instances到相關的數字)。啟動相關集群(如果沒有終止)。
更改作業的並發運行，並運行相關的作業。可以是一次性運行，也可以是周期性運行。
根據需要，再次設置次要區域，以便將來進行災難恢複。
自動化腳本、示例和原型
用於災難恢複項目的自動化腳本:
Databricks建議您使用磚起程拓殖的提供者幫助您開發自己的同步過程。
另請參閱Databricks工作區遷移工具用於示例自動化和原型腳本。
的磚同步(DBSync)project是一個對象同步工具，用於備份、恢複和同步Databricks工作區。