共用方式為

成本最佳化的最佳做法

  • 發行項

本文涵蓋支援成本最佳化原則的最佳做法，依原則組織。

1. 選擇最佳資源

使用效能最佳化的儲存格式

若要充分利用 Databricks Data Intelligence Platform，您必須使用 Delta Lake 作為記憶體架構。 它可協助建置更簡單、更可靠的 ETL 管線，並提供許多效能增強功能，相較於使用 Parquet、ORC 和 JSON，可大幅加快工作負載的速度。 請參閱 Azure Databricks 的最佳化建議。 如果工作負載也在工作計算上執行，這會直接導致運算資源的運行時間縮短，進而降低成本。

使用工作計算

工作是在 Databricks 計算執行個體上執行非互動式程式碼的方式。 例如，您能以互動方式或依排程執行擷取、轉換和載入 (ETL) 工作負載。 當然，您也可以在筆記本 UI 中以互動方式執行工作。 不過，在工作計算上，非互動式工作負載的成本會明顯低於全用途計算。 請參閱定價概觀，以比較工作計算和全用途計算。

某些工作的另一個優點是，每個工作或工作流程都可以在新的計算執行個體上執行，將工作負載彼此隔離。 不過，多任務工作流程也可針對所有工作重複使用計算資源，因此每個工作流程只會發生一次計算啟動時間。 請參閱設定工作的計算。

針對 SQL 工作負載使用 SQL 倉儲

對於互動式 SQL 工作負載，Databricks SQL 倉儲是最符合成本效益的引擎。 請參閱定價概觀。 根據預設，所有 SQL 倉儲都會隨附 Photon，以加速您現有的 SQL 和資料框架 API 呼叫，並降低每個工作負載的整體成本。

此外，無伺服器 SQL 倉儲支援智慧型工作負載管理（IWM），這組功能能增強 Databricks SQL 在快速且符合成本效益地處理大量查詢的能力。

針對您的工作負載使用最新的執行階段

Azure Databricks 平台提供針對資料工程任務 (Databricks Runtime) 或機器學習工作最佳化 (適用於機器學習的 Databricks Runtime) 最佳化的不同執行階段。 執行階段的建置是為了為工作提供最佳的程式庫選擇，並確保提供的所有程式庫都處於最新狀態，並且能以最佳方式一起運作。 Databricks Runtime 會定期發行，在主要版本之間提供效能改善。 由於能更有效率地使用計算資源，這些效能改善通常能節省成本。

僅針對正確的工作負載使用 GPU

具有 GPU 的虛擬機器器可以大幅加快深度學習的計算速度，但成本遠高於僅限 CPU 的機器。 僅對具有 GPU 加速程式庫的工作負載使用 GPU 執行個體。

大部分工作負載不會使用 GPU 加速程式庫，因此不會受益於已啟用 GPU 的執行個體。 工作區管理員可限制 GPU 機器和計算資源，以防止不必要的使用。 請參閱部落格文章「GPU 是否真的昂貴？在 Databricks 叢集上進行推斷的效能評定 GPU。」

針對您的工作負載使用無伺服器服務

BI 使用案例

BI 工作負載通常會間歇性地取用數據，並產生多個並發查詢。 例如，使用BI工具的人員可能會更新儀錶板或撰寫查詢，然後直接分析結果，而不需與平台進一步互動。 在此案例中，資料平台：

  • 終止閑置計算資源以節省成本。
  • 當使用者使用 BI 工具要求新的或更新的資料時，可快速提供計算資源。

非無伺服器 Azure Databricks SQL 倉儲的啟動時間為數分鐘，因此許多使用者通常會接受較高的成本，且不會在閑置期間終止。 另一方面，無伺服器 SQL 倉儲可在數秒内啟動並擴大，因此可同時實現即時可用性和閒置終止。 這可帶來絕佳的使用者體驗，並節省整體成本。

此外，無伺服器 SQL 倉儲會比非無伺服器倉儲更早縮小，進而降低成本。

ML 和 AI 模型服務

