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