私はここでは初めてですが、ApacheHadoopで記述されたプログラムの単体テストを行うための最良の方法を知る必要があります。マップ内のロジックのユニットテストケースをjUnitの方法で記述し、メソッドを減らすことができることを私は知っています。また、関連する他のロジックについても同じことができますが、これは十分にテストされ、実際の実行環境で動作することを保証するものではありません。
MRUnitについて読んだことがありますが、それも上で述べたようなもののようですが、より成熟した方法です。しかし、それも実際のmapreduceジョブとしては実行されませんが、モックされたものです。
どんな助けでもいただければ幸いです。
ありがとう。
あなたには確かに他の選択肢があります。少しグーグルすると、あなたはそれを自分で手に入れているでしょう。ここで私はあなたのためにそれをしました！
これが私が貼り付けているテキストです：http：//blog.cloudera.com/blog/2009/07/advice-on-qa-testing-your-mapreduce-jobs/
従来のjUnitとMRUnitを使用する以外に、次のオプションがあります。
従来の単体テストとMRUnitは、バグを早期に検出するのに十分な仕事をする必要がありますが、どちらもHadoopを使用してMRジョブをテストしません。ローカルジョブランナーを使用すると、1つのJVM内のローカルマシンでHadoopを実行できるため、ジョブが失敗した場合のMRジョブのデバッグが少し簡単になります。
ローカルジョブランナーを有効にするには、「mapred.job.tracker」を「local」に設定し、「fs.default.name」を「file：/// some / local / path」に設定します（これらはデフォルト値です）。
ローカルジョブランナーを使用する場合は、Hadoopデーモンを起動する必要がないことを忘れないでください。bin / hadoopを実行すると、JVMが起動し、ジョブが実行されます。新しいhadoop-local.xmlファイル（または0.20を使用している場合はmapred-local.xmlとhdfs-local.xml）を作成することはおそらく理にかなっています。次に、–configパラメーターを使用して、使用する構成ディレクトリーをbin/hadoopに指示できます。構成ファイルをいじりたくない場合は、Toolを実装し、 ToolRunnerを使用するクラスを作成してから、このクラスをbin / hadoop jar foo.jar com.example.Bar -D mapred.job.tracker=localで実行できます。 -D fs.default.name = file：///（args）、ここでBarはツールの実装です。
ローカルジョブランナーを使用してHadoopでMRジョブをテストするには、ローカルジョブランナーが有効になっている新しい構成ディレクトリを作成し、通常どおりにジョブを呼び出します。–configパラメーターを含めることを忘れないでください。ローカル構成ファイル。
-confパラメーターは0.18.3でも機能し、 –configでディレクトリーを指定する代わりに、hadoop-local.xmlファイルを指定できます。Hadoopはジョブを楽しく実行します。この形式のテストの難しさは、ジョブが正しく実行されたことを確認することです。注：ジョブを実行する前に、入力ファイルが正しく設定され、出力ディレクトリが存在しないことを確認する必要があります。
ローカルジョブランナーを構成してジョブを実行できたとすると、ジョブが正しく完了したことを確認する必要があります。単に終了コードに基づいて成功するだけでは十分ではありません。少なくとも、ジョブの出力が正しいことを確認する必要があります。bin/hadoopの出力をスキャンして例外を探すこともできます。前提条件を設定し、ジョブを実行し、実際の出力と期待される出力を比較し、発生した例外をスキャンするスクリプトまたは単体テストを作成する必要があります。このスクリプトまたは単体テストは、適切なステータスで終了し、ジョブがどのように失敗したかを説明する特定のメッセージを出力できます。
ローカルジョブランナーにはいくつかの制限があることに注意してください。サポートされるレデューサーは1つだけであり、DistributedCacheは機能しません（修正が進行中です）。
ローカルジョブランナーを使用すると、単一のスレッドでジョブを実行できます。単一スレッドでMRジョブを実行することはデバッグに役立ちますが、複数のHadoopデーモン（ NameNode、DataNode、TaskTracker、JobTracker、SecondaryNameNodeなど）が実行されている実際のクラスターを適切にシミュレートしません。疑似分散クラスターは、すべてのHadoopデーモンを実行する単一のマシンで構成されます。このクラスターは依然として比較的管理が簡単で（ローカルのジョブランナーよりも難しいですが）、ローカルのジョブランナーよりもHadoopとの統合をテストします。
疑似分散クラスターを使用してHadoopでMRジョブをテストするには、ローカルジョブランナーを使用するための前述のアドバイスに従いますが、前提条件のセットアップには、すべてのHadoopデーモンの構成と起動が含まれます。次に、ジョブを開始するには、通常どおりにbin/hadoopを使用します。
おそらく、MRジョブをテストするための最も徹底的でありながら最も面倒なメカニズムは、少なくとも数台のマシンで構成されるQAクラスターでそれらを実行することです。QAクラスターでMRジョブを実行することにより、ジョブとHadoopとの統合の両方のすべての側面をテストすることになります。
QAクラスターでジョブを実行すると、ローカルのジョブランナーと同じ問題が多数発生します。つまり、ジョブの出力が正しいかどうかを確認する必要があります。また、各タスクの試行によって生成されたstdinとstdoutをスキャンすることもできます。これには、これらのログを中央の場所に収集して、それらを取得する必要があります。Scribeはログを収集するための便利なツールですが、QAクラスターによっては不要な場合があります。
ほとんどのお客様は、新しいジョブをデプロイしてテストし、新しいバージョンのHadoopを試し、クラスターをあるバージョンから別のバージョンにアップグレードする練習をすることができる、ある種のQAまたは開発クラスターを持っていることがわかりました。Hadoopが本番パイプラインの主要部分である場合、QAまたは開発クラスターを作成することは非常に理にかなっており、Hadoopでジョブを繰り返し実行することで、ジョブへの変更を引き続き徹底的にテストできます。EC2は、オンデマンドでアップおよびダウンできるため、QAクラスターに適したホストになる可能性があります。EC2でQAクラスターを作成することに興味がある場合は、ベータ版のEC2EBSHadoopスクリプトをご覧ください。
組織にとってのQAの重要性と、所有しているリソースの量に基づいて、QAプラクティスを選択する必要があります。従来の単体テストフレームワークを使用するだけで、MRUnitとローカルジョブランナーは、リソースをあまり使用せずに、簡単な方法でMRジョブを徹底的にテストできます。ただし、QAまたは開発クラスターでジョブを実行することは、当然、Hadoopクラスターの費用と運用タスクを使用してMRジョブを完全にテストするための最良の方法です。