hadoop - 写入 1 亿个文件到 s3

Question

我的主要目标是根据每条记录的id将记录拆分成文件，现在有超过150亿条记录，而且肯定会增加。我需要一个使用 Amazon EMR 的可扩展解决方案。我已经为一个拥有大约 9 亿条记录的较小数据集完成了这项工作。

输入文件为 csv 格式，其中一个字段需要作为输出中的文件名。假设有如下输入记录:

awesomeId1, somedetail1, somedetail2
awesomeID1, somedetail3, somedetail4
awesomeID2, somedetail5, somedetail6

所以现在应该有 2 个文件作为输出，一个名为 awesomeID1.dat和其他 awesomeID2.dat ，每个都有与各自 ID 相关的记录。

输入大小:每月总计 600 GB(gzippef 文件的大小)，每个文件约为 2 3 GB。我需要一次处理大约 6 个月或更长时间。所以总数据大小为 6*600 GB(压缩后)。

之前我得到的是 Too many open files使用 FileByKeyTextOutputFormat extends MultipleTextOutputFormat<Text, Text> 时出错根据id值写入s3。然后正如我所解释的here ，我没有将每个文件直接写入 s3，而是在本地写入它们并以 1024 个文件为一组移动到 s3。

但现在随着数据量的增加，我从 s3 收到以下消息，然后它跳过写入有问题的文件:"Please reduce your request rate."此外，我还必须在包含 200 台 m1.xlarge 机器的集群上运行，这需要大约 2 个小时，因此成本也非常高!

我想要一个可扩展的解决方案，如果将来数据量再次增加，它也不会失败。

有什么建议吗？

Answer 1

这里是一些关于 SlowDown 错误的信息:https://forums.aws.amazon.com/message.jspa?messageID=89722#89816您应该按字母顺序插入 S3。此外，该限制是动态的，会随着时间的推移而重新调整，因此请放慢速度，稍后再尝试提高速度。

也许使用数据库比使用文件系统更好？总数据集有多大？

DynamoDB 可能是一个不错的选择，但可能很贵，每月 1 美元/GB。 (因为它使用 SSD 作为后备存储。)

RDS 是另一种选择。它的定价从 0.10 美元/GB/月起。

更好的办法可能是在 EC2 上托管您自己的 NoSQL 或其他数据存储，例如在新的 hs1.8xlarge 实例上。您可以仅在需要时启动它，并在不需要时将其备份到 S3。