大部分的模型都可作為 REST API，以整合到您的 Web 或用戶端應用程式中；提供服務的模型會隨著時間接收不同負載的要求，而模型服務平台應一律提供足夠的資源，但只提供實際需要的資源 (向上調整和向下調整)。

Mosaic AI 模型服務使用無伺服器計算，可為部署模型提供高可用性和低延遲的服務。 服務會自動擴大或縮減，以滿足需求變更，降低基礎結構成本，同時最佳化延遲效能。

使用正確的執行個體類型

使用最新一代的雲端執行個體類型幾乎一律會提供效能優點，因為它們可提供最佳效能和最新功能。

根據您的工作負載，選擇正確的實例系列來取得最佳效能/價格比率也很重要。 一些簡易經驗規則包括：

  • 針對 ML、大量隨機播放和溢出工作負載最佳化的記憶體
  • 針對結構化串流工作負載和維護作業（例如優化和清理），優化計算性能。
  • 針對受益於快取的工作負載最佳化儲存體，例如臨機操作和互動式資料分析
  • 針對特定 ML 和 DL 工作負載最佳化的 GPU
  • 缺少特定需求的一般用途

選擇最高效的計算大小

Azure Databricks 會對每個背景工作節點執行一個執行程式。 因此，「執行程式」和「背景工作」詞彙會在 Azure Databricks 架構的內容中交替使用。 人們通常會就背景工作數目方面考量叢集大小，但還有其他重要因素需要考量：

  • 執行程式的內核總數 (計算)：所有執行程式的內核總數。 這決定了計算執行個體的平行處理原則上限。
  • 執行程式總記憶體數：所有執行程式的總 RAM 數量。 這決定了在將資料溢寫至磁碟之前，記憶體中可以儲存的資料量。
  • 執行程式本機儲存體：本機磁碟儲存體的類型和數量。 本機磁碟主要用於在隨機播放和快取期間的溢寫情況。

其他考量包括背景工作角色執行個體類型和大小，這也會影響上述因素。 調整計算大小時，請考慮下列事項：

  • 工作負載將消耗多少資料？
  • 工作負載的計算複雜度如何？
  • 您要從何處讀取資料？
  • 資料在外部儲存體中是如何分割的？
  • 需要多少平行處理原則？

您可以在計算大小考慮下找到詳細資料和範例。

評估效能最佳化的查詢引擎

Photon 是高效能的 Databricks 原生向量化查詢引擎，可加速 SQL 工作負載和 DataFrame API 呼叫 (適用於資料擷取、ETL、串流、資料科學和互動式查詢)。 Photon 與 Apache Spark API 相容，因此開始使用就像開啟它一樣簡單，不需要變更程式碼，也沒有鎖定。

觀察到的加速可能會導致大幅節省成本，因此應評估定期執行的工作，以查看使用 Photon 是否不僅速度更快，而且成本更低。

2. 動態配置資源

使用自動調整計算

透過自動調整，Databricks 會動態地重新配置背景工作角色，以考慮工作的特性。 管線的某些部分可能會比其他部分更密集地計算，且 Databricks 會在工作的這些階段自動新增額外的背景工作角色 (並在不再需要時移除這些背景工作角色)。 相較於靜態大小的計算執行個體，自動調整可降低整體成本。

在縮小結構化串流工作負載的叢集大小時，計算自動調整有其限制。 Databricks 建議針對串流工作負載使用 Delta Live Tables 及 增強型自動調整。

使用自動終止

Azure Databricks 提供數個功能，可藉由減少閑置資源與控制可部署計算資源的時間，協助控制成本。

  • 為所有互動式計算資源設定自動終止。 在指定的閒置時間之後，計算資源會關閉。 請參閱自動終止。
  • 針對只有在上班時間才需要計算的使用案例，計算資源可以設定為自動終止，而排程的程式可以在使用者回到桌面之前，於上午重新啟動計算（並可能在必要時預先提供數據）。 請參閱 CACHE SELECT。
  • 如果計算啟動時間過長，請考慮使用叢集集區，請參閱集區最佳做法。 Azure Databricks 資源池是一組閒置且隨時可用的實例。 使用閒置執行個體建立叢集節點時，會減少叢集啟動和自動調整時間。 如果集區沒有閒置的執行個體，就會藉由從執行個體提供者配置新的執行個體來進行擴充，以因應叢集的要求。

