磚的性能調優的筆記本

[HariharaSam]

大家好！

我試圖運行一個磚筆記本使用ThreadPoolExecutor並行。

誰能建議如何減少花費的時間基於以下發現。

當前的性能:

時間25分鍾

ThreadPoolExecutor max_workers - 24

目前集群配置:

DBR - 9.1 LTS

最小的工人- 2

馬克斯工人- 6

核心- 4人均數量

內存- 14 GB /工人

自動伸縮功能啟用

我試著增加工人的數量到18希望它會減少花費的時間,但實際上並沒有幫助。

任何想法如何減少時間. .

[Hubert_Dudek1]

ThreadPoolExecutor不會幫助磚/火花將處理工作的工作。

所以請分析在UI火花是什麼消費最多的時間。

有很多技巧如何優化他們依靠數據集(大小等轉換)

• 尋找數據傾斜;一些分區可以是巨大的,小的,因為不正確的分區。您可以使用火花UI,但也調試代碼有點(get getNumPartitions()),尤其是SQL可以把它不平等的分區(有設置連接器下界,等等)。你可以試著分區的數量作為工人的核心乘以X(所以他們將處理隊列中一步一步),
• 檢查數據泄漏在火花UI意味著寫作洗牌從RAM和磁盤分區。(25、50和75百分位應該是類似的)。增加洗牌分區如果他們必須經常寫到磁盤上。
• 增加調整大小spark.SQL.shuffle.partitions默認是200大,你應該計算數據大小除以分區的大小,
• 增加司機的大小兩倍執行程序(但得到最優規模,請分析負載——在磚集群選項卡上的指標有Ganglia甚至更好地整合datadog集群),
• 檢查寬轉換,在分區之間需要調整數據,組織他們做一個洗牌,
• 如果您需要過濾數據,如果可能的話,做到在閱讀從SQL因此將表語推這將增加在SQL查詢,
• 確保一切在一個分布式的方式運行,特別是UDF。它將幫助如果你使用矢量化熊貓udf將運行在執行人。甚至熊貓udf可以緩慢。你可以嚐試而不是注冊metastore中的SQL函數並使用它在您的SQL查詢。
• 不要使用收集等,因為它們不是運行在分布式的方式,而是在驅動程序裝入內存對象的一切(就像在本地執行筆記本)
• 關於基礎設施,使用更多的工人和檢查你的ADLS連接通過一個私人聯係。
• 您還可以使用溢價ADLS更快。
• 有時我處理大數據作為流更容易與大數據集。在這種情況下,你需要卡夫卡(彙合的雲很優秀)的SQL和磚之間。如果你使用流進行一次性處理,請使用AvailableNow而不是一次。
• 讀取數據時,請記住,如果你閱讀從一個大分區文件(大約200 MB)將會更快。所以對於一個三角洲,閱讀前可以優化。當然,如果你讀,例如,持續x天每天分區將會更快,但運行優化可以幫助。
• 關於寫作,最好的是,你得到盡可能多的文件核/分區默認情況下,每個核心並行正在寫一個文件。以後你可以通過提及優化合並它們。請檢查每個文件大小相似。如果沒有,看來你有一個傾斜的分區。在一個巨大的數據集,有時是好鹽,然後分區數量,數量比相等(你可以從SparkContext獲得核的數量。DefaultParallelism屬性)

[HariharaSam]

嗨@Hubert杜德克,

你有提到ThreadPoolExecutor不會幫助,所以如果我想要運行一個相同的磚筆記本的100個不同的輸入值和運行序列需要更多的時間來完成。

那麼如何實現這個場景呢?

[Hubert_Dudek1]

編排為一個工作負載的一切,每一個筆記本運行會有不同的參數(類似下麵的圖片)。您可以創建一個* * * * *任務時,所有依賴於它,這樣他們將使用同一台機器(另一個設定,你使用的服務器和每個任務使用不同的機器也是可能的)。

如果你真的想要一個1萬的筆記本1並行集群,您可以設置一個獨特的工作池執行每一個筆記本所以他們會保留資源(池需要不同)的名稱。

sc.setLocalProperty (“spark.scheduler。池”、“somename”)