boto 2.8.0 を使用して、S3 に保存されている大きなログ ファイルに対して EMR ジョブフローを作成しています。私は Elastic Mapreduce に比較的慣れていないので、この問題からジョブフローを適切に処理する方法を感じています。
問題のログファイルは、ログ サーバーから出力された日付に対応するキーを使用して s3 に保存されます/2013/03/01/access.log。これらのファイルは非常に大きいです。私の mapreduce ジョブは、Apache Pig スクリプトを実行します。このスクリプトは、ログ ファイルに保存されている uri パスの一部を単純に調べ、ビジネス ロジックに対応する一般化されたカウントを出力します。
boto のクライアント コードは、cli の入力として日時を受け取り、PigStep必要なすべての日付のインスタンスを使用してジョブフローをスケジュールします。したがって、次のようなものを渡すとpython script.py 2013-02-01 2013-03-01、29 日分の datetime オブジェクトが繰り返され、s3 のそれぞれの入力キーでピッグステップが作成されます。from_dateこれは、結果として得られるジョブフローに、との間の timedelta の各日に 1 つずつ、非常に多くのステップが含まれる可能性があることを意味しますto_date。
私の問題は、私の EMR ジョブフローが非常に遅く、ほとんどばかげていることです。それは今一晩実行されていますが、その例セットの途中まではできていません. このような多くのジョブフローステップを作成しているのに何か問題がありますか? クライアント コードで前処理して各日付のステップを作成するのではなく、代わりにさまざまなキーの豚スクリプトを一般化する必要がありますか? これは、Elastic Mapreduce の最適化を探すのに実行可能な場所ですか? AWS cli ruby クライアントに渡された 1 か月分の同等のデータに対する同様のジョブのelastic-mapreduce実行には、約 15 分かかりました (このジョブは、同じ豚のスクリプトによって強化されました)。
編集
言うまでもなく、ジョブはタイプ m1.small の 2 つのインスタンスに対してスケジュールされていましたが、それ自体が問題である可能性があります。