3

org.apache.hadoop.mapreduce.*次のプロパティを持つテキスト ファイルを処理するには、(API を使用して) map reduce バッチを作成する必要があります。

  • ISO-8859-1エンコーディング。
  • CSVライク
  • セパレータは0xef

TextInputFormat自分でフィールド分割を行いたいので、 a を使用します。ただし、TextInputFormatUTF-8 でエンコードされたファイルしか処理できないようです。

MAPREDUCE-232によると、2008 年から保留中のパッチがありますが、回避策を見つけることができませんでした。私のオプションは何ですか？事前に UTF-8 でファイルを変換することはできません。

編集：Hadoopのソースコードを読んでいるときに、可能な回避策を見つけました。LineReader& フレンズはバイトのみを扱います。バイトを文字列に変換することはありません。ハードコードされた行末セパレータのみに一致し、バイト バッファを埋めます。ISO_8859_1 と UTF-8 は に対して同じバイト シーケンスを共有するため\n、次のように使用できます。

public class MyMapper extends Mapper<IntWritable, Text, Text, Text> {

    public void map(IntWritable key, Text value, Context context) 
                   throws IOException, InterruptedException {
        String data = new String(value.getBytes(),
                                 0, value.getLength(), 
                                 Charsets.ISO_8859_1)
        // [...]
    }
}

この解決策は受け入れられますか?

4

1 に答える 1

1

私は TextInputFormat について特別な経験はありませんが、あなたの言うことが本当なら (基になるコードは の 1 バイト値のみを探している\n)、サンプル コードを使用してそれらのバイトを String に変換することは完全に正当です。

アップデート：

実装の詳細に依存することについてのあなたの懸念は有効ですが、ここにあなたに有利な点がいくつかあります:

  1. 「バグ修正」は 2008 年以来未解決のままであり、すべてのエンコーディングを正しく処理しなかったために拒否されました (別名、これは正しく修正するためにさらに作業が必要な難しい問題です)。
  2. このTextクラスは明示的に utf-8 エンコーディングで動作します。全世界を壊すことなく後でそれを変更するのは難しい.
  3. ポイント2に続いて、ターゲットエンコーディングにはutf-8と互換性のある改行バイトシーケンスがあるため、元の生のバイトを常に取得できる限り、問題ありません。
于 2013-04-08T17:37:36.127 に答える