azure-databricks-cluster-usage-management

Overview

定義計算資源（集羣、作業和池），並確定用於不同工作負載的資源。
描述幾個用例的集羣資源調配策略，以最大限度地提高可用性和成本效益。
描述集羣治理的最佳實踐，包括集羣策略。
描述Azure Databricks的容量限制。
描述如何管理成本和執行按存儲容量使用計費分析。

計算資源/Computation Resources

cluster

集羣是一組虛擬機，您可以在其上運行數據工程、數據科學和數據分析工作負載，如生產ETL管道、流式分析、特殊分析和機器學習。集羣允許您將一組計算機（工作節點）視爲由驅動程序節點編排的單個計算機。

cluster manager

您可以使用Clusters UI、CLI或REST API創建集羣。控制平面（在Microsoft管理的Azure訂閱中）中的羣集管理器將爲您的羣集請求虛擬機，並在數據平面（在客戶管理的Azure預訂中）中啓動它們。創建集羣后，可以通過連接筆記本和執行命令來使用它運行交互式工作負載。

job

除了交互式工作負載之外，您還可以通過作業在集羣上運行自動化工作負載。作業是立即或按計劃運行筆記本或JAR的一種方式。您可以使用作業UI、CLI或API管理和監視作業。

Cluster Types

Azure Databricks區分了通用集羣和作業集羣。當您使用Clusters UI、CLI或API創建集羣時，您將創建一個通用集羣，該集羣可用於與筆記本交互運行工作負載。創建作業時，可以選擇使用現有的通用集羣，或創建新的作業集羣。作業集羣是短暫的；它們是爲作業創建的，並在完成時終止，這與通用集羣不同，通用集羣是持久的，可以手動重新啓動。多個用戶之間可以共享通用集羣，以進行協作交互分析。作業集羣允許您運行快速、健壯的自動化作業，並進行隔離和定時運行。隨着計算成本顯著降低，作業集羣非常適合生產和重複工作負載。通用集羣非常適合分析和特殊工作。

Pool

您可以選擇配置羣集以從池中提取虛擬機。池是一組空閒的、隨時可用的實例，允許您減少集羣啓動和自動縮放時間。當連接到池的集羣需要實例時，它首先嚐試分配池的一個空閒實例。如果池沒有空閒實例，則通過從實例提供程序分配新實例來擴展池，以適應集羣的請求。當一個集羣釋放一個實例時，它將返回到池中，並可供另一個集羣使用。只有連接到池的集羣才能使用該池的空閒實例。您可以使用池UI、CLI和API管理池。

將集羣連接到池可以節省實例獲取時間，這對於有許多庫和依賴項安裝的集羣來說可能是啓動就要相當長的時間。如果沒有池，一些短時間的作業可能會比運行實際工作負載浪費更多的時間，因爲大部分都消耗在獲取、啓動集羣這個過程。儘管Azure Databricks不向閒置實例的DBU收費，但實例的雲提供商成本仍然適用。可以在池中配置限制以管理成本。我們將在下一節中進一步討論。

集羣配置/Cluster Configurations

Custer mode

配置羣集時，可以從三種羣集模式中進行選擇。

首先是標準集羣，建議單個用戶使用。第二個是高併發集羣，它是一個託管雲資源，可以在多個用戶之間共享，具有公平的調度和隔離的筆記本環境。高併發集羣的主要好處是，它們提供了Spark本機細粒度共享，以實現最大的資源利用率和最小的查詢延遲。爲多個用戶配置一個集羣也比爲每個用戶配置集羣更容易。單節點集羣沒有工作線程，並在驅動程序節點上運行Spark作業。相比之下，標準模式集羣除了驅動程序節點之外，還需要至少一個Spark工作節點來執行Spark作業。

comparison

