1) ファイル
Hadoop ストリーミングを使用する場合、行ベースのテキスト ファイルを使用する必要があり、最初のタブまでのデータがキーとしてマッパーに渡されます。
ストリーミングのドキュメントを見てください。
入力ファイルを HDFS に入れることもできます。これは、大きなファイルに推奨されます。上記のリンクの「大きなファイル」セクションを見てください。
2) メタデータの保存
私が見る問題は、ヘッダー情報 (メタデータ) がそのようなデータとしてのみ扱われるため、自分でフィルター処理する必要があることです (最初のステップ)。すべての入力ファイルのデータはマップステップの後に結合されるだけなので、それを渡すのはより困難です。
後で関連付けられるようにするには、メタデータをデータ自体のどこかに追加する必要があります (2 番目のステップ)。ファイルの各データ行に対して (キー、データ + メタデータ) を発行できるため、各データ行のメタデータを保持できます。巨大なオーバーヘッドになるかもしれませんが、MapReduce について話しているのは、次のことを意味します: pfffrrrr ;)
ここで、ストリーミングが Java で実装されたジョブと実際にどの程度異なるのかがわからない部分が来ました。IF ストリーミングはファイルごとに 1 つのマッパーを呼び出します。次の問題を回避できます。map() の最初の入力をメタデータとして取得し、それ (またはプレースホルダー) を後続のすべてのデータ出力に追加するだけです。そうでない場合、次は Java-Jobs についてです。
少なくとも JAR マッパーを使用すると、データをその入力ファイルに関連付けることができます (こちらを参照)。ただし、メタデータを含まないファイルのパーティションでマップ関数が呼び出される可能性があるため、最初にメタデータを抽出する必要があります。私はそのようなものを提案します：
Hadoop ストリーミングを使用している場合、入力は任意の行ベースの形式にすることができます。マッパーとリデューサーの入力は sys.stdin から取得され、好きな方法で読み取ることができます。デフォルトのタブ区切りフィールドを使用する必要はありません (ただし、私の経験では、一貫性を保つために、可能であればすべてのタスクで 1 つの形式を使用する必要があります)。
ただし、デフォルトのスプリッターとパーティショナーでは、入力と出力がどのように分割またはソートされるかを制御できないため、マッパーとリデューサーは、特定の行がヘッダー行であるか、その行のみを使用してデータ行であるかを判断する必要があります。元のファイルの境界がわからない。
マッパーが最初の入力行がファイルの最初の行であると想定したり、行ベースの形式から離れたりするパーティショナーを指定できる場合があります。前回ストリーミングで試したときは、これを行うのは困難でした。私の意見では、マッパーとリデューサーのタスクは、効率と再利用性のために入力にとらわれないようにする必要があります。ファイル境界を追跡するよりも、入力レコードのストリームを考えるのが最善です。
ストリーミングのもう 1 つのオプションは、データに含まれる別のファイルにヘッダー情報を送信することです。これは、マッパーとレデューサーが作業ディレクトリで利用できるようになります。ファイルごとに関連付けるのではなく、1 行あたり 2 つではなく 3 つのフィールドを使用して、各行を初期タスクの適切なヘッダー情報に関連付けるというのが 1 つのアイデアです。
一般に、入力をストリームとして扱い、ファイルの境界、入力サイズ、または順序に依存しないようにしてください。これらの制限はすべて実装できますが、複雑さが犠牲になります。それらを実装する必要がある場合は、タスク チェーンの最初または最後に実行してください。
Jython または SWIG を使用している場合は、他のオプションがあるかもしれませんが、ストリーミングよりもそれらを使用するのが難しいことがわかりました。