Too many fetch-failures (フェッチの失敗が多すぎる)

ステップまたはタスク試行ログに [Too many fetch-failures] または [Error reading task output] というエラーメッセージが表示されている場合、実行中のタスクは別のタスクの出力に依存するということを示しています。これは多くの場合、リデューサータスクが実行のために列に並んでおり、1 つまたは複数のマップタスクの出力を必要としているとき、その出力がまだ利用できないときに発生します。

出力が利用できない場合、次のような理由が考えられます。

• 前提条件となるタスクが処理中です。これは多くの場合、マップタスクです。

• データが別のインスタンスに置かれている場合、ネットワークの接続状態が悪いためにデータが利用できないことがあります。

• 出力の取得に HDFS が利用される場合、HDFS の問題も考えられます。

このエラーの最も一般的な原因は、前のタスクが実行中であることです。これは特に、リデューサータスクが最初に実行を試みるときにエラーが発生する場合に該当します。これに該当するかどうかは、エラーを返したクラスターステップの syslog ログを調べることで確認できます。マップタスクとリデューサータスクの両方が進行していることが syslog から判明した場合、マップタスクが完了していないうちにリデューサーフェーズが開始されたことを示します。

ログで確認するべきことの 1 つは、100% に到達し、それから値を落とすマッパーの進捗パーセンテージです。マップのパーセンテージが 100% のとき、それはすべてのマップタスクが完了していることを意味しません。それが意味することは、Hadoop がすべてのマップタスクを実行していることだけです。この値が 100% より下に落ちる場合、それはマップタスクが失敗し、設定によっては、Hadoop がタスクの再スケジュールを試行する場合があることを意味します。ログのマップのパーセンテージが 100% のままになっている場合、CloudWatch メトリクス、特に RunningMapTasks を調べて、マップタスクが処理中かどうかを確認します。この情報は、マスターノードで Hadoop Web インターフェイスを利用し、確認することもできます。

この問題が発生する場合、次のような操作を試すことができます。

• リデューサーフェーズが開始までに待ち時間を長くします。この場合、Hadoop 設定の mapred.reduce.slowstart.completed.maps を変更し、時間を長くします。詳細については、「追加のソフトウェアをインストールするためのブートストラップアクションの作成」を参照してください。

• リデューサーのカウントをクラスターのリデューサー能力の合計に合わせます。この場合、ジョブの Hadoop 設定の mapred.reduce.tasks を調整します。

• コンバイナクラスコードを使用して、フェッチする必要がある出力の数を最小限に抑えます。

• Amazon EC2 サービスに、クラスターのネットワークパフォーマンスに影響を与えるような問題がないことを確認します。これは、サービスヘルスダッシュボードを利用して確認できます。

• クラスターのインスタンスの CPU とメモリリソースをチェックし、データ処理がノードのリソースに過度の負担を与えていないことを確認します。詳細については、「クラスターハードウェアとネットワークを設定する」を参照してください。

• Amazon EMR クラスターで使用する Amazon マシンイメージ (AMI) のバージョンを確認します。バージョンが 2.3.0～2.4.4 の場合は、より新しいバージョンに更新してください。このバージョンの範囲に該当する AMI で使用される Jetty のバージョンでは、マップフェーズからの出力の配信に失敗する可能性があります。リデューサーがマップフェーズからの出力を取得できない場合は、フェッチエラーが発生します。

  Jetty はオープンソースの HTTP サーバーで、Hadoop クラスター内でのマシン間の通信に使用されます。