下面是三種集羣模式的詳細比較。建議爲單個用戶使用標準和單節點集羣，而高併發集羣是多個用戶的理想選擇。高併發集羣的性能和安全性是通過在單獨的進程中運行用戶代碼來實現的。這不是用於Scala。因此，高併發集羣只適用於SQL、Python和R，標準和單節點集羣除了Scala之外還可以運行這些語言。只有高併發集羣支持Python和SQL表訪問控制。這通常與憑據傳遞一起使用，它允許您使用用於登錄Azure Databricks的身份從Azure Databrick羣集自動向blob存儲或ADLS進行身份驗證。在標準和單節點羣集上，憑據傳遞限制單個用戶使用。在高併發集羣上，憑證傳遞僅允許您運行Python和SQL命令。正如我們前面提到的，高併發集羣爲併發用戶的性能和安全性提供了進程隔離。

use cases

下面是每個集羣模式的一些用例。標準集羣通常用於生產批處理或流式ETL或ML作業，其中高併發集羣用於交互式分析或商業智能。根據工作負載的不同，兩者都可以用於特殊開發。標準集羣的用戶通常是數據工程師和數據科學家，而高併發集羣的用戶則通常是數據分析師。管理和財務部門的用戶也可以使用高併發集羣來快速洞察。數據分析師或數據科學家可以使用單節點集羣進行輕量級探索性數據分析或單節點機器學習工作負載。

Guardrails for High Concurrency Clusters

有幾個過程可以幫助集羣在許多併發用戶中保持其性能。首先是查詢監視器。大型查詢可能會非常緩慢，使集羣資源飽和，並使其他人難以共享同一個集羣。查詢監視器是一個過程，它通過檢查大型查詢的最常見原因並終止超過閾值的查詢，防止查詢獨佔集羣資源。這對於使用UI創建的所有通用集羣都是啓用的。應爲SQL分析師和數據科學家共享給定集羣的特殊分析集羣啓用查詢監視器，管理員需要確保查詢彼此“良好”。通常，我們不建議急於取消ETL場景中使用的查詢，因爲通常沒有人在循環中糾正錯誤。我們建議您禁用除臨時分析羣集之外的所有羣集的查詢監視器。另一個有用的過程是任務搶佔。Azure Databricks中的Apache Spark調度程序自動搶佔任務以強制公平共享。這保證了具有許多併發運行作業的集羣上的交互式響應時間。 Spark配置屬性可用於根據您的需要調整這些流程。

Cost Control with Pools

我們之前看到，在池中保持空閒VM實例對性能很好，但不是免費的。Azure Databricks不會對集羣未使用的閒置實例收取DBU費用，但這些實例的雲提供商成本卻需要。有幾種推薦的方法可以配置您的池，以在滿足您的需求的同時最大限度地降低成本。

如果您只在工作時間運行交互式工作負載，請確保池的“Min Idle”實例計數在下班後設置爲零。或者，如果您的自動數據管道在夜間運行了幾個小時，請在管道啓動前幾分鐘設置“最小空閒”計數，然後將其恢復爲零。或者，始終保持“最小空閒”爲零，但設置“空閒實例自動終止”超過你需要運行的作業時間，以滿足您的需要。池中運行的第一個作業將緩慢啓動，但在超時時間段內運行的後續作業將快速啓動。作業完成後，池中的所有實例都將在空閒超時期後終止，從而避免了雲提供商的成本。此外，還可以通過設置池的最大容量來預算VM資源。這限制了所有空閒實例和連接到池的集羣使用的實例的總和。

Databricks Runtime

Databricks運行時是在集羣上運行的一組核心組件。所有Databricks運行時都包含ApacheSpark，並添加了可提高可用性、性能和安全性的組件和更新。建議您查看最新的Databricks Runtime發佈功能，並將集羣遷移到最新版本，其中通常包括性能和穩定性修復以及新功能。

Types

當您創建或編輯集羣時，Databricks在DatabricksRuntime Version下拉列表中提供了幾種類型的運行時和這些運行時類型的幾種版本。 Databricks Runtime包括Apache Spark，但也添加了大量組件和更新，大大提高了大數據分析的可用性、性能和安全性。DatabricksRuntime ML是Databricks Runtime的變體，它添加了多個流行的機器學習庫，包括TensorFlow、Keras、PyTorch和XGBoost。Databricks Runtime for Genomics是爲處理基因組和生物醫學數據而優化的DatabricksRuntime的變體。DatabricksLight爲不需要DatabricksRuntime提供的高級性能、可靠性或自動縮放優勢的作業提供了運行時選項。

