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 は、Hadoop クラスター内のマシン間通信に使用されるオープンソースHTTPサーバーです。