Data Lakehouse 的可靠性

可靠性支柱的架構原則可解決系統從失敗中復原的能力，並繼續運作。

可靠性原則

1. 設計失敗

   在高度分散式的環境中，可能會發生中斷。 針對平臺和各種工作負載，例如串流作業、批次作業、模型定型和 BI 查詢，必須預期失敗，且必須開發彈性解決方案，以提高可靠性。 重點是設計應用程式以快速復原，並在最佳情況下自動復原。

2. 管理數據品質

   數據品質是從數據衍生精確且有意義的深入解析的基礎。 數據質量有許多維度，包括完整性、精確度、有效性和一致性。 必須主動管理，才能改善最終數據集的品質，讓數據成為商務使用者可靠且值得信任的資訊。

3. 自動調整的設計

   標準 ETL 程式、商務報告和儀錶板在記憶體和計算方面通常具有可預測的資源需求。 不過，新專案、季節性工作或進階方法，例如模型定型（適用於變換、預測和維護），會建立資源需求的尖峰。 若要讓組織處理所有這些工作負載，它需要可調整的記憶體和計算平臺。 視需要新增資源必須簡單，而且只應收取實際耗用量的費用。 一旦尖峰結束，就可以釋出資源，並據以降低成本。 這通常稱為水平調整（節點數目）和垂直調整（節點大小）。

4. 測試復原程式

   大部分應用程式和系統的全企業災害復原策略都需要評估優先順序、功能、限制和成本。 可靠的災害復原方法會定期測試工作負載失敗和驗證復原程式的方式。 自動化可用來模擬不同的失敗，或重新建立過去造成失敗的案例。

5. 自動化部署和工作負載

   自動化 Lakehouse 的部署和工作負載有助於標準化這些程式、消除人為錯誤、改善生產力，並提供更高的重複性。 這包括使用「組態即程序代碼」來避免設定漂移，以及「基礎結構即程序代碼」，以自動化布建所有必要的 Lakehouse 和雲端服務。

6. 監視系統和工作負載

   Lakehouse 中的工作負載通常會整合 Databricks 平臺服務和外部雲端服務，例如數據源或目標。 只有在執行鏈結中的每個服務正常運作時，才會成功執行。 當情況並非如此時，監視、警示和記錄對於偵測和追蹤問題及了解系統行為很重要。

下一步：可靠性的最佳做法

請參閱 可靠性的最佳做法。