Azure Databricks 不會在集區中的執行個體閑置時向 Databricks 單位 (DBU) 收費，因而節省成本。 執行個體提供者計費確實適用。

使用計算原則來控制成本

計算原則可強制執行許多計算資源的成本特定限制。 請參閱卓越營運 - 使用計算原則。 例如：

3. 監視和控制成本

監視成本

使用 Azure Cost Manager 來分析 Azure Databricks 成本。 計算和工作區標籤也會傳遞至 Azure Cost Manager。 請參閱標記成本屬性的叢集。

標記成本屬性的叢集

若要監視一般成本，並為退款目的，精確地將 Azure Databricks 使用情況劃分到貴組織的營業單位和團隊，您可以標記叢集、SQL 倉儲和集區。 這些標籤會傳播至詳細的 Databricks 單位 (DBU) 和雲端提供者 VM 和 Blob 儲存體使用量，以進行成本分析。

確定在為團隊和使用案例設定工作區和叢集時，會考慮成本控制和屬性。 這樣可簡化標記，並改善成本屬性的正確性。

總成本包括 DBU 虛擬機器、磁碟，以及任何相關聯的網路成本。 對於無伺服器 SQL 倉儲，DBU 成本已經包含虛擬機器和磁碟成本。

Azure Databricks 資源的標記可以在 Azure 入口網站的成本分析工具中使用

實作追蹤和退款成本的可檢視性

使用複雜的技術生態系統時，主動了解未知因素是維護平台穩定性及控制成本的關鍵。 可檢視性可讓您根據系統產生的數據來分析和優化系統。 這與監視不同，監視著重於識別新的模式，而不是追蹤已知問題。

Databricks 提供絕佳的可觀察性功能，使用 系統表 作為由 Databricks 託管的分析儲存庫，存放客戶帳戶的操作數據，這些數據可以在系統目錄中找到。 它們提供帳戶的歷程記錄可檢視性，並在平台遙測中包含方便使用的表格資訊。

請參閱部落格：在 Databricks 上以智慧方式平衡成本最佳化和可靠性

定期共用成本報告

產生每月成本報告，以追蹤耗用量成長和異常狀況。 使用叢集標記，按使用案例或團隊，與擁有工作負載的團隊共用這些報告。 這可消除意外狀況，並允許小組在成本過高時主動調整其工作負載。

監視和管理 Delta Sharing 輸出成本

與其他資料共用平台不同，差異共用不需要資料複寫。 此模型有許多優點，但這意味著當跨雲端或跨區域共用資料時，你的雲端廠商可能會收取資料輸出費用。 請參閱 監視和管理差異共享輸出成本（適用於提供者），以監視和管理輸出費用。

4. 設計符合成本效益的工作負載

平衡一律開啟和觸發的串流

傳統上，當人們想到串流時，會想到「即時」、「24/7」或「永遠在線」等詞彙。 如果資料擷取即時發生，基礎計算資源必須全天候執行，每天每小時都產生成本。

不過，並非所有依賴連續事件串流的使用案例，都需要將這些事件立即新增至分析數據集。 如果使用案例的商務需求只需要每小時或每天的全新資料，則該需求每天只能執行幾次，進而大幅降低工作負載成本。 Databricks 建議對於沒有低延遲需求的增量工作負載，搭配 AvailableNow 觸發程式使用結構化串流。 請參閱設定累加批次處理。

隨選與容量過剩執行個體之間的平衡

現成執行個體可利用雲端以較低價格提供的過剩虛擬機器資源。 為了節省成本，Azure Databricks 支援使用現成執行個體建立叢集。 Databricks 建議第一個執行個體 (Spark 驅動程式) 一律為隨選虛擬機器。 現成實例是工作負載的絕佳選擇，因為雲端提供者已收回一或多個現成實例，因此可以接受較長的時間。