最佳實踐:集群配置
當您創建和配置集群時，Databricks提供了許多選項，以幫助您以最低的成本獲得最佳性能。然而，當您試圖為工作負載確定最佳配置時，這種靈活性會帶來挑戰。仔細考慮用戶將如何利用集群將有助於在創建新集群或配置現有集群時指導配置選項。在確定配置選項時需要考慮的一些事情是:
什麼類型的用戶將使用集群?數據科學家的工作類型可能與數據工程師或數據分析師的要求不同。
用戶將在集群上運行什麼類型的工作負載?例如，批提取、轉換和加載(ETL)作業可能與分析工作負載有不同的需求。
您需要滿足什麼級別的服務水平協議(SLA) ?
你的預算有什麼限製?
本文基於這些考慮提供了針對不同場景的集群配置建議。本文還討論了Databricks集群的特定特性，以及針對這些特性需要注意的事項。
您的配置決策將需要在成本和性能之間進行權衡。集群的主要成本包括集群消耗的數據單元(Databricks Units, DBUs)和運行集群所需的底層資源的成本。可能不太明顯的是次要成本，例如不符合SLA的業務成本、員工效率的降低，或者由於控製不當可能造成的資源浪費。
集群功能
在討論更詳細的集群配置場景之前，了解Databricks集群的一些特性以及如何最好地使用這些特性是很重要的。
通用集群和作業集群
當你創建集群您可以選擇集群類型:通用集群或作業集群。通用集群可以由多個用戶共享，最適合執行特別分析、數據探索或開發。完成處理的實現並準備好操作代碼之後，切換到在作業集群上運行它。作業集群在作業結束時終止，從而減少資源使用和成本。
集群模式
Databricks支持三種集群模式:標準、高並發、單節點。大多數常規用戶使用標準或單節點集群。
警告
標準模式集群(有時稱為無隔離共享集群)可以由多個用戶共享，用戶之間沒有隔離。如果使用“高並發”集群模式沒有表acl，與標準模式集群使用相同的設置。帳戶管理員可以防止為Databricks工作空間管理員自動生成內部憑證在這些類型的集群上。對於更安全的選項，Databricks建議使用具有表acl的高並發集群。
建議僅對單個用戶使用標準集群。標準集群可以運行用Python、SQL、R和Scala開發的工作負載。
單節點集群適用於使用少量數據或非分布式工作負載的作業，如單節點機器學習庫。
高並發集群非常適合需要共享資源或運行臨時作業的用戶組。管理員通常創建高並發集群。Databricks建議對高並發集群啟用自動伸縮。
自動定量
自動定量允許集群根據工作負載自動調整大小。從成本和性能的角度來看，自動伸縮可以使許多用例和場景受益，但是理解何時以及如何使用自動伸縮可能具有挑戰性。以下是決定是否使用自動縮放以及如何獲得最大效益的一些考慮因素:
與固定大小的集群相比，自動伸縮通常可以降低成本。
與配置不足的固定大小集群相比，自動伸縮工作負載可以更快地運行。
一些工作負載與自動伸縮集群不兼容，包括spark-submit作業和一些Python包。
對於單用戶通用集群，當最小工作人員數量設置過低時，用戶可能會發現自動伸縮減慢了他們的開發或分析速度。這是因為它們正在運行的命令或查詢通常相隔幾分鍾，在這段時間內集群處於空閑狀態，可以縮小以節省成本。當執行下一個命令時，集群管理器將嚐試擴展，從雲提供程序檢索實例時將花費幾分鍾時間。在此期間，作業可能在資源不足的情況下運行，從而減慢檢索結果的時間。雖然提高最低工人數量有所幫助，但也會增加成本。這是另一個需要平衡成本和性能的例子。
如果三角洲緩存時，重要的是要記住，如果節點終止，則該節點上的任何緩存數據都將丟失。如果保留緩存的數據對您的工作負載很重要，可以考慮使用固定大小的集群。
如果您有一個運行ETL工作負載的作業集群，如果您知道您的作業不太可能改變，那麼有時可以在調優時適當地調整集群的大小。但是，如果數據大小增加，自動縮放將為您提供靈活性。另外值得注意的是，如果集群在很長一段時間內未得到充分利用或等待另一個進程的結果，那麼優化的自動伸縮可以減少長時間運行的作業的開銷。但是，當集群試圖適當地擴展時，您的作業可能會再次遇到輕微的延遲。如果某個作業有嚴格的sla，那麼固定大小的集群可能是更好的選擇，或者考慮使用Databricks池減少集群啟動時間。
池
池通過維護一組可用的、隨時可用的實例，減少集群啟動和擴展時間。Databricks建議利用池來縮短處理時間，同時最大限度地降低成本。
Databricks運行時版本
Databricks建議通用集群使用最新的Databricks Runtime版本。使用最新版本將確保您的代碼和預加載包之間具有最新的優化和最新的兼容性。
對於運行操作工作負載的作業集群，請考慮使用長期支持(LTS) Databricks運行時版本。使用LTS版本將確保您不會遇到兼容性問題，並且可以在升級之前徹底測試您的工作負載。如果你有一個關於機器學習的高級用例，可以考慮專門的Databricks Runtime版本。
集群政策
磚集群政策允許管理員對集群的創建和配置實施控製。Databricks建議使用集群策略來幫助應用本指南中討論的建議。有關集群策略的詳細信息，請參見集群策略最佳實踐指南．
自動終止
許多用戶在使用完集群後不會考慮終止集群。幸運的是，集群會在設定的時間段後自動終止，默認為120分鍾。
管理員可以在創建集群策略時更改此默認設置。減少這個設置可以減少集群空閑的時間，從而降低成本。重要的是要記住，當集群終止時，所有狀態都將丟失，包括所有變量、臨時表、緩存、函數、對象等等。當集群再次啟動時，需要恢複所有這些狀態。如果開發人員出去午休30分鍾，那麼花同樣多的時間讓筆記本電腦恢複到原來的狀態是一種浪費。
重要的
空閑集群在終止前的非活動期間繼續累積DBU和雲實例費用。
垃圾收集
盡管這一點可能不像本文中討論的其他考慮因素那麼明顯，但關注垃圾收集可以幫助優化集群上的工作性能。提供大量RAM可以幫助作業更有效地執行，但也可能導致垃圾收集期間的延遲。
要最小化長時間垃圾收集清理的影響，請避免部署為每個實例配置大量RAM的集群。將更多的RAM分配給執行程序將導致更長的垃圾收集時間。相反，使用更小的RAM大小配置實例，如果作業需要更多內存，則部署更多實例。然而，在某些情況下，建議使用更少的節點和更多的RAM，例如，需要大量shuffle的工作負載，如中所討論的集群大小調整注意事項．
集群大小調整注意事項
Databricks為每個工作節點運行一個執行程序。因此，術語executor和worker在Databricks體係結構上下文中可以互換使用。人們通常根據工作者的數量來考慮集群的大小，但是還有其他重要的因素需要考慮:
執行程序內核總數(compute):所有執行程序的內核總數。這決定了集群的最大並行度。
執行程序總內存:所有執行程序的RAM總量。這決定了在將數據溢出到磁盤之前可以在內存中存儲多少數據。
Executor本地存儲:本地磁盤存儲的類型和數量。本地磁盤主要用於shuffle和緩存期間溢出的情況。
其他需要考慮的因素包括工作實例類型和大小，它們也會影響上述因素。在調整集群大小時，請考慮:
您的工作負載將消耗多少數據?
你的工作負載的計算複雜度是多少?
從哪裏讀取數據?
如何在外部存儲器中對數據進行分區?
你需要多少並行度?
回答這些問題將幫助您根據工作負載確定最佳集群配置。對於隻使用窄轉換(每個輸入分區隻對一個輸出分區有貢獻的轉換)的簡單ETL風格的工作負載，請關注計算優化配置。如果您預計會出現大量的洗牌，那麼內存的數量就很重要，存儲空間也很重要，以解決數據溢出的問題。較少的大實例可以減少在機器之間傳輸數據時的網絡I/O。
在worker實例類型的大小和worker實例類型的數量之間有一個平衡。一個有兩個工作集群(每個工作集群有40個核心和100 GB RAM)的集群與一個有8個工作集群(有10個核心和25 GB RAM)的集群具有相同的計算和內存。
如果您希望對相同的數據進行多次重讀，那麼您的工作負載可能會受益於緩存。考慮使用Delta Cache進行存儲優化配置。
集群大小調整示例
下麵的示例顯示了基於特定類型工作負載的集群建議。這些示例還包括要避免的配置，以及為什麼這些配置不適合工作負載類型。
數據分析
數據分析師通常執行需要來自多個分區的數據的處理，導致許多shuffle操作。具有較少節點的集群可以減少執行這些洗牌所需的網絡和磁盤I/O。下圖中的集群A可能是最佳選擇，特別是對於支持單個分析師的集群。
集群D可能會提供最差的性能，因為大量的節點和更少的內存和存儲將需要更多的數據變換來完成處理。
分析工作負載可能需要重複讀取相同的數據，因此推薦的worker類型是啟用Delta Cache的存儲優化。
為分析工作負載推薦的其他功能包括:
啟用自動終止以確保集群在一段時間不活動後終止。
考慮基於分析師的典型工作負載啟用自動伸縮。
考慮使用池，這將允許將集群限製為預先批準的實例類型，並確保一致的集群配置。
可能沒有用處的特性:
存儲自動伸縮，因為這個用戶可能不會產生很多數據。
High Concurrency集群，因為這個集群是針對單個用戶的，而High Concurrency集群最適合共享使用。
基本批量ETL
不需要廣泛轉換的簡單批處理ETL作業，例如連接或聚合，通常受益於計算優化的集群。對於這些類型的工作負載，下圖中的任何集群都可能是可接受的。
建議使用計算優化的工作類型;這些將更便宜，而且這些工作負載可能不需要大量內存或存儲。
使用池可以減少集群啟動時間，減少運行作業管道時的總運行時間，從而為支持簡單ETL作業的集群提供好處。但是，由於這些類型的工作負載通常作為調度作業運行，其中集群隻運行足夠長的時間來完成作業，因此使用池可能不會帶來好處。
以下功能可能沒什麼用:
Delta Caching，因為不需要重新讀取數據。
可能不需要自動終止，因為這些可能是預定的作業。
不建議自動伸縮，因為應該為用例預先配置計算和存儲。
高並發集群適用於多用戶，對運行單個作業的集群沒有好處。
複雜批處理ETL
更複雜的ETL作業，例如需要跨多個表進行聯合和連接的處理，在您可以將打亂的數據量最小化時，可能工作得最好。由於減少集群中的工作人員數量將有助於最大限度地減少洗牌，因此您應該考慮使用較小的集群(如下圖中的集群a)而不是較大的集群(如集群D)。
複雜的轉換可能是計算密集型的，因此對於某些工作負載來說，要達到最佳核數可能需要向集群添加額外的節點。
與簡單的ETL作業一樣，建議使用計算優化的工作類型;這些將更便宜，而且這些工作負載可能不需要大量內存或存儲。同樣，與簡單的ETL作業一樣，需要考慮的主要集群特性是在運行作業管道時減少集群啟動時間和總運行時間的池。
以下功能可能沒什麼用:
Delta Caching，因為不需要重新讀取數據。
可能不需要自動終止，因為這些可能是預定的作業。
不建議自動伸縮，因為應該為用例預先配置計算和存儲。
高並發集群適用於多用戶，對運行單個作業的集群沒有好處。
訓練機器學習模型
由於訓練機器學習模型的初始迭代通常是實驗性的，因此較小的集群(如集群a)是一個不錯的選擇。較小的集群也將減少洗牌的影響。
如果需要考慮穩定性，或者對於更高級的階段，較大的集群(如集群B或C)可能是一個不錯的選擇。
不建議使用像集群D這樣的大型集群，因為在節點之間轉移數據的開銷很大。
推薦的worker類型經過了存儲優化，啟用了Delta Caching，以考慮相同數據的重複讀取，並啟用訓練數據的緩存。如果存儲優化節點提供的計算和存儲選項不足，可考慮GPU優化節點。一個可能的缺點是這些節點缺乏Delta Caching支持。
為分析工作負載推薦的其他功能包括:
啟用自動終止以確保集群在一段時間不活動後終止。
考慮基於分析師的典型工作負載啟用自動伸縮。
使用池，這將允許將集群限製為預先批準的實例類型，並確保一致的集群配置。
可能沒有用處的特性:
自動伸縮，因為當集群縮小時刪除節點時，緩存的數據可能會丟失。此外，典型的機器學習作業通常會消耗所有可用的節點，在這種情況下，自動伸縮將沒有任何好處。
存儲自動伸縮，因為這個用戶可能不會產生很多數據。
High Concurrency集群，因為這個集群是針對單個用戶的，而High Concurrency集群最適合共享使用。
常見的場景
以下部分提供了針對常見集群使用模式配置集群的其他建議:
多個用戶運行數據分析和臨時處理。
專門的用例，如機器學習。
支持定時批處理作業。
多用戶群
場景
您需要為多個用戶提供對數據的訪問，以便運行數據分析和特別查詢。集群的使用可能會隨著時間的推移而波動，並且大多數作業不是非常資源密集的。用戶大多要求對數據進行隻讀訪問，並希望通過簡單的用戶界麵執行分析或創建儀表板。
集群供應的推薦方法是在集群中混合使用自動伸縮的節點供應方法。混合方法包括定義按需實例和的數量搶占式實例並在最小實例數和最大實例數之間啟用自動伸縮。
默認情況下，該集群始終可用，並由屬於組的用戶共享。啟用自動伸縮允許集群根據負載上下伸縮。
用戶不能啟動/停止集群，但是初始的按需實例可以立即響應用戶的查詢。如果用戶查詢需要更多的容量，自動伸縮會自動提供更多的節點(主要是Spot實例)來適應工作負載。
Databricks還有其他特性可以進一步改進多租戶用例:
處理交互式工作流中的大型查詢描述自動管理永遠不會完成的查詢的過程。
任務搶占改進長時間運行的作業和較短的作業一起工作的方式。
這種方法通過以下方法降低了總成本:
使用共享集群模型。
混合使用按需和現場實例。
使用自動伸縮來避免為未充分利用的集群付費。
專門的工作負載
場景
您需要為組織內的專業用例或團隊提供集群，例如，運行複雜數據探索和機器學習算法的數據科學家。一個典型的模式是用戶需要一個集群來運行他們的分析。
對於這種工作負載，最好的方法是為默認範圍、固定範圍和設置範圍創建具有預定義配置的集群策略。這些設置可能包括實例的數量、實例類型、就地實例還是按需實例、角色、要安裝的庫等等。使用集群策略允許具有更高級需求的用戶快速啟動集群，他們可以根據用例進行配置，並強製執行成本和策略的遵從性。
這種方法為用戶提供了更多的控製，同時通過預定義集群配置保持控製成本的能力。這還允許您為具有訪問不同數據集權限的不同用戶組配置集群。
這種方法的一個缺點是，用戶必須與管理員一起對集群進行任何更改，例如配置、安裝的庫等等。
