問題タブ [input-split]

次のシナリオを検討してください。

それぞれ6 MBの4つのファイルがあります。HDFSブロックサイズは 64 MB です。

1blockは、これらすべてのファイルを保持します。余分なスペースがあります。新しいファイルが追加された場合、ここに収容されます

によってジョブのinput splitsが計算される場合 (通常は、各分割を処理のためにメモリにロードできるため、シーク時間が短縮されます。)Map-reduceInput formatsplit sizeHDFS block size

ここで行われる入力分割の数:

1. 4つのファイルすべてがaに含まれているため、1つblockですか？

2. それともファイルごとに1つの入力分割ですか?

3. これはどのように決定されますか？すべてのファイルを単一の入力分割として処理したい場合はどうすればよいですか?

NLineInputFormat の getSplitsForFile() fn を調べました。入力ファイル用に InputStream が作成され、その反復と分割が n 行ごとに作成されることがわかりました。効率的ですか？特に、この読み取り操作がマッパー タスクを起動する前に 1 つのノードで発生している場合。5 GB のファイルがある場合はどうなりますか。基本的には、ファイル データが 2 回シークされることを意味します。これがボトルネックである場合、hadoop ジョブはこれをどのようにオーバーライドしますか?

私のユースケースを clément-mathieu に提供するための編集

私のデータセットは、それぞれ約2GBの大きな入力ファイルです。ファイルの各行は、データベースのテーブル (私の場合は cassandra) に挿入する必要があるレコードを表します。データベースへの一括トランザクションを n 行ごとに制限したいと考えています。nlineinputformat を使用してこれを行うことに成功しました。私の唯一の懸念は、本番環境で現れる可能性のある隠れたパフォーマンスのボトルネックがあるかどうかです。

1. Hadoop で処理するファイルがあり、ファイルのサイズが HDFS のブロック サイズよりも小さいことがわかっています。これは、ファイルが分割されないことを保証し、デフォルトのファイルでは分割されないため、InputSplit を記述する必要はありませんか?

2. SequenceFileOutputFormat (またはその他の出力形式) で保存されたファイルがブロック サイズよりも大きい場合、1 つのキーと値のペアのみで構成されます。これは、ファイル ブロックが同じノードに格納され (レプリケートされたコピーを除く)、MapReduce タスクがそれらを取得するために多くの時間を無駄にしないことを意味しますか? これは、キーが分割されない (キー サイズがブロック サイズよりも小さく、キーが 1 つしかない) ため、独自の inputSplit を記述する必要がないことを意味しますか?

Flumeを使用してTwitterデータをhdfsにダウンロードしていました。2 GB を超えるデータがありますが、チャンク ファイルの分割は 64 MB 未満です。つまり、1 番目のファイルは 300 KB、2 番目のファイルは 566 KB です。なぜそれが起こっているのですか？

Hadoop MapReduce InputFormatインターフェイスの Apache ドキュメントから:

"入力サイズに基づく [L] 論理分割は、多くのアプリケーションにとって不十分です。これは、レコード境界を尊重する必要があるためです。そのような場合、アプリケーションは、レコード境界を尊重し、レコードを提示する責任があるRecordReaderも実装する必要があります。個々のタスクに対する論理的なInputSplitの指向ビュー。"

WordCountサンプル アプリケーションは、入力サイズに基づく論理分割が不十分なものですか? その場合、RecordReader の実装はソース コードのどこにありますか?