Autoscaling

自動添加和刪除工作節點，以響應不斷變化的工作負載，優化資源使用。啓用自動縮放後，Databricks會自動選擇運行Spark作業所需的適當數量的工作節點。自動縮放使實現高集羣利用率變得更容易，因爲您無需擔心集羣的精確配置以匹配工作負載。這可以提供兩個優點：

（1）與運行恆定大小且配置不足的集羣相比，工作負載運行速度更快。

（2）與靜態大小的集羣相比，您可以降低總體成本。啓用自動縮放時，可以指定集羣中節點的最小和最大數量。爲工作節點設置這個範圍需要一些實驗。臨時使用或業務分析通常會有很大的差異。對於生產批處理作業，可以關閉自動縮放或在上限上添加buffer。不要對流式工作負載使用自動縮放。結構化流上自動縮放的默認行爲是集羣將始終縮放到最大節點數。建議的最佳做法是禁用結構化流工作負載的自動縮放，並將其作爲Databricks作業在新作業集羣上運行，並進行無限次重試。

Auto Termination

在創建羣集期間，您可以指定一個非活動時間段（以分鐘爲單位），在該時間段之後，您希望羣集終止。如果當前時間與集羣上上次運行的命令之間的差異超過指定的非活動時間，Databricks將自動終止該集羣。建議爲ad-hoc集羣啓用自動終止，以防止空閒集羣在夜間或週末運行。自動終止設置的默認值取決於您選擇創建標準集羣還是高併發集羣。標準集羣配置爲在120分鐘後自動終止。高併發集羣配置爲不自動終止。

Instance Types

可用的機器類型列表可能令人望而生畏。爲了簡化這一點，Azure Databricks自動將機器類型組織到適當的工作負載類型組中，併爲每個工作負載類型推送最常用的機器類型。您還可以使用Pricing Calculator選擇特定的工作負載類型和節點數量，以查看估計的DBU成本。對於內存密集型應用程序，建議使用內存優化的實例類型。例如，如果機器學習工作負載在內存中緩存了大量數據。計算優化的實例類型對結構化流式應用程序很有幫助，因爲您需要確保在一天的高峯時間處理速率高於輸入速率。這些也可用於分佈式分析和數據科學應用。對於需要更高磁盤吞吐量和IO的用例，建議使用存儲優化的實例類型。對於企業級應用程序、關係數據庫和具有內存緩存的分析，建議使用通用實例類型。

Spot VMs (Private Preview)

VM實例有兩層：按需和現貨。對於按需實例，您可以按秒支付計算容量，無需長期承諾。目前在私人預覽中，現貨實例允許您使用備用Azure VM計算能力，並選擇您願意支付的最高價格。基於Azure計算能力的供需情況，實時改變現貨價格。如果當前現貨市場價格高於最高現貨價格，則終止現貨實例。由於與按需定價相比，現貨實例通常以折扣價提供，因此在相同的預算下，您可以顯著降低運行應用程序的成本，增加應用程序的計算能力，並提高吞吐量。集羣可以使用按需和現貨實例的組合來創建（具有自定義現貨價格），允許您根據您的用例定製集羣。我們建議啓動集羣，使Spark驅動程序位於按需實例上，這樣即使在丟失點實例節點後也可以保存集羣的狀態。如果您選擇使用所有現貨實例（包括驅動程序），當您由於現貨市場的變化而丟失驅動程序實例時，任何緩存的數據或表都將被刪除。

