1

まず最初に、クラスターに従って Apache Pig バージョン 0.11.0-cdh4.3.0 (再エクスポート) を実行しています。ただし、私のビルドでは 0.11.0-cdh4.5.0 を使用していますが、これは賢明な決定ではありませんが、両方とも Pig v0.11.0 であるため、ここで発生している問題とは関係ないと思います

構造的に次のようなスクリプトがあります (両方のカスタム udf が DataByteArray 型を返します。これは有効な Pig 型であることがわかります)。

LOAD USING parquet.pig.ParquetLoader();

FOREACH GENERATE some of the fields

GROUP BY (a,b,c)

FOREACH GENERATE FLATTEN(group) AS (a,b,c), CustomUDF1(some_value) AS d

FOREACH GENERATE FLATTEN(CubeDimensions(a,b,c)) AS (a,b,c) , d

GROUP BY (a,b,c)

FOREACH GENERATE FLATTEN(group) AS (a,b,c), SUM(some_value), CustomUDF2(some_value)

STORE USING parquet.pig.ParquetStorer();

Pig はこれを 2 つの mapreduce ジョブに分割します。CubeDimensions が最初のジョブで発生するか、2 番目で発生するかはわかりませんが、最初のジョブの削減段階で発生すると思われます。

したがって、2 番目のジョブのマッピング ステージでは、中間データを読み取るだけで、次のことが起こります。

「予期しないデータ型 49 がストリームに見つかりました。」@ org.apache.pig.data.BinInterSedes:422

番号が 48 と 49 の両方であり、BinInterSedes クラスにはどちらも存在しないことがわかりました。

http://grepcode.com/file/repository.cloudera.com/content/repositories/releases/org.apache.pig/pig/0.11.0-cdh4.3.0/org/apache/pig/data/BinInterSedes.java? av=f

しかし、これは豚自身の中間出力であるため、どこで問題が発生した可能性があるのか​​ よくわかりません。私のカスタム UDF はどちらも有効な型を返します。Pig は、認識している型のみを使用して確実に保存することを期待しています。

どんな助けでも大歓迎です。

4

1 に答える 1

1

偶然にも、Pig の中間ストレージで行分割に使用されるシーケンスが、カスタム UDF によって返されるバイト配列の 1 つで発生するようです。これにより、pig は途中で行を分割し、データ型の表示を探し始めます。行の途中にあるため、有効なデータ型の指示がないため、エラーになります。

これをどのように修正するつもりなのか、まだ完全にはわかりません。@WinnieNicklausは、スクリプトを2つに分割してその間に保存することで、すでに優れたソリューションを提供しています。もう 1 つのオプションは、UDF が Base64 でエンコードされたバイト配列を返すようにすることです。そうすれば、PIG 中間ストレージは CTRL-A、CTRL-B、CTRL-C、TUPLE-INDICATOR を使用し、いずれも英数字ではないため、PIG 中間ストレージと競合することは決してありません。

于 2014-05-15T08:35:44.917 に答える