亞馬遜EMR上的s3fs：它會擴展大約1億個小文件嗎？

Question

請參考已經提出以下問題： Write 100 million files to s3 和 Too many open files in EMR

這裏被處理的數據的大小是ATLEAST周圍4-5TB。準確地說 - 使用gzip壓縮的300GB。

隨着時間的推移，輸入的大小將逐漸增加，因爲此步驟會聚合數據。

例如，日誌，直到2012年12月將包含：

UDID-1, DateTime, Lat, Lng, Location 
UDID-2, DateTime, Lat, Lng, Location 
UDID-3, DateTime, Lat, Lng, Location 
UDID-1, DateTime, Lat, Lng, Location 

爲此，我們將不得不產生與UDID（唯一設備標識符）作爲單獨的文件的文件名和記錄屬於該UDID在文件中排序順序。

例：

UDID-1.dat => File Contents 
DateTime1, Lat1, Lng1, Location1 
DateTime2, Lat2, Lng2, Location2 
DateTime3, Lat3, Lng3, Location3 

現在，當我們有日誌一月，2013年月份，這一步驟將同時讀取舊的數據，通過這一步上了年紀個月已生成的文件，以及較新的日誌來聚合UDID的數據。

例：

If the logs for month of Jan has a record as: UDID-1, DateTime4, Lat4, Lng4, Location4, the file UDID-1.dat would need to be updated with this data. Each UDID's file should be chronologically sorted. 

對於這一步，我們認爲將數據寫入到一個EBS卷，並將其作爲-是供以後使用。但EBS卷的限制爲1TB。正如前面提到的那樣，在s3上直接生成文件或者在HDFS上生成文件然後轉移到s3文件對於這種用例來說不是一個可行的選擇，因爲大約有1億個需要移動的小文件。即使使用s3distcp，移動如此大量的文件也會太慢。

因此，接下來我們將嘗試s3fs - 由Amazon S3支持的基於FUSE的文件系統。有誰知道s3fs的可擴展性如何？它能夠處理1億個小文件嗎？需要多少時間才能將3-5TB的數據從s3傳輸到本地文件系統，以便它可以被MR作業使用？將數據移回s3需要多長時間？它會和使用s3distcp時遇到的問題一樣嗎？

在此先感謝！

Answer 1

我會建議不要使用s3fs來複制大量的小文件。

我已經嘗試了幾次從HDFS移動大量的小文件，並保持s3fs守護進程崩潰。我正在使用cp和rsync。如果您正在進行增量更新，這會變得更加惡化。另一種方法是使用use_cache選項並查看它的行爲。

我們採取了使用s3cmd並且使用Unix find命令遍歷每個文件的方法。事情是這樣的：

find <hdfs fuse mounted dir> -type f -exec s3cmd put {} s3://bucketname \; 

您也可以使用一些嘗試s3cmd sync這樣的：

s3cmd sync /<local-dir>/ s3://bucketname