可靠性最佳做法
本文涵蓋可靠性的最佳做法，並按下列各節所列的架構原則進行組織。
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 管理資料品質 (機器翻譯)。 現成的差異即時資料表支援三種模式：保留、卸除和無效記錄失敗。 若要隔離識別的無效記錄，預期規則可用特定方式定義，以便將無效的記錄儲存 (「隔離」) 在另一個資料表中。 請參閱隔離無效的資料。
設定工作以進行自動重試和終止
分散式系統實為複雜，某處發生失敗很可能會讓整個系統發生連鎖反應。
- Azure Databricks 工作支援重試原則，用於決定重試失敗執行的時間和次數。 請參閱設定重試原則。
- 可設定任務的可選持續時間閾值，包括任務的預期完成時間，以及任務的完成時間上限。
- 差異即時資料表也會使用呈報的重試以平衡速度和可靠性，自動復原失敗。 請參閱開發和生產模式。
另一方面，掛起的任務可能會阻止整個工作完成，導致高昂的成本。 Databricks 工作支援逾時設定，以終止長於預期的工作。
使用可調整和生產等級的模型服務基礎結構
針對批次和串流推斷，請使用 Azure Databricks 工作和 MLflow 將模型部署為 Apache Spark UDF，以有效利用工作排程、重試、自動調整等等。 如需批次推斷和預測，請參閱部署模型。
模型服務為即時模型服務提供可調整和生產等級的基礎結構。 它使用 MLflow 處理您的機器學習模型，並將其公開為 REST API 端點。 這項功能使用無伺服器計算，表示端點和相關聯的計算資源是在 Azure Databricks 雲端帳戶中管理和執行。
盡可能使用受控服務
從 Databricks Data Intelligence Platform 有效利用受控服務 (無伺服器計算)，例如：
這些服務由 Databricks 以可靠且可調整的方式運作，客戶沒有額外的成本，使工作負載更加可靠。
2. 管理資料品質
使用分層儲存體架構
藉由建立分層架構，並確保資料品質隨著資料在各層中移動而增加，由此策劃資料。 常見的分層方法是：
- 原始層 (青銅)：來源資料會內嵌到 lakehouse 的第一層，並應保留在那裡。 從原始層建立所有下游資料時，可視需要重建此層的後續層。
- 策展層 (白銀)：第二層的目的是保留經過清理、精簡、篩選和彙總的資料。 此層的目標是為所有角色和函式提供穩固、可靠的分析和報告基礎。
- 最後一層 (黃金)：第三層圍繞商業或專案需求而建置。 它提供不同的視圖，作為其他營業單位或專案的資料產品，圍繞安全需求準備資料 (例如匿名資料)，或最佳化效能 (例如使用預先彙總的視圖)。 此層中的資料產品會被視為業務真相。
最後一層應該只包含高品質的資料，並且從商務角度來看是完全可信的。
藉由減少資料備援來改善資料完整性
拷貝或複製資料會建立資料備援，並導致完整性遺失、資料譜系遺失，以及通常不同的存取權限。 這樣可降低 Lakehouse 中的資料品質。
暫時或可處置的資料復本本身並不有害，有時需要提高敏捷度、實驗性和創新性。 不過，當這些復本變成可運作且經常用來做出商務決策時，它們就會成為資料孤島。 當這些資料孤島不同步時，會對資料完整性和品質產生重大負面影響，並引發等疑問，如「哪一個資料集是主要資料集？」 或「資料集是否為目前狀態？」
主動管理結構描述
不受控制的結構描述變更可能會導致無效資料，以及使用這些資料集的工作失敗。 Azure Databricks 有數種方法可驗證並強制執行結構描述：
- Delta Lake 支援結構描述驗證和結構描述強制執行，可自動處理結構描述變化，以避免在擷取期間插入不正確的記錄。 請參閱強制執行結構描述。
- 自動載入器會在處理您的資料時偵測新資料行的新增情況。 根據預設，新增資料行會導致串流以
UnknownFieldException停止使用。 自動載入器支援數種結構描述演進模式。
使用條件約束和資料預期
差異資料表支援標準 SQL 條件約束管理子句，以確保會自動檢查新增至資料表的資料品質和完整性。 違反條件約束時，Delta Lake 會擲回 InvariantViolationException 錯誤，表示無法新增新資料。 請參閱 Azure Databricks 中的條件約束。
為了進一步改善此處理，差異即時資料表支援預期：預期會定義資料集內容的資料品質條件約束。 預期包含描述、非變異值，以及記錄違反非變異值時要採取的動作。 查詢預期使用 Python 裝飾項目或 SQL 限制式子句。 請參閱使用 Delta Live Tables 管理資料品質 (機器翻譯)。
採用以資料為中心的機器學習方法
Databricks Data Intelligence Platform 的 AI 願景的核心準則是以資料為中心的機器學習方法。 隨著生成式 AI 變得越來越普遍，此觀點仍然同樣重要。
任何 ML 專案的核心元件都可視為資料管線：特徵工程、訓練、模型部署、推斷和監視管線都是資料管線。 因此，讓 ML 解決方案運作需要將預測、監視和功能資料表中的資料與其他相關資料合併。 基本上，達成此目的最簡單的方式是在用來管理生產資料的相同平台上開發 AI 支援的解決方案。 請參閱以資料為中心的 MLOps 和 LLMOps
3. 自動調整的設計
啟用 ETL 工作負載的自動調整
自動調整可讓叢集根據工作負載自動重設大小。 自動調整可從成本和效能角度獲益於許多使用案例和案例。 文件提供判斷了是否要使用自動調整，以及如何取得最大效益的考量。
對於串流工作負載，Databricks 建議使用差異即時資料表與自動調整。 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 之類的大型雲端服務會為許多客戶提供服務，並具有防範單一失敗的內建防護功能。 例如，區域是連線至不同電源的建築物群組，可確保單一停電事件不會導致一個區域癱瘓。 不過，可能會發生雲端區域失敗，並且失敗的嚴重性及其對企業的影響可能會有所不同。