Amazon EMR上的s3fs :它是否可以扩展到大约1亿个小文件？

Question

请参考已经提出的以下问题：Write 100 million files to s3和Too many open files in EMR

这里要处理的数据大小至少在4-5TB左右。准确地说-300 To，使用gzip压缩。

随着这一步随着时间的推移聚合数据，输入的大小将逐渐增加。

例如，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年1月的日志时，此步骤将读取旧数据、此步骤为较早月份生成的文件和较新的日志，以聚合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，移动如此大量的文件也太慢了。

因此，接下来我们将尝试亚马逊S3支持的基于s3fs -FUSE的文件系统。有人知道s3fs的可伸缩性有多强吗？它能处理1亿个小文件吗？将分布在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