本文涵蓋下列各節所列架構原則所組織 可靠性 的最佳做法。
1. 針對失敗進行設計
使用支援 ACID 交易的資料格式
ACID 交易是維護資料完整性和一致性的重要功能。 選擇支援 ACID 交易的資料格式可協助建置更簡單且更可靠的管線。
Delta Lake 是一種開放原始碼記憶體架構，可提供 ACID 交易 以及架構強制執行、可調整的元數據處理，以及統一串流和批次數據處理。 Delta Lake 與 Apache Spark API 完全相容，專為與結構化串流緊密整合而設計，可讓您輕鬆地針對批次和串流作業使用單一資料複本，並提供大規模增量處理。
針對所有工作負載使用復原性分散式資料引擎
Apache Spark 是 Azure Databricks Lakehouse 的計算引擎，是復原性的分散式資料處理為基礎。 如果內部 Spark 任務未如預期傳回結果，Apache Spark 將會自動重新排程遺漏的任務，並繼續執行整個工作。 這對非程式碼本身引起的故障很有幫助，例如短暫的網絡問題或被回收的 Spot VM。 使用 SQL API 和 Spark DataFrame API 時，此復原功能會內建於引擎中。
在 Databricks Lakehouse 中， Photon 是原生向量化引擎，完全以C++撰寫，是與 Apache Spark API 相容的高效能計算。
自動拯救無效或不符合格式的資料
無效或不符合規範的資料可能會導致依賴已建立資料格式的工作負載當機。 若要增加整個程序的端對端復原能力，最佳做法是在內嵌時篩選出無效和不符合規範的資料。 支援被恢復的資料可確保您在擷取或 ETL 過程中，絕不會遺失或遺漏資料。 已修復的資料行包含任何未剖析的資料，可能是因為該資料從指定的結構描述中遺失，因為類型不符，或因為記錄或檔案中的資料行主體寫與結構描述中的資料不相符。
Databricks 自動載入器：自動載入器是串流檔案擷取的理想工具。 此功能支援 JSON 和 CSV 的 復原數據。 例如，對於 JSON，已修復的資料行包含任何未剖析的資料，可能是因為該資料從指定的結構描述中遺失，因為類型不符，或因為資料行大小寫不相符。 被還原的資料數據行預設為
_rescued_data，是 Auto Loader 在推斷模式時傳回的結構描述的一部分。管道： 建置復原工作流程的另一個選項是使用具有品質條件約束的 Lakeflow 宣告式管線 。 請參閱 透過管線預期管理數據品質。 根據預設，Lakeflow 宣告式管線支援三種模式：保留、捨棄和失敗於無效的記錄。 若要隔離識別的無效記錄，預期規則可用特定方式定義，以便將無效的記錄儲存 (「隔離」) 在另一個資料表中。 請參閱 隔離無效的記錄。
設定工作以進行自動重試和終止
分散式系統實為複雜，某處發生失敗很可能會讓整個系統發生連鎖反應。
- Lakeflow Jobs 支持重試政策，以決定任務失敗執行的重試時間和次數。 請參閱 設定重試原則。
- 您可以設定任務的選擇性工期閾值，包括 任務的預期完成時間 ，以及任務完成時間上限。
- Lakeflow 宣告式管線 也會使用遞增重試來自動化失敗復原，以平衡速度和可靠性。 請參閱 開發和生產模式。
另一方面，延宕的任務可能會阻止整個作業的完成，導致高昂的成本。 Lakeflow 作業支援逾時設定，以終止比預期更長的作業。
使用可擴展且生產級的模型服務基礎結構
針對批次和串流推斷，請使用 Lakeflow 作業和 MLflow 將模型部署為 Apache Spark UDF，以利用作業排程、重試、自動調整等等。 如需 批次推斷和預測，請參閱部署模型。
模型服務 為即時模型服務提供可調整且生產等級的基礎結構。 它使用 MLflow 處理您的機器學習模型，並將其公開為 REST API 端點。 這項功能使用無伺服器計算，表示端點和相關聯的計算資源是在 Azure Databricks 雲端帳戶中管理和執行。
盡可能使用受控服務
透過 Databricks Data Intelligence Platform，利用管理式服務（無伺服器計算），例如：
這些服務是由 Databricks 以可靠且可調整的方式運作，讓工作負載更可靠。
2. 管理資料品質
使用分層儲存體架構
透過建立分層架構，並確保資料在各層中移動時品質不斷提升，以此策劃資料。 常見的分層方法是：
- 原始圖層（青銅）： 源數據會載入到資料湖屋的第一層，應當保留在那裡。 從原始層建立所有下游資料時，可視需要重建此層的後續層。
- 整理層（銀）： 第二層的目的在於存放已清理、精煉、篩選和匯總的資料。 此層的目標是為所有角色和職能提供穩固、可靠的分析和報告基礎。
- 最後一層 （金）： 第三層是以商務或專案需求為基礎所建置。 它作為資料產品，為其他營業單位或專案提供不同的視角，並且根據安全需求（例如，匿名化資料）準備數據，或者進行效能最佳化（例如，使用預先彙總的數據視圖）。 此層中的資料產品會被視為業務真相。
最後一層應該只包含高品質的資料，並且從商務角度來看是完全可信的。
藉由減少資料備援來改善資料完整性
拷貝或複製資料會建立資料備援，並導致完整性遺失、資料譜系遺失，以及通常不同的存取權限。 這樣可降低 Lakehouse 中資料的品質。
暫時或可處置的資料復本本身並不有害，有時需要提高敏捷度、實驗性和創新性。 不過，當這些復本變成可運作且經常用來做出商務決策時，它們就會成為資料孤島。 當這些資料孤島不同步時，會對資料完整性和品質產生重大負面影響，並引發等疑問，如「哪一個資料集是主要資料集？」 或「資料集是否是最新的？」
主動管理架構
不受控制的結構描述變更可能會導致無效資料，以及使用這些資料集的工作失敗。 Azure Databricks 有數種方法可驗證並強制執行結構描述：
- Delta Lake 支援結構描述驗證和結構描述強制執行，可自動處理結構描述變化，以避免在擷取期間插入不正確的記錄。 請參閱 架構強制執行。
-
自動載入器 會在處理您的數據時偵測新數據行的新增。 預設情況下，新增資料行會導致你的串流停止，並顯示
UnknownFieldException。 自動載入器支援數種 架構演進模式。
使用條件約束和資料預期
Delta 資料表支援標準 SQL 的約束管理子句，以確保對新增至資料表的資料自動檢查其品質和完整性。 違反條件約束時，Delta Lake 會 InvariantViolationException 擲回錯誤，表示無法新增新數據。 請參閱 Azure Databricks 的條件約束。
為了進一步改善此處理，Lakeflow 宣告式管線支援預期條件：預期條件會定義數據集內容的數據品質限制。 預期包含描述、非變異值，以及記錄違反非變異值時要採取的動作。 查詢預期會用 Python 裝飾器或 SQL 約束子句。 請參閱 透過管線預期管理數據品質。
採用以資料為中心的機器學習方法
Databricks Data Intelligence Platform 的 AI 願景的核心準則是以資料為中心的機器學習方法。 隨著生成式 AI 變得越來越普遍，此觀點仍然同樣重要。
任何 ML 專案的核心元件都可視為資料管線：特徵工程、訓練、模型部署、推斷和監視管線都是資料管線。 因此，讓 ML 解決方案運作需要將預測、監視和功能資料表中的資料與其他相關資料合併。 基本上，達成此目的最簡單的方式是在用來管理生產資料的相同平台上開發 AI 支援的解決方案。 請參閱 以數據為中心的MLOps和LLMOps
3. 為自動擴展設計
啟用 ETL 工作負載的自動擴縮調整
自動調整 可讓叢集根據工作負載自動重設大小。 自動調整規模可以從成本和效能的角度來提升許多使用案例和情境。 文件提供用來判斷是否要使用自動調整及如何取得最大效益的考慮因素。
針對串流工作負載，Databricks 建議使用具有自動調整功能的 Lakeflow 宣告式管線。 Databricks 增強的自動調整 透過自動配置叢集資源以優化叢集使用，並根據工作負載量進行調整，從而將對管線數據處理延遲的影響降至最低。
啟用 SQL 倉儲的自動縮放
SQL 倉儲的縮放參數會設定傳送至倉儲的查詢所分佈的最小和最大叢集數目。 預設值為只有一個沒有自動縮放的叢集。
若要處理指定倉儲的更多並行使用者，先增加叢集數目。 若要瞭解 Azure Databricks 如何將叢集新增至倉儲並從中移除叢集，請參閱 SQL 倉儲大小調整、調整和佇列行為。
4. 測試復原程序
從結構化串流查詢失敗中復原
結構化串流提供串流查詢的容錯和資料一致性。 使用 Lakeflow 作業，您可以輕鬆地設定結構化串流查詢，以在失敗時自動重新啟動。 藉由啟用流式查詢的檢查點，您可以在發生故障後重新啟動查詢。 重新啟動的查詢會從失敗的查詢離開的地方繼續進行。 請參閱 結構化串流檢查點 和 結構化串流的生產環境注意事項。
使用資料時光旅行功能復原ETL工作
儘管經過徹底的測試，但在生產環境中工作可能會失敗，或產生非預期甚至無效的資料。 有時候，在了解問題來源並修正最初引發問題的管線後，可以透過執行其他工作來解決此問題。 不過，通常情況下，這並不簡單，應該將相關的工作回退。 使用 Delta Time 技術，用戶可以輕鬆地回滾至較舊版本或時間戳的變更，修復管線，然後重新啟動修復後的管線。
便捷方式是使用 RESTORE 命令。
利用具有內建恢復功能的自動化工作架構
Lakeflow 作業 是專為復原而設計的。 當多任務工作的工作失敗時（例如所有相依工作），作業會提供執行矩陣檢視，讓您調查導致失敗的問題，請參閱 檢視單一作業的執行。 無論是短暫的網路問題還是數據中的實際問題，您都可以修正這些問題，並在 Lakeflow 作業中啟動修復作業流程。 它只會執行失敗和相依的工作，並保留先前執行的成功結果，節省時間和金錢，請參閱 疑難解答和修復作業失敗。
設定災害復原模式
對於 Azure Databricks 之類的雲端原生資料分析平台，明確的災害復原模式非常重要。 即使在區域性災害如颶風、地震或其他原因導致雲端服務提供者全服務中斷的罕見事件中，您的數據團隊仍然可以使用 Azure Databricks 平臺。
Azure Databricks 通常是整體數據生態系統的核心部分，其中包含許多服務，包括上游數據擷取服務（批次/串流）、雲端原生記憶體，例如 Azure Data Lake Storage、下游工具和服務，例如商業智慧應用程式，以及協調流程工具。 部分使用案例可能會對區域範圍服務中斷特別敏感。
災害復原 牽涉到一組原則、工具和程式，可在自然或人為引發的災害之後，復原或延續重要的技術基礎結構和系統。 Azure 之類的大型雲端服務會為許多客戶提供服務，並具有防範單一失敗的內建防護功能。 例如，區域是連線至不同電源的建築物群組，可確保單一停電事件不會導致一個區域癱瘓。 不過，可能會發生雲端區域失敗，並且失敗的嚴重性及其對企業的影響可能會有所不同。
5. 自動化部署和工作負載
請參閱 卓越營運 - 自動化部署和工作負載。
6. 監視系統和工作負載
請參閱 卓越營運 - 設定監視、警示和記錄。