将 1 亿个文件写入 s3

我的主要目标是根据每条记录的 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 https://stackoverflow.com/questions/12953251/too-many-open-files-in-emr，我没有将每个文件直接写入 s3，而是在本地写入，然后以 1024 个文件为一批批量移动到 s3。

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

我想要一个scalable如果将来数据量再次增加，该解决方案不会失败。

有什么建议么？

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

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

DynamoDB 可能是一个不错的选择，但可能价格昂贵，为 1 美元/GB/月。 （因为它使用 SSD 作为后备存储。）

RDS 是另一种选择。其定价为 0.10 美元/GB/月起。

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