根據SLA，儘可能利用現貨定價。對於非任務關鍵型作業，爲worker使用現場虛擬機，爲驅動程序使用按需虛擬機。對於具有嚴格SLA的工作流，請使用回退到按需的現貨實例。如果您運行的是混合集羣（即按需和現貨實例的混合），並且如果現貨實例獲取失敗或您丟失現貨實例，Azure Databricks將恢復使用按需實例，併爲您提供所需的容量，則此Spot將恢復爲按需功能。如果沒有此選項，您將失去羣集的點實例提供的容量，從而導致工作負載延遲或失敗。對於生產作業，請使用所有按需實例。

Cluster Sizing Starting Points

Rules of Thumb

以下是集羣規模調整的幾個起點。爲了減少網絡混亂，通常首選較少的大實例而不是較多的小實例。這主要適用於批處理ETL作業；對於流，可以根據轉換的複雜性從較小的實例開始。這不是板上釘釘的——相反的做法在很多情況下都是有意義的，所以尺寸很重要。您可以根據最初的任務數量調整大小，然後再進行調整。使用一個小集羣運行該作業，以瞭解任務的數量，並使用每個核心2-3x個任務進行基本大小調整。根據工作量進行選擇。

Workloads requiring caching

如果工作負載需要緩存，請查看Spark UI中的存儲選項卡，以查看是否緩存了整個訓練數據集。如果它被完全緩存並有空餘空間，則可以使用更少的實例。如果它幾乎完全緩存，則可以增加集羣大小。如果它甚至不接近緩存，請考慮內存優化的實例。檢查persistent是否爲MEMORY_ONLY或MEMORY_AND_DISK。SSD溢出到磁盤並不是那麼糟糕。如果這還不夠，請轉到下一節。

ETL and Analytics Workloads

首先，通過Ganglia指標查看CPU使用情況，檢查我們是否受到計算限制。唯一加快速度的方法是添加更多的內核。接下來，檢查我們是否已綁定到網絡。在計算繁重步驟之前，檢查是否存在高峯值。使用更大和更少的機器來減少洗牌。使用SSD支持的實例實現更快的遠程讀取。最後，檢查我們是否溢寫。檢查Spark SQL選項卡是否溢出（常見的溢出是在混洗之前進行預聚合）。使用內存優化實例解決此問題。

Additional Cluster Management Best Practices

定期重新啓動長時間運行的集羣-某些集羣作爲一個交互式集羣全天候運行。建議定期重新啓動這些程序以獲取新的修補程序。
將未使用的筆記本從集羣中分離-將筆記本連接到集羣會消耗每個REPL（每個筆記本使用的語言）的一定內存量。

集羣治理/Cluster Governance

集羣治理最佳實踐

對於集羣治理，您可以通過授予用戶“可以重新啓動”或“可以連接到”權限來鎖定集羣配置，而不是授予集羣創建和管理權限。對於那些希望授予集羣創建權限的用戶，可以使用集羣策略在集羣配置中強制執行規則。

羣集策略

作爲管理員，您可以配置羣集策略以限制可用於創建羣集的屬性或屬性值。然後，用戶可以從羣集配置頁面上的策略下拉列表中選擇羣集策略。您可以配置將羣集策略限制爲特定用戶和組的ACL。羣集策略允許您：

（1）限制用戶使用指定的設置創建羣集。

（2）通過修復和隱藏一些值來簡化用戶界面，以使更多用戶能夠創建他們的集羣。

（3）通過限制每個集羣的最大成本來控制成本（例如，通過對其值有助於每小時價格的屬性設置限制）。例如，這裏有一個策略，允許用戶以最小的配置創建一箇中型集羣。創建時唯一需要的字段是集羣名稱；其餘的是固定的和隱藏的，正如你在右邊看到的。左邊是該策略的JSON配置-這是管理員將配置的地方，右邊是最終用戶將看到的內容。只有管理員用戶才能創建、編輯和刪除羣集策略。管理員用戶也可以訪問所有策略。

羣集策略-好處

集羣策略提供了三個好處：

（1）控制成本-例如，防止個人以高worker數量運行不必要的大型集羣，強制實施特定配置以節省成本，例如自動終止。

（2）改進治理-例如，強制使用集羣標籤來跟蹤團隊或項目的使用情況，控制哪些用戶或組能夠使用更大的集羣，並可能將其與內部審批流程相關聯。

（3）將中斷降至最低-從第一天起就設置正確的限制，以避免更多用戶加入時出現問題。

羣集策略-應用程序

下面是一些您可能希望使用策略的示例。對於不同的工作負載，可以使用不同的集羣大小。您還可以確保所有用戶或業務部門都有一個標準運行時，這在解決問題時非常重要。如果您知道所有用戶或組都在使用特定版本的運行時，那麼它可以使再現性變得更容易。您可以擁有經過認證的超級用戶，因爲某些用戶有內部審批流程，可以訪問更不受限制的策略。您還可以爲作業和交互式工作負載制定不同的策略。當您想要限制用戶可以調度作業的集羣類型時，這一點就發揮了作用。例如，如果我不希望我的用戶能夠針對通用或交互式集羣調度作業，我可以設置一個策略，只允許使用臨時或作業集羣。

羣集策略-用例

以下是集羣策略的兩個潛在用例。數據科學策略可能具有可選的自動縮放功能，所需的自動終止時間爲120分鐘。數據分析策略可能允許用戶根據查詢要求從預定義的一組“T恤尺寸”中進行選擇，以確定集羣的大小。它還可以強制自動終止並具有共享池訪問權。

容量限制/Capacity Limits

在本課中，我們將確定Databricks中功能的重要容量限制，包括API網關、作業服務、羣集管理器和Azure計算/網絡限制。請注意，以下規定的限制不得解釋爲可用性保證；任何超過這些限制的嘗試都可能導致停機，並且在SLA中不會算作“停機”。

API Gateway Limits

所有API調用中每個工作區總計30個API/秒；未使用的容量將緩存最多500個API調用。這個限制是爲了防止錯誤配置的API客戶端佔用太多資源。達到極限後，將返回429錯誤代碼。可以在等待至少一秒鐘後嘗試進一步的呼叫。特定API可能具有較低的單個調用速率。例如，雖然一個工作區可能每秒允許30個API調用，但任何給定的API都可能有10個API/秒的限制（並且您可以同時使用三個這樣的API）。

Jobs Service Limits

我們設置了以下限制，以確保在當前容量和架構的情況下始終能夠保證工作可用性：每個工作區1000次併發運行每個工作區每小時創建5000個工作當超過這些限制時，用戶將收到429個響應代碼，需要重試其請求

P.S.好像跟azure CN得文檔上有些差異，還是以文檔的爲準吧：https://learn.microsoft.com/zh-cn/azure/databricks/resources/limits

Cluster Manager Limits

To prevent abuse, CM family of services imposes:

An upsize throttling limit of 100 VMs acquisitions/min per workspace; unused capacity will cache with a maximum of 1000 VM acquisitions. Excess requests will be queued.

An upsize throttling limit of 1800 VMs acquisitions-in-progress per control plane. Excess results will be queued for up to 20 minutes.

Azure Network Resource Provider (NRP) has as of the date of this document a throughput limit of 50 concurrent write operations (i.e., create or delete)

由於刪除與相同配額的創建相沖突，因此集羣的生存期對我們可以同時啓動多少集羣和實例起着重要作用，建議的使用模式變得無法估計。此外，由於每個訂閱都有限制，因此同一訂閱上的任何其他創建/刪除（例如其他Databricks工作區、AKS集羣等）都將爭奪相同的配額。

以下是如何針對不同場景解釋這一點的指導：對於單個大型集羣創建，不要超過200個節點。由於我們在集羣創建過程中錯開（而不是跨集羣），因此不要同時創建40箇中等大小的集羣（即最多40個節點）。客戶帳戶中限制的節點數，按以下順序排列：每個地區每個訂閱的最大虛擬機數-25k 工作區中的最大VM數-由子網大小確定最大虛擬機數將由配額限制： VM配額由VM系列提供-配額除以給定實例類型所需的vCPU數量。 PublicIP配額-每個VM一個。

高衝擊工作負荷

如果您需要比Azure允許的更快地創建/刪除羣集，您可以使用實例池來避免某些限制。

Azure計算/網絡限制

一些Microsoft CRP/NRP限制。請注意，限制是每個訂閱，因此添加更多訂閱將增加規模。

成本管理/Cost Management

Azure Databricks Costs

DBU Costs

Azure Databricks按DatabricksUnit（DBU）（每小時處理能力的一個單位）收取使用費。DBU在Databricks集羣啓動時收取費用（可能有部分DBU成本）。儘管計算實例的Azure成本仍然適用，但閒置池實例不收取DBU費用。例如，如果您創建了一個具有一個驅動程序節點和3個DS3_v2類型的工作節點的集羣，並運行該集羣2小時，則可以按如下方式計算DBU：總實例小時數=節點總數× 小時數=（1+3）× 2=8個DBU。總成本包括8個DBU的成本，以及DS3_v2實例的8個實例小時的Azure成本。

Infrastructure Costs

除了DBU成本，還有Azure Databricks基礎設施的成本。

爲每個工作區創建的DBFS根管理存儲的Blob存儲成本
羣集中用於運行工作負載的實例的Azure VM成本
連接到每個工作節點的磁盤的Azure託管磁盤成本，包括連接到每個VM的30GB實例根磁盤和連接到每個虛擬機中Databricks Runtime容器的150GB數據磁盤
公共IP地址成本，因爲羣集VM每個都有一個動態公共IP地址，除非客戶使用無公共IP功能
從與服務遙測、spark和審計日誌相關的出口費用到Databricks存儲和事件中心端點的網絡帶寬成本（如果控制平面不在同一區域）
與提供診斷/審計日誌相關的可選存儲、事件中心和日誌分析成本

Resource Groups

有兩個資源組與每個Azure Databricks工作區關聯，即用戶標識的資源組和自動生成的託管資源組。Azure Databricks工作區部署在用戶標識的資源組中。所有基礎結構資源都在託管資源組中創建。此資源組的命名約定爲：“databricks rg-”+用戶指定的資源組+“ws”+隨機字符(azure CN的看了沒有ws標識，可能是global的？)

Cost Analysis

Cost Report

轉到Azure門戶中的成本管理+計費以查看成本分析。

Cost Export

您可以在SKU級別按DBU獲取細分，以在數據基礎上構建自定義報告解決方案。雖然有一個選項可以與成本分析相反，但Azure通過CSV成本導出和本地計費API（僅適用於企業協議客戶）提供了專門的方法。

Pre Purchase Plan (P3)

Azure Databricks預購計劃（P3）允許組織預購DBU，並提供額外好處，包括批量折扣、服務積分、培訓積分、Slack支持和SCP考慮。您可以購買與資源組、訂閱或企業協議相關的P3。在企業協議範圍內購買是最佳做法。這使組織能夠在訂閱中共享Azure Databricks消費，以換取更高的折扣。使用按存儲容量使用計費模型，組織可以隨後對每個訂閱的確切使用情況進行收費。

Cost Report for P3

由於P3是預付款，實際成本報告將顯示$0。要獲取P3提取的信息，請在成本分析中選擇攤銷成本。

Chargebacks

爲了進行有效的按存儲容量使用計費分析，請爲不同的部門/團隊創建單獨的工作區，併爲部門/團隊中的每個項目/計劃創建單獨的集羣。爲每個工作區和項目關聯適當的工作區和集羣標籤，然後利用策略確保標籤的一致應用（工作區標籤的Azure策略，集羣標籤的Databricks集羣策略）。這將允許您按工作區和集羣標籤監視和報告按存儲容量使用計費。

Budget & Cost Monitoring

您可以通過Azure成本中心中的工作區和集羣標記定義預算，以及爲預算閾值創建操作組。例如，您可以配置操作以在達到預算的80%時發送電子郵件，或在達到預算100%時調用Azure功能終止羣集。