0

Hadoop fs -put filename を使用してサイズ 117MB のテキスト ファイルを HDFS にアップロードすると、1 つのデータ ノードにはサイズ 64.98MB (デフォルトのファイル分割サイズ) のファイル部分が含まれ、別のデータ ノードにはサイズ 48.59MB のファイル部分が含まれていることがわかります。

私の質問は、この分割位置がデータを意識した方法で計算されたかどうかです (たとえば、ファイルがテキストであることを何らかの方法で認識し、ファイルを "\n" で分割します)。

InputFileFormat を使用して、実行中のジョブにファイルをインテリジェントな方法で分割する方法を伝えることができることを認識していますが、 fs -put コマンドでファイルの種類を指定しなかったため、インテリジェントな分割この場合は行われます。

エリー

4

1 に答える 1

3

ここで 2 つのことを混同していると思います。次の 2 種類の分割は完全に分離されています。

  1. ファイルを HDFS ブロックに分割する
  2. マッパーに配布するファイルの分割

いいえ、分割位置はデータを意識した方法で計算されませんでした。

現在、デフォルトで を使用している場合FileInputFormat、これらの両方のタイプの分割の種類が重複しています (したがって同一です)。

しかし、上記の 2 番目のポイントに対していつでも独自の方法で分割することができます (または分割をまったく行わない、つまり 1 つの完全なファイルを 1 つのマッパーに渡すこともできます)。

InputFormatまた、入力データの分割方法に関係なく、hdfs ブロック サイズを変更することもできます。

ここで注意すべきもう 1 つの重要な点は、ファイルは実際には HDFS に格納されるときに物理的に分割されますが、マッパーに配布するための分割については、ファイルの実際の物理的な分割ではなく、論理的な分割のみであるということです。

ここから例を挙げる：

110MB のテキスト ファイルを hdfs にロードするとします。hdfs ブロック サイズと入力分割サイズは 64MB に設定されています。

  1. マッパーの数は、hdfs ブロック分割の数ではなく、入力分割の数に基づいています。

  2. hdfs ブロックを 64MB に設定すると、正確に 67108864(64*1024*1024) バイトになります。つまり、ファイルが行の途中から分割されても問題ありません。

  3. これで、2 つの入力分割 (2 つのマップ) ができました。最初のブロックの最終行と 2 番目のブロックの最初の行は意味がありません。TextInputFormat は、意味のある行を読み取り、それらをマップ ジョブに渡す役割を果たします。TextInputFormat の機能は次のとおりです。

    • 2 番目のブロックでは、完全な行である 2 番目の行を探し、そこから読み取り、2 番目のマッパーに渡します。
    • 最初のマッパーは最初のブロックの終わりまで読み取り、(最初のブロックの最後の不完全な行 + 2 番目のブロックの最初の不完全な行) も処理します。

詳細はこちらをご覧ください。

于 2013-04-09T17:04:25.843 に答える