2017-10-08 172 views
1

我在S3中存在大約15000個文件(ORC),其中每個文件包含幾分鐘的數據和每個文件的大小在300-700MB之間變化。由於遞歸循環YYYY/MM/DD/HH24/MIN格式的目錄非常昂貴,我創建了一個包含給定日期的所有S3文件列表的文件(objects_list.txt)並傳遞此文件作爲輸入到火花讀APISpark EMR S3處理大量文件

val file_list = scala.io.Source.fromInputStream(getClass.getResourceAsStream("/objects_list.txt")) 
val paths: mutable.Set[String] = mutable.Set[String]() 
    for (line <- file_list.getLines()) { 
     if(line.length > 0 && line.contains("part")) 
     paths.add(line.trim) 
    } 

val eventsDF = spark.read.format("orc").option("spark.sql.orc.filterPushdown","true").load(paths.toSeq: _*) 
eventsDF.createOrReplaceTempView("events") 

所述簇的大小是10個r3.4xlarge機(工人)(其中每個節點:120GB RAM和16個核心)和主是m3.2xlarge配置(

我面臨的問題是,火花閱讀運行不斷,我看到只有司機工作和休息所有節點沒有做任何事情,我不知道爲什麼驅動程序我因爲AFAIK火花懶惰地工作,所以直到一個行動被稱爲閱讀不應該發生,我認爲它列出每個文件,並收集一些與它相關的元數據。

但是爲什麼只有驅動程序正在工作並休息所有節點都沒有做任何事情,我如何讓這個操作在所有工作節點上並行運行?

我所遇到的這些文章https://tech.kinja.com/how-not-to-pull-from-s3-using-apache-spark-1704509219https://gist.github.com/snowindy/d438cb5256f9331f5eec,但這裏的整個文件的內容被解讀爲RDD,但我的使用情況取決於列唯一被提及的那些塊/數據的列應該從S3中獲取(給出ORC的列式訪問是我的存儲)。在S3文件大約有130列,但只有20場正在使用被稱爲和處理數據幀API的

Sample Log Messages: 
17/10/08 18:31:15 INFO S3NativeFileSystem: Opening 's3://xxxx/flattenedDataOrc/data=eventsTable/y=2017/m=09/d=20/h=09/min=00/part-r-00199-e4ba7eee-fb98-4d4f-aecc-3f5685ff64a8.zlib.orc' for reading 
17/10/08 18:31:15 INFO S3NativeFileSystem: Opening 's3://xxxx/flattenedDataOrc/data=eventsTable/y=2017/m=09/d=20/h=19/min=00/part-r-00023-5e53e661-82ec-4ff1-8f4c-8e9419b2aadc.zlib.orc' for reading 

下面你可以看到,只有一個執行程序運行到驅動程序的任務節點之一(集羣模式)而CPU是在其他節點的剩餘部分(即工人),0%,甚至後3-4小時處理的,這種情況是在文件的同一給定數量龐大的已被處理 Only One Executor is Active i.e Driver

任何指針怎麼可以避免這個問題,即加快負載和進程?

回答

2

有一種解決方案可以幫助您基於AWS Glue。

你在S3中分割了很多文件。但是你有基於時間戳的分區。所以使用膠水,您可以在S3中使用您的對象,如EMR中的「配置表」。

首先,你需要創建一個EMR有5.8+版本,你將能夠看到這一點:

enter image description here

您可以設置這個檢查這兩個選項。這將允許訪問AWS膠粘數據目錄。

之後,您需要將您的根文件夾添加到AWS膠水目錄。快速的方法是使用Glue Crawler。該工具將抓取您的數據並根據需要創建目錄。

我會建議你看看here

履帶運行後,這會對你的表中的目錄,你可以在AWS Athena看到的元數據。

在Athena,你可以看到你的數據是否被抓取者正確識別。

該解決方案將使您的火花接近真正的HDFS。由於元數據將在數據目錄中正確顯示。而你的應用程序正在尋找「索引」的時間將允許更快地運行作業。

在這裏使用此功能,我能夠改善查詢,並且使用膠水處理分區效果更好。所以,試試這可能會有助於演出。

+0

感謝您的詳細解答。但除了AWS Glue之外,還有其他的通用解決方案嗎?如果有人在GCE或Azure上運行他們的應用程序,該怎麼辦? ,我認爲這是一個非常普遍的問題,人們可能正在做一些事情來擺脫這個瓶頸,有興趣瞭解該解決方案 –

+0

在另一個說明中,是否有任何關於如何從EMR引用/連接到Glue目錄表的參考,他們的文檔沒有任何樣本/例子 –

+1

關於這一點並不多。如果您創建一個EMR集羣來檢查上述兩件事情。當您使用spark指向一個Hive表時,您可以指向該表。就像這樣使用:'val myDf = spark.table(「database.table」)'你有你的數據框。 –