InputSampler についての私の理解では、レコード リーダーからデータを取得し、キーをサンプリングしてから、HDFS にパーティション ファイルを作成します。
このサンプラーについていくつか質問があります: 1) このサンプリング タスクはマップ タスクですか? 2) データは HDFS 上にあります (クラスターのノード全体に分散されています)。このサンプラーは、サンプリングするデータを持つノードで実行されますか? 3) これはマップ スロットを消費しますか? 4) サンプルは MR ジョブのマップ タスクと同時に実行されますか? スロットの数を減らすことで、マッパーが消費する時間に影響するかどうかを知りたいですか?
私は、InputSampler が重大な欠陥のある仮定をしているため、あまり役に立たないことを発見しました。
これは、マッパー入力からキー値をサンプリングし、結果の統計を使用してマッパー出力を均等に分割するという考え方です。その場合、マッパーの入力と出力でキーのタイプと値の分布が同じであると想定されます。私の経験では、マッパーが読み取り時に同じキー値タイプをレデューサーに送信することはほとんどありません。したがって、InputSampler は役に立ちません。
効果的に分割するためにサンプリングしなければならなかった数回で、最終的にはマッパーの一部としてサンプリングを行い (そのとき初めてどのキーが生成されているかがわかったため)、結果をマッパーの close() に書き出すことになりました。ディレクトリへのメソッド (マッパーごとに 1 セットの統計情報)。私のパーティショナーは、最初の呼び出しで遅延初期化を実行して、マッパーが作成したファイルを読み取り、統計を有用な構造に同化してから、それに応じて後続のキーを分割する必要がありました。
他の唯一の現実的なオプションは、開発時にキー値がどのように分散されているかを推測し、その仮定をパーティショナーにハードコーディングすることです。
あまりきれいではありませんが、私が把握できる最高のものでした。
この質問はずっと前に出されたもので、多くの質問が未回答のままでした。
@Chris による唯一かつ最も投票された回答は、実際には質問に回答していませんが、興味深い視点を提供しますが、私の意見では少し悲観的で誤解を招く可能性があるため、ここでも説明します。
サンプリング タスクは、 への呼び出しで実行されInputSampler.writePartitionFile(job, sampler)ます。このメソッドの呼び出しは、同じスレッドでサンプリングが行われている間、ブロックされています。
そのため、電話する必要はありませんjob.waitForCompletion()。これは MapReduce ジョブではなく、単にクライアントのプロセスで実行されます。さらに、MapReduce ジョブは開始するまでに少なくとも 20 秒かかりますが、小さなファイルのサンプリングには数秒しかかかりません。
したがって、すべての質問に対する答えは単純に「いいえ」です。
のコードを見ると、 をwritePartitionFile()呼び出していることがわかりますsampler.getSample()。 を呼び出しinputformat.getSplits()て、サンプルとなるすべての入力分割のリストを取得します。
これらの入力形式は、サンプルを抽出するために順次読み取られます。各入力分割は、同じメソッド内で作成された新しいレコード リーダーによって読み取られます。これは、クライアントが読み取りとサンプリングを行っていることを意味します。
他のノードは「マップ」やその他のプロセスを実行していません。サンプリングに必要な入力分割のためにクライアントが必要とするブロック データを HDFS に提供しているだけです。
ここで、Chris の回答について説明します。InputSampler と TotalOrderPartitioner にはおそらくいくつかの点で欠陥があることに同意します。なぜなら、それらは実際には理解も使用も簡単ではないからです...しかし、マップの入力と出力の間でキーの型を同じにする必要はありません。
InputSampler は、ジョブの InputFormat (およびその RecordReader) キーを使用して、サンプリングされたすべてのキーを含むパーティション ファイルを作成します。次に、このファイルは、Mapper のプロセスの最後のパーティショニング フェーズで TotalOrderPartitioner によって使用され、パーティションが作成されます。
最も簡単な解決策は、 InputSampler 専用のカスタム RecordReader を作成することです。これは、Mapperと同じキー変換を実行します。
これを説明するために、データセットに (char, int) のペアが含まれており、マッパーが文字の ascii 値を取得してそれらを (int, int) に変換するとします。たとえば、「a」は 97 になります。
このジョブの全順序分割を実行する場合、InputSampler は文字「a」、「b」、「c」をサンプリングします。次に、パーティショニング フェーズでは、マッパーの出力キーは 102 や 107 などの整数値になり、パーティション分散用のパーティション ファイルの 'a'、'g'、または 't' とは比較できません。これは一貫性がなく、サンプリングと mapreduce ジョブに同じ InputFormat を使用すると、入力と出力のキー タイプが同じであると見なされるように見えるのはこのためです。
したがって、解決策は、カスタムの InputFormat とその RecordReader を作成することです。これは、クライアント側のサンプリング ジョブにのみ使用されます。このジョブは、入力ファイルを読み取り、各レコードを返す前に同じ変換charを行います。intこのように、InputSampler はカスタム レコード リーダーからの整数 ascii 値をパーティション ファイルに直接書き込みます。これにより、同じ分布が維持され、マッパーの出力で使用できるようになります。
数行のテキスト説明テキストで把握するのはそれほど簡単ではありませんが、InputSampler と TotalOrderPartitioner がどのように機能するかを完全に理解することに興味がある人は、このページをチェックしてください: http://blog.ditullio.fr/2016/01/04/hadoop -basics-total-order-sorting-mapreduce/
さまざまなケースでの使用方法を詳しく説明しています。