從gs到Dataproc的文件xfer - 文件大小成爲障礙？

儘管有幾個不同的集羣配置，我一直在Dataproc集羣上運行pySpark作業進行基準測試，並注意到處理時間固定的「底層」。我想知道這是否歸因於gs：storage和Dataproc之間的文件xfer延遲？從gs到Dataproc的文件xfer - 文件大小成爲障礙？

源文件是60G，並存儲在與我的數據集羣相同的區域（us-central1）中同一項目下的存儲區中。該檔案爲14.3億行，每卷17個字段的7.31億條記錄，全部在一行上。額外的行都是空白，除了標題行。

在1個主，4個工作人員配置中，一切都是帶有300GB磁盤的n-standard-8機器，運行時間爲35:20和36:33。當我把這個集羣加大到8個工人而不是4個（仍然全是n-standard-8）時，它降到了21:14。接下來，我將wkrs更改爲n-highmem-32中的4個，同時將mstr保持在n-standard-8，這個時間點在20:01。最後，通過切換到1 mstr和16 wkrs，我確實加強了所有n -highmem-32。此運行在15:36

這裏進來的最佳時間都是我的測試/ CONFIGS的結果，等：

我的腳本運行略有改動其他測試，以高速緩存，但沒有一個比上面好。

這讓我覺得60G文件的初始xfer是一個主要因素。多久你會期望這樣一個xfer採取 - 在同一個項目中，在同一地區的所有GCP內部？是否需要10分鐘？

我還包括萬一pySpark腳本答案是在這裏：

來源

2016-03-23 Thom Rogers

」文件是14.3億行，每個記錄有17個字段的731萬條記錄，全部在一行上。「你能重新解釋一下嗎？這些線條有多長？這可能是你的問題。 – surjikal

你也可以使用'reduceByKey'而不是'groupByKey'。 – surjikal

一般而言，當分區到達那裏不應該在文件尺寸方面的瓶頸，只要計算合理精細;潛在的InputFormat預計將60GB文件分割成大小爲〜64MB的大量較小字節範圍，這些字節範圍將分別由不同的工作任務獨立讀取。您應該檢查Spark web interfaces以查看正在運行的任務數量，其時間，每個任務的最小/最大時間，每個工作人員處理的字節數量等，以查看數據拆分中是否存在某些偏差或導致某些工人閒置並且無助於閱讀文件。

如果由於某種原因分區數量很少，您可以嘗試調用SparkContext.textFile(path, minPartitions)調用minPartitions參數。「

來源

2016-03-24 18:04:59

從gs到Dataproc的文件xfer - 文件大小成爲障礙？

回答

相關問題