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