私がデータ処理プログラムを書いている状況はたくさんありますが、新しいバグは大規模なデータセットでしか発見されません。たとえば、1 億レコードに 1 レコードでクラッシュするスクリプトを考えてみましょう (予期しない入力などにより)。データの小さなサンプルで開発している場合、そのバグは見られません。私にできることは、Hadoop のエラー ログをじっと見つめ、スクリプトを微調整してから、ジョブ全体を再実行することだけです。これは、計算時間と開発者時間の両方で恐ろしく非効率的です。
私が望むのは、スクリプトがクラッシュしたときに処理していたデータのセグメントをダウンロードする方法です。
これを Hadoop から簡単に取り出す方法はありますか? (理想的には、Hadoop ストリーミング?)
数年前、Hadoop 自体が作成する一時ディレクトリを掘り下げるという恐ろしいトリックを学びました...これは良い解決策とは思えません。
私が望むのは、スクリプトがクラッシュしたときに処理していたデータのセグメントをダウンロードする方法です。
「keep.failed.task.files」の説明は「失敗したタスクのファイルを保持する必要があります。これは、ストレージが再利用されないため、失敗しているジョブでのみ使用する必要があります。また、マップ出力がファイルから消去されるのを防ぎます。消費されるにつれてディレクトリを減らします。」
デフォルトは false です。このプロパティを true に変更すると、タスクが失敗した場合にデータを利用できるようになります。データは開発者のマシンに取り込まれ、プログラムは Eclipse で簡単にデバッグできます。
私にできることは、Hadoop のエラー ログをじっと見つめ、スクリプトを微調整してから、ジョブ全体を再実行することだけです。これは、計算時間と開発者時間の両方で恐ろしく非効率的です。
また、Hadoop ジョブが不良レコードに遭遇し、タスクがクラッシュした場合、レコードを無視して map/reduce タスクを再実行できます。完全なジョブを再度実行する必要はありません。詳細については、このHadoop ドキュメントを確認してください。
setup（）、map（）、reduce（）、cleanup（）メソッドのロジックの周りにtry-catchブロックを配置することをお勧めします。Exceptionのcatchブロックで、グループが「Exception」（またはその他）であり、名前が例外のgetMessage（）メソッドから返された文字列であるカウンターをインクリメントします。これにより、少なくとも何が起こったのかが一目でわかります。そのcatchブロックでは、スタックトレース、渡されたキーと値（または発話可能）などの追加情報をファイルに書き込むこともできます。
デバッグについては、Eclipseのhadoopフローを「デバッグ対象...->Javaアプリケーション」にすることも好きです。これは、コード内の多数の問題を見つけて修正するのに役立ちました。