2

私の主な目的は、各レコードの ID に従ってレコードをファイルに分割することです。現在、150 億を超えるレコードがあり、確実に増加する可能性があります。Amazon EMR を使用したスケーラブルなソリューションが必要です。約 9 億件のレコードを持つ小規模なデータセットについては、既にこれを行っています。

入力ファイルはcsv形式で、フィールドの1つが出力のファイル名である必要があります。したがって、次の入力レコードがあるとします。

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

これで、2 つのファイルが出力されます。1 つは という名前awesomeID1.datで、もう1 つは という名前でawesomeID2.dat、それぞれの ID に関連するレコードが含まれています。

入力のサイズ: 1 か月あたり合計 600 GB (gzippef ファイルのサイズ)、各ファイルは約 2 3 GB です。そして、一度に約6か月以上処理する必要があります。したがって、合計データ サイズは 6*600 GB (圧縮) になります。

以前は、id 値に従って s3 に書き込むためToo many open filesに使用していたときにエラーが発生していました。FileByKeyTextOutputFormat extends MultipleTextOutputFormat<Text, Text>次に、ここで説明したように、すべてのファイルを直接 s3 に書き込むのではなく、ローカルに書き込み、1024 個のファイルのバッチで s3 に移動しました。

しかし、データ量が増えたため、s3 から次のメッセージが表示され、問題のファイルの書き込みがスキップされます。"Please reduce your request rate."また、200 台の m1.xlarge マシンを含むクラスターで実行する必要があるため、約 2 時間かかります。も非常に高価です！

将来、データ量が再び増加しても失敗しないスケーラブルなソリューションが必要です。

助言がありますか？

4

1 に答える 1

0

SlowDownエラーに関する情報は次のとおりです。https ：//forums.aws.amazon.com/message.jspa？messageID = 89722＃89816アルファベット順にS3に挿入する必要があります。また、制限は動的であり、時間の経過とともに再調整されるため、速度を落とし、後でレートを上げてみてください。

おそらく、ファイルシステムよりもデータベースを使用する方が良いでしょうか？データセット全体の大きさはどれくらいですか？

DynamoDBは適しているかもしれませんが、月額$ 1/GBと高額になる可能性があります。（バッキングストレージにSSDを使用しているため。）

RDSは別のオプションです。価格は$0.10/GB/月からです。

さらに良いのは、新しいhs1.8xlargeインスタンスなど、EC2で独自のNoSQLまたは他のデータストアをホストすることです。必要な場合にのみ起動し、不要な場合はS3にバックアップできます。

于 2012-12-29T11:23:48.187 に答える