pyspark中的優化

我正在編寫pyspark中的代碼，在哪裏進行過濾，加入，unionall，groupby操作。pyspark中的優化

但我注意到在groupby opration之前，count（）函數需要9分鐘，而groupby之後count（）函數需要35分鐘。我需要一些關於如何優化groupby子句的建議以減少處理時間。

配置參數：執行程序存儲器12克 NUM-執行人50 執行人芯5 驅動器的存儲器40克數據大小約1個TB

代碼段，例如：

dataframeA = hc.sql("select * from tableA") 



dataframeB = hc.sql("select * from tableB") 

dataframeC = hc.sql("select * from tableC") 



dataframeD = dataframeA.unionAll(dataframeB) 



dataframeE = dataframeD.join(dataframeC, col1 == col2, 'left_outer') 



dataframeF = dataframeE.groupby ([col1, col2] 
        .agg({ 
         max("col3"), 
         sum("col4")/ sum("col5"), 
         ... 
         })

任何建議？

來源

2016-11-28 Renu

能夠幫助您發佈您的代碼（或至少是一個簡化的例子） –

添加了代碼片段以供參考。 – Renu

您可以考慮使用reduceByKey而不是groupByKey。

groupByKey將洗牌集羣中的所有數據並消耗大量資源，但reduceByKey將首先減少每個集羣中的數據，然後再洗牌數據減少。

來源

2016-11-29 01:57:13

是的我懷疑過度洗牌正在發生在小組中。但是，在我使用所有數據框的情況下，是否可以應用reducebykey，並且聚合中有大約100列？ – Renu

在你的情況下，DataFrame的'groupBy'被優化，所以我不認爲'reduceByKey'真的有效。 –

有沒有什麼辦法可以減少組合和混合操作中的混洗？ – Renu

邏輯本身似乎沒問題。有幾件事你可以嘗試：

你有一個連接和groupby通常建議一些洗牌。您可以嘗試減少執行器的數量，提供更多的內存和內核。

在您的groupby中，您正在使用密鑰[col1，col2]。這些列與連接中的列相同嗎？如果是這樣，那麼它們本質上是相同的列，左邊的數據框上沒有按鍵。因此，您只能使用col2，希望優化程序能夠改善您的第二次洗牌（使用原始洗牌）。

來源

2016-11-29 07:55:35

在我的情況下，有3個連接，其中一個與group by具有相同的鍵。在這種情況下，減少執行程序的數量不會起到相同的執行時間。 – Renu

我從網頁界面發現的最後4個階段是超過一半的時間。如何增加分區？ – Renu

如果您有核心來處理它們，增加分區數量通常會有所幫助。它基本上增加了並行性... –

pyspark中的優化

回答

相關問題