1

私たちはElasticMapReduceを非常に広範囲に使用しており、ElasticMapReduceを使用してますます多くのデータを処理しています。データの形式が正しくないために、ジョブが失敗することがあります。あらゆる種類の例外を処理するためにマップスクリプトを絶えず改訂してきましたが、スクリプトを壊すことができる不正な形式のデータがまだある場合があります。

  1. 一部のマップまたはリデュースジョブが失敗した場合でも、Elastic MapReduceを「エラー時に続行」に指定することは可能ですか？

  2. 少なくとも、クラスター全体が失敗する失敗したタスクの最小数を増やすことは可能ですか（場合によっては、500程度のジョブのうち1つだけ失敗したジョブがあり、少なくともそれらの結果を取得してクラスターを作成したい場合があります）実行を継続します。）

  3. さらに、新しい例外を処理するようにマップスクリプトを修正することはできますが、デフォルトのHadoop "aggregate"レデューサーを使用します。それが失敗した場合、例外をキャッチする方法はありません。「集計」レデューサーのエラーを処理する特別な方法はありますか、それとも上記の質問2で利用可能なものを処理する必要がありますか（失敗したタスクの最小数を増やします）。

4

2 に答える 2

2

マッパーとレデューサーの両方でキャッチExceptionでき、キャッチブロック内には次のようなカウンターがあります。

catch (Exception ex){
    context.getCounter("CUSTOM_COUNTER", ex.getMessage()).increment(1);
    System.err.println(GENERIC_INPUT_ERROR_MESSAGE + key + "," + value); // also log the payoad which resulted in the exception
    ex.printStackTrace();
}

例外メッセージが予想どおりであり、カウンターの値も許容できる場合は、結果を先に進めるか、ログを調査することができます。キャッチExceptionすることはお勧めできませんが、「エラーを続行」したい場合は、ほとんど同じです。Excpetionここではクラスターのコストが危機に瀕しているので、特定の例外よりもキャッチしたほうがよいと思います。

ただし、コードが完全に間違った入力で実行されるなどの副作用がある可能性がありますが、キャッチの場合ははるかに早く失敗します。しかし、このようなことが起こる可能性は非常に低いです。

編集：

ポイント2については、以下を使用して、トラッカーごとに許可される障害の最大数を設定できます。

        conf.setMaxTaskFailuresPerTracker(noFailures);

また

設定する必要のある構成はですmapred.max.tracker.failures。ご存知かもしれませんが、デフォルトは4です。他のすべてのマップされた構成については、ここを参照してください。

于 2013-02-25T22:06:43.840 に答える
0

私があなたの質問を正しく読んでいるなら、emrのrubyベースのコマンドラインツールのelastic-mapreduce呼び出しで定義された次のステップに失敗してもクラスターを続行させることができます

--jar s3://elasticmapreduce/libs/script-runner/script-runner.jar --args "s3://bucket/scripts/script.sh" --step-name "do something using bash" --step-action CONTINUE  \
于 2014-03-03T23:36:03.207 に答える