卓越營運的最佳做法
本文涵蓋卓越營運的最佳做法，並按下列各節所列的架構原則進行組織。
1. 最佳化組建和發行程序
建立專用的 Lakehouse 作業團隊
常見的最佳做法是設立一個平台作業小組，讓資料團隊能夠在一或多個資料平台上工作。 此團隊負責在內部建立藍圖和最佳做法。 它們提供基礎結構自動化和自助式存取等工具，並確保符合安全性和合規性需求。 這樣一來，即會將保護平台資料的責任交於中央團隊，從而讓分散式團隊能夠專注於處理資料並產生新的深入解析。
使用企業原始程式碼管理 (SCM)
原始程式碼管理 (SCM) 可協助開發人員更有效率地工作，進而加快發行速度並降低開發成本。 擁有可協助追蹤變更、維護程式碼完整性、偵測錯誤並復原至舊版的工具，是整體方案架構的重要元件。
Databricks Git 資料夾可讓使用者將筆記本或其他檔案儲存在 Git 存放庫中，提供複製存放庫、認可和推送、提取、分支管理和檢視檔案差異等功能。 使用 Git 資料夾以取得更佳的程式碼可見度和追蹤。
標準化 DevOps 程序 (CI/CD)
持續整合與持續傳遞 (CI/CD) 是指使用自動化管線，以簡短、頻繁的週期開發及交付軟體。 雖然這不是一個新程序，在傳統軟體工程中已普遍存在數十年之久，但它正逐漸成為資料工程和資料科學團隊的必要程序。 若要讓資料產品具有價值，必須及時傳遞資料產品。 此外，消費者必須對這些產品內的結果有效性充滿信心。 藉由自動化建置、測試和部署程式碼的程序，開發團隊可以比仍然主導許多資料工程和資料科學團隊的手動程序更頻繁且可靠地傳遞版本。 請參閱 Azure Databricks 上的 CI/CD 是什麼？。
如需使用 Databricks Git 資料夾進行程式碼開發最佳做法的詳細資訊，請參閱使用 Git 和 Databricks Git 資料夾的 CI/CD 技術 (Repos)。 搭配 Databricks REST API，您可以使用 GitHub Actions、Azure DevOps 管線或 Jenkins 工作來建立自動化部署程序。
標準化 MLOps 程序
MLOps 程序可提供 ML 管線的重現性，從而實現資料團隊之間更緊密結合的共同作業、減少與 DevOps 和 IT 的衝突，以及加快發行速度。 由於許多模型用來驅動關鍵商務決策，標準化 MLops 程序可確保模型會以一致且可靠的方式進行開發、測試及部署。
建置和部署 ML 模型比較複雜。 有許多選項可用來達成此目的，但用於定義完善的標準的選項很少。 因此，在過去的幾年裡，我們看到了機器學習作業 (MLOps) 的問世。 MLOps 是一組用於管理模型、資料和程式碼的程序和自動化，以提高 ML 系統的效能穩定性和長期效率。 其涵蓋資料準備、探索式資料分析 (EDA)、特徵工程、模型訓練、模型驗證、部署和監視。
Databricks 平台上的 MLOps 可協助您最佳化機器學習 (ML) 系統的效能和長期效率：
- 始終牢記您的商業目標：就像企業中的 ML 核心目的是啟用資料驅動決策和產品一樣，MLOps 的核心目的是確保這些資料驅動應用程式保持穩定、保持最新，並繼續對企業產生積極影響。 設定 MLOps 上的技術工作的優先權時，請考慮業務影響：是否啟用新的商務使用案例？ 其是否可改善資料團隊的生產力？ 其是否會降低營運成本或風險？
- 使用專業的開放式工具管理 ML 模型：您可以使用 MLflow (專為 ML 模型生命週期所設計) 來追蹤和管理 ML 模型。 請參閱 使用 MLflow 的 ML 生命週期管理。
- 以模組化方式實作 MLOps：如同任何軟體應用程式，程式碼品質對於 ML 應用程式而言至關重要。 模組化程式碼可讓您測試個別元件，並降低未來程式碼重構的難度。 定義清楚的步驟 (例如訓練、評估或部署)、進階步驟 (例如訓練到部署管線) 及責任，以釐清 ML 應用程式的模組化結構。
Databricks 電子書 The Big Book of MLOps 對此進行了詳細說明。
定義環境隔離策略
當組織使用 Databricks 之類的資料平台時，通常需要在環境 (例如開發與實際執行) 或組織營運單位之間建立資料隔離邊界。
隔離標準可能會因組織而異，但通常包含下列預期：
- 使用者只能根據指定的存取規則取得資料的存取權。
- 資料只能由指定的人員或團隊管理。
- 資料會在儲存體中實體分離。
- 資料只能在指定的環境中存取。
在 Databricks 中，工作區是主要資料處理環境，而且有數個案例可改善整體設定，例如：
- 將不同的營業單位與自己的工作區隔離，以避免共用工作區系統管理員，並確保 Databricks 中的任何資產皆不會不小心地在營業單位之間共用。
- 隔離軟體開發生命週期環境 (例如開發、預備和實際執行環境)。 例如，個別的生產工作區可讓您先測試新的工作區設定，再將其套用至實際執行環境。 或者，實際執行環境可能需要比開發環境更嚴格的工作區設定。 如果您必須在不同的虛擬網路上部署開發、預備和實際執行環境，則這三個環境也需要不同的工作區。
- 分割工作區以克服資源限制：雲端帳戶/訂用帳戶具有資源限制。 將工作區分割成不同的訂用帳戶/帳戶，是確保每個工作區有足夠資源可用的方法。 此外，Databricks 工作區也具有資源限制。 分割工作區可確保每個工作區中的工作負載始終可以存取完整的資源集。
不過，還應該考慮到共用工作區會有一些缺點：
筆記本共同作業無法跨工作區運作。
針對多個工作區，設定和維護都需要完全自動化 (透過 Terraform、ARM、REST API 或其他方式)。 這對於移轉目的而言尤為重要。
如果需要在網路層保護每個工作區 (例如，若要防止資料外流)，則所需的網路基礎結構可能非常昂貴，尤其是對於大量工作區。
請務必找出隔離需求和共同作業需求與維護作業所需的工作之間的平衡。
為您的企業定義目錄策略
除了環境隔離策略之外，組織還需要一個策略來建構和分隔中繼資料和資料。 資料 (包括個人識別資訊、付款或健康情況資訊) 具有很高的潛在風險，並且隨著資料外洩的威脅不斷增加，無論您選擇的組織策略為何，分隔和保護敏感性資料都非常重要。 從邏輯和實體上分隔您的敏感性資料與非敏感性資料。
組織可能要求將特定類型的資料儲存在其雲端租用戶的特定帳戶或貯體中。 Unity Catalog 中繼存放區允許透過其三層 catalog > schema > tables/views/volumes 命名空間來結構化中繼資料，並在中繼存放區、目錄或結構描述層級設定儲存位置，以符合這類需求。
組織與合規性需求通常會規定，您僅在特定環境中保留特定資料。 您可能也想要將生產資料與開發環境保持隔離，或確保永遠不會合併特定資料集和網域。 在 Databricks 中，工作區是主要計算環境，而目錄是主要資料網域。 使用 Unity Catalog 中繼存放區，系統管理員和目錄擁有者可以將目錄繫結至特定工作區。 這些環境感知繫結可協助您確保工作區中只有特定目錄可供使用，而不論授與使用者的特定資料物件權限為何。
如需這些主題的完整討論，請參閱 Unity Catalog 最佳做法
2. 自動化部署和工作負載
使用基礎結構即程式碼 (IaC) 進行部署和維護
基礎結構即程式碼 (IaC) 可讓開發人員和作業團隊自動管理、監視及佈建資源，而不是手動設定硬體裝置、作業系統、應用程式和服務。
HashiCorp Terraform 是熱門的開放原始碼工具，可跨數個雲端提供者建立安全且可預測的雲端基礎結構。 Databricks Terraform 提供者會使用彈性且功能強大的工具來管理 Azure Databricks 工作區和關聯的雲端基礎結構。 Databricks Terraform 提供者的目標是支援所有 Azure Databricks REST API，支援部署和管理資料平台的最複雜層面的自動化。 Databricks Terraform 提供者是建議的工具，能可靠地部署和管理叢集和工作、佈建 Azure Databricks 工作區及設定資料存取。
標準化計算組態
標準化計算環境可確保在所有環境中使用相同的軟體、程式庫和組態。 此一致性可讓您更輕鬆地跨環境重現結果、偵錯問題及維護系統。 透過標準化的環境，團隊可以節省時間和資源，而無需從頭設定環境。 這也會降低手動設定期間可能發生的錯誤和不一致的風險。 標準化也可讓您在所有環境中實作一致的安全性原則和做法。 這可協助組織更妥善地管理風險，並符合法規需求。 最後，標準化可協助組織減少浪費及最佳化資源使用率，進而更好地管理成本。
標準化涵蓋環境設定和進行中的資源管理。 為實現一致設定，Databricks 建議使用基礎結構即程式碼。 若要確保一致設定隨時間啟動的計算資源，請使用計算原則。 Databricks 工作區系統管理員可以根據一組原則規則來限制使用者或群組的計算建立權限。 他們可以強制執行 Spark 組態設定，並強制執行叢集範圍的程式庫安裝。 您也可以使用計算原則，將專案的 T 恤大小叢集 (S、M、L) 定義為標準工作環境。
使用工作的自動化工作流程
設定工作的自動化工作流程有助於減少不必要的手動任務，並透過建立和部署工作的 DevOps 程序來提高生產力。 Data Intelligence Platform 提供兩種方法來執行以下動作：
Databricks 工作：
Databricks 工作可在 Databricks Data Intelligence Platform 中協調資料處理、機器學習和分析管線。 它是與 Databricks 平台整合的完全受控協調流程服務：
- Databricks 工作 是在 Databricks 工作區中執行資料處理和分析應用程式的一種方式。 您的工作可以是單一任務，也可以是具有複雜相依性的大型多工工作流程。 Databricks 會管理所有工作的任務協調流程、叢集管理、監視和錯誤報表。
- Delta Live Tables 是一種宣告式架構，可建置可靠、可維護且可測試的資料處理管線。 您可定義您要對資料執行的轉換，而 Delta Live Tables 會管理任務協調流程、叢集管理、監視、資料品質及錯誤處理。
外部協調器：
外部協調器會使用完整的 Azure Databricks REST API 來協調 Databricks 資產、筆記本和工作。 請參閱：
我們建議針對 Databricks 中的所有任務相依性使用 Databricks 工作，並視需要將這些封裝的工作流程整合至外部協調器
使用自動化和事件驅動檔案擷取
事件驅動 (與排程驅動) 檔案擷取具有幾個優點，包括效率、提升資料時效性，以及即時資料擷取。 只有當事件發生時，才會執行工作，以確保您不會浪費資源，進而節省成本。
自動載入器可在新資料檔案抵達雲端儲存時，逐步有效地進行處理。 它可以擷取許多檔案格式，例如 JSON、CSV、PARQUET、AVRO、ORC、TEXT 和 BINARYFILE。 藉助雲端儲存上的輸入資料夾，自動載入器會在新檔案抵達時自動處理。
若為一次性擷取，請考慮改用 COPY INTO 命令。
為資料管線使用 ETL 架構
雖然可以手動執行 ETL 任務，但使用架構具有許多優點。 架構可為 ETL 程序帶來一致性和重複性。 藉由提供預先建置的函式和工具，架構可以將一般任務自動化，以節省時間和資源。 ETL 架構可以處理大量資料，而且可以視需要輕鬆地擴大或縮小。 這可讓您更輕鬆地管理資源，並回應不斷變化的商務需求。 許多架構都包含內建的錯誤處理和記錄功能，讓您能夠更輕鬆地識別和解決問題。 而且它們通常會包含資料品質檢查和驗證，以確保資料符合特定標準，然後再將其載入資料倉儲或資料湖。
Delta Live Tables 是一種宣告式架構，可建置可靠、可維護且可測試的資料處理管線。 您可定義您要對資料執行的轉換，而 Delta Live Tables 會處理任務協調流程、叢集管理、監視、資料品質及錯誤處理。
使用 Delta Live Tables，您可以在 SQL 或 Python 中定義端對端資料管線：指定資料來源、轉換邏輯和資料的目標狀態。 Delta Live Tables 會維護相依性，並自動判定要執行工作的基礎結構。
為了管理資料品質，Delta Live Tables 會監視一段時間的資料品質趨勢，並透過預先定義的錯誤原則的驗證和完整性檢查來防止將錯誤的資料輸入資料表。 請參閱什麼是差異即時資料表？。
遵循 ML 工作負載的 deploy-code 方法
程式碼和模型通常會透過軟體開發階段以非同步方式處理。 有兩個方法可以達成：
- 部署程式碼：ML 專案會在開發環境中撰寫程式碼，然後此程式碼會移至預備環境，並在其中進行測試。 成功測試之後，專案程式碼會部署到執行所在的實際執行環境。
- 部署模型：模型訓練會在開發環境中執行。 然後，產生的模型成品會移至預備環境進行模型驗證檢查，然後再將模型部署至實際執行環境。
請參閱模型部署模式。
Databricks 建議對大部分使用案例使用 deploy-code 方法。 此模型的主要優勢包括：
- 這適用傳統的軟體工程工作流程，可使用熟悉的工具，例如 Git 和 CI/CD 系統。
- 它支援在鎖定環境中進行自動重新訓練。
- 其僅要求實際執行環境對生產訓練資料具有讀取存取權。
- 其可完整控制訓練環境，進而協助簡化重現性。
- 它可讓資料科學團隊使用模組化程式碼和反覆項目測試，協助在較大型的專案中進行協調與開發。
Databricks 電子書 The Big Book of MLOps 對此進行了詳細說明。
使用模型登錄來分離程式碼和模型生命週期
由於模型生命週期與程式碼生命週期並非一對一對應，Unity Catalog 可讓 ML 模型的完整生命週期在其託管的 MLflow 模型登錄版本中進行管理。 Unity Catalog 中的模型會將 Unity Catalog 的優點延伸到 ML 模型，包括跨工作區的集中式存取控制、稽核、譜系和模型探索。 Unity Catalog 中的模型可與開放原始碼 MLflow Python 用戶端相容。
自動化 ML 實驗追蹤
追蹤 ML 實驗是儲存每個實驗的相關中繼資料及組織實驗的程序。 此中繼資料包含實驗輸入/輸出、參數、模型和其他成品。 實驗追蹤的目標是在 ML 模型開發程序的每個階段建立可重現的結果。 自動化此程序可更輕鬆地調整實驗數目，並確保所有實驗中擷取的中繼資料的一致性。
Databricks 自動記錄是一種無程式碼解決方案，可延伸 MLflow 自動記錄，以提供 Azure Databricks 上機器學習訓練工作階段的自動實驗追蹤。 當您使用記錄為 MLflow 追蹤執行的訓練執行來訓練模型時，Databricks 自動記錄會自動擷取模型參數、計量、檔案和譜系資訊。
重複使用相同的基礎結構來管理 ML 管線
ML 管線使用的資料通常來自與其他資料管線使用的資料相同的來源。 ML 和資料管線很類似，兩者皆會為商務使用者分析或模型訓練準備資料。 這兩者也都需要可調整、安全且適當的監視。 在這兩種情況下，使用的基礎結構都應該支援這些活動。
使用 Databricks Terraform 提供者自動部署 ML 環境。 ML 需要部署基礎結構，例如推斷工作、服務端點和特徵化工作。 所有 ML 管線都可以自動化為工作，而且許多以資料為中心的 ML 管線可以使用更專業的自動載入器來擷取影像和其他資料，以及使用 Delta Live Tables 來計算特徵或監視計量。
請務必使用模型服務進行 ML 模型的企業級部署。
利用複雜資料和 ML 專案的宣告式管理
MLOps 內的宣告式架構可讓團隊以高階詞彙定義所需的結果，並讓系統處理執行的詳細資料，簡化 ML 模型的部署和調整。 這些架構支援持續整合與部署、自動化測試和基礎結構管理，並確保模型治理與合規性，最終加速上市以及提升 ML 生命週期的生產力。
Databricks Asset Bundles (DAB) 是簡化開發 Databricks 平台的複雜資料、分析和 ML 專案的工具。 套件組合可讓您使用單一、簡潔的宣告式 YAML 語法，在軟體開發工作流程中提供 CI/CD 功能，進而在積極開發期間輕鬆管理複雜的專案。 藉由使用套件組合將專案的測試、部署和組態管理自動化，您可以減少錯誤，同時將整個組織的軟體最佳做法提升為範本化專案。
3. 管理容量與配額
管理服務限制與配額
管理服務限制與配額對於維護正常運作的基礎結構以及防止非預期的成本很重要。 在雲端上啟動的每個服務都必須考慮限制，例如存取速率限制、執行個體數目、使用者數目和記憶體需求。 針對您的雲端提供者，請檢查 雲端限制。 在設計解決方案之前，必須了解這些限制。
具體而言，針對 Databricks 平台，有不同類型的限制：
Databricks 平台限制：這些是 Azure Databricks 資源的特定限制。 整體平台的限制記載於資源限制中。
Unity Catalog 限制：Unity Catalog 資源配額
訂用帳戶/帳戶配額：Azure Databricks 會為其服務利用雲端資源。 例如，Azure Databricks 上的工作負載會在叢集上執行，而 Databricks 平台會啟動雲端提供者的虛擬機器 (VM)。 雲端提供者會針對可以同時啟動多少 VM 設定預設配額。 視需要而定，可能需要調整這些配額。
如需進一步的詳細資料，請參閱增加 VM 系列 vCPU 配額。
以類似的方式，儲存體、網路和其他雲端服務具有必須了解及納入考量的限制。
投資容量規劃
容量規劃涉及管理雲端資源，例如儲存體、計算和網路，以維護效能，同時最佳化成本。 規劃預期負載的變化，其中這些變化可能會因為各種原因而發生，包括突然的商務變更，甚至是世界事件。 測試負載變化，包括非預期的負載變化，以確保您的工作負載可以調整。 確保如果一個區域失敗，所有區域都可以充分調整以支援總負載。 考量：
- 技術和服務限制與雲端限制。 請參閱管理容量與配額。
- 判定要用於設計的服務的 SLA。
- 成本分析，以判定如果成本增加，應用程式會實現多少改善。 評估價格是否值得投資。
了解和規劃高優先順序 (磁碟區) 事件很重要。 如果佈建的雲端資源不足且工作負載無法調整，這類增加的磁碟區可能會導致中斷。
4. 設定監視、警示和記錄
建立監視程序
出於多種原因，為資料平台建立監視程序十分重要。 監視程序可讓您提早偵測資料品質問題、效能瓶頸和系統失敗等問題，而這有助於防止停機和資料遺失。 其可協助識別資料平台中的效率不佳，並藉由減少浪費及改善資源使用率來最佳化成本。 此外，監視程序可協助確保符合法規需求，並提供資料存取和使用方式的稽核線索。
使用原生和外部工具進行平台監視
Databricks Data Intelligence Platform 具有內建的監視解決方案，並可整合外部監視系統：
使用 Azure 監視解決方案進行平台監視
監視對任何生產層級解決方案都至關重要，而 Azure Databricks 可提供強固的功能來監視自訂應用程式計量、串流查詢事件，以及應用程式記錄檔訊息。 Azure Databricks 可以將此監視資料傳送至不同的記錄服務。 下列文章說明如何將監視資料從 Azure Databricks 傳送至 Azure 監視器 (Azure 的監視資料平台)。
Databricks Lakehouse Monitoring
Databricks Lakehouse Monitoring 可讓您監視帳戶中所有資料表中的資料的統計屬性和品質。 資料品質監視可提供量化量值來追蹤和確認一段時間的資料一致性，並協助識別和警示使用者資料散發和模型效能中的變更。 您也可以監視包含模型輸入和預測的推斷資料表，以追蹤機器學習模型的效能。
請參閱檢視 Lakehouse Monitoring 費用，以了解 Lakehouse Monitoring 的成本。
SQL 倉儲監視
監視 SQL 倉儲對於了解一段時間的負載設定檔以及有效率地管理 SQL 倉儲而言非常重要。 透過 SQL 倉儲監視，您可以檢視資訊，例如倉儲處理的查詢數目或配置給倉儲的叢集數目。
Databricks SQL 警示
Databricks SQL 警示會定期執行查詢、評估定義的條件，並在符合條件時傳送通知。 您可以設定警示來監視您的業務，並在報告的資料超出預期限制時傳送通知。
此外，您可以根據監視計量資料表的計量來建立 Databricks SQL 警示，例如，在統計資料移出特定範圍時或者資料與基準資料表相比發生偏移時，收到通知。
自動載入器監視
自動載入器會提供 SQL API 來檢查串流的狀態。 使用 SQL 函式，您可以找到自動載入器串流探索到的檔案的相關中繼資料。 請參閱監視自動載入器。
使用 Apache Spark 串流查詢接聽程式 介面，可以進一步監視自動載入器串流。
工作監視
作業監視可協助您識別並解決 Databricks 作業中的問題，例如失敗、延遲或效能瓶頸。 作業監視提供工作效能的深入解析，可讓您最佳化資源使用率、減少浪費量，並提升整體效率。
Delta Live Tables 監視
系統會為每個 Delta Live Tables 管線建立和維護事件記錄檔。 事件記錄檔包含與管線相關的所有資訊，包括稽核記錄、資料品質檢查、管線進度和資料譜系。 您可以使用事件記錄檔來追蹤、了解及監視資料管線的狀態。
串流監視
串流是擷取和分析最重要的資料處理技術之一。 其會為使用者和開發人員提供低延遲和即時資料處理功能，以進行分析和觸發動作。 Databricks Data Intelligence Platform 可讓您監視結構化串流查詢。
ML 和 AI 監視
監視實際執行工作流程中的模型效能，是 AI 和 ML 模型生命週期的重要層面。 推斷資料表會持續記錄來自 Mosaic AI 模型服務端點的服務要求輸入和回覆 (預測)，並將要求和回覆儲存到 Unity Catalog 中的差異資料表，進而簡化模型的監視和診斷。 然後，您可以使用 Databricks 平台的所有功能 (例如 DBSQL 查詢、筆記本和 Lakehouse Monitoring) 監視、偵錯和最佳化模型。
如需監視模型服務的詳細資料，請參閱監視模型品質和端點健康情況。
安全性監視
成本監視
請參閱成本最佳化 - 監視和控制成本。