Hadoop大量の独自のバイナリ エンコード テキスト データを処理するために使用するアプリケーションを、次のような単純化されたMapReduceシーケンスで考えてみましょう。
- ファイルまたはディレクトリへの URL を入力として取得します
- 入力 URL で見つかったバイナリ ファイルのリストを読み取ります
- これらの各ファイルからテキスト データを抽出します。
- テキスト データを、抽出された新しいプレーン テキスト ファイルに保存します。
- 抽出されたファイルを特殊な特性 (「コンテキスト」など) の (サブ) 形式に分類します。
- 必要に応じて、抽出された各テキスト ファイルをそのコンテキストに従って分割します
- 元の (分割されていない) ファイルのコンテキストを使用して各分割を処理します
- 処理結果を独自のデータ リポジトリに送信します
ステップ 5 で識別された形式固有の特性 (コンテキスト) も、キーと値のペアとして (小さな) テキスト ファイルに保存されるため、ステップ 6 とステップ 7 でアクセスできます。
InputFormatステップ 6 の分割は、カスタムクラス (カスタム ファイル形式ごとに 1 つ)を使用して行われます。
このシナリオを Hadoop で実装するには、ステップ 1 からステップ 5 を a に統合し、別のシナリオをステップ 7Mapperに使用できます。Mapper
このアプローチの問題はInputFormat、分割を生成するためにどの抽出ファイルを使用するかをカスタムに知らせる方法です。たとえば、形式 A は、わずかに異なる特性 (たとえば、異なる行区切り文字) を持つ 2 つの抽出されたファイルを表す場合があります。したがって、2 つの異なるコンテキストが 2 つの異なるファイルに保存されます。
上記に基づいて、getSplits(JobConf)各カスタムのメソッドは、InputFormat分割する前に各ファイルのコンテキストにアクセスできる必要があります。ただし、InputFormatフォーマットごとに (最大で) 1 つのクラスが存在する可能性があるため、抽出されたファイルの適切なセットを正しいコンテキスト ファイルと関連付けるにはどうすればよいでしょうか?
解決策は、抽出されたファイルとコンテキストを関連付けるために特定の命名規則を使用すること (またはその逆) である可能性がありますが、より良い方法はありますか?