2

ここに同様の投稿があったことは知っていますが、本当に確かな答えがあるものを見つけることができません.

バイナリ ファイルがロードされた Hadoop クラスターがあります。これらのファイルのサイズは、数百 k から数百 mb までさまざまです。

現在、ファイルの内容全体を各マップに読み込むカスタム レコード リーダーを使用して、これらのファイルを処理しています。そこから、必要な適切なメタデータを抽出して JSON にシリアル化します。

私たちが予見している問題は、最終的に名前ノードが処理できないサイズに達する可能性があることです。移動するメモリは非常に多く、数テラバイトのメモリを持つ名前ノードを持つことはばかげているように思えます。

このような大きなバイナリ ファイルを適切に処理する方法はありますか? 特に、リデューサーがそれらを元に戻す順序がわからないために分割できないものは?

4

3 に答える 3

1

そのため、そのような答えではありませんが、コメントのリストを伝えるのがより難しいほど多くの質問があるので、ここに行きます：

各マップの内容全体をメモリに読み込むとおっしゃっていますが、これらのファイルの実際のバイナリ入力形式について詳しく説明できますか。

  • それらには論理レコードが含まれていますか、つまり、単一の入力ファイルが単一のレコードを表しているか、それとも多くのレコードを含んでいますか?
  • ファイルは圧縮されていますか (事後または何らかの内部圧縮メカニズム)?
  • 現在、このファイルを一度にどのように処理していますか? JSON に変換するための全体的な ETL ロジックは何ですか?
  • 処理を開始する前にメモリに読み込まれたファイル全体を実際に読み取る必要がありますか、それとも、ある程度のサイズのバッファが設定されたら処理できますか (DOM と SAX XML の解析など)。

私の推測では、マッパー ロジックの一部をレコード リーダーに移行し、複数のマッパー間でファイルを「分割」する方法を見つけることさえできると思います。これにより、スケーラビリティの問題に対処できます。

あなたの質問のいくつかの点に対処するには：

  • NameNode は、ブロックに関する情報 (名前、ブロック [サイズ、長さ、場所]) を格納するためのメモリのみを必要とします。まともなメモリ フットプリント (GB) を割り当てると仮定すると、HDFS ストレージにペタバイトのデータを保持するクラスターを作成できない理由はありません (十分な物理ストレージがあると仮定します)。
于 2012-06-21T01:42:48.837 に答える
0

Namenode は、ストレージや処理とは何の関係もありません。代わりに、データノードとタスクトラッカーに集中する必要があります。また、ここでストレージの問題やファイルの処理に対処しようとしているのかどうかもわかりません。多くのバイナリ ファイルを扱っている場合は、Hadoop SequenceFile を参照する価値があります。SequenceFile は、バイナリのキーと値のペアで構成されるフラット ファイルであるため、MapReduce で入出力形式として広く使用されています。詳細な説明については、このページにアクセスしてください -

http://wiki.apache.org/hadoop/SequenceFile
于 2012-06-20T19:48:41.130 に答える
0

大きなバイナリ ファイルがある場合は、SequenceFile 形式を入力形式として使用し、それに応じてマップされた入力分割サイズを設定します。合計入力サイズと設定した分割サイズに基づいてマッパーの数を設定できます。Hadoop が入力データの分割を処理します。

何らかの形式で圧縮されたバイナリ ファイルがある場合、hadoop はこの分割を実行できません。したがって、バイナリ形式は SequenceFile でなければなりません。

于 2012-06-21T01:32:15.140 に答える