首先,我根据集群运行apachepig版本0.11.0-cdh4.3.0(rexported)。然而,我的构建使用0.11.0-cdh4.5.0,我知道这不是一个明智的决定,但我不认为这与我在这里遇到的问题有关,因为它都是pig v0.11.0
我有一个脚本,它的结构如下(两个自定义udf都返回databytearray类型,这是一个有效的pig类型afaik):
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将其分为两个mapreduce作业。我不确定立方体尺寸是发生在第一次还是第二次,但我怀疑它发生在第一次作业的缩减阶段。
所以第二个作业的Map阶段只不过是读取中间数据,这就是发生这种情况的地方:
“在流中发现意外的数据类型49。”@org.apache.pig.data.binintersedes:422
我看到这个数字是48和49,在班里都不存在:
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
但由于这是Pig本身的中间产量,我不太明白它可能出了什么问题。我的自定义udf都返回一个有效的类型,我希望pig只使用它知道的类型来存储。
任何帮助都将不胜感激。
1条答案
按热度按时间wyyhbhjk1#
巧合的是,在pig的中间存储中用于行拆分的序列也出现在自定义udf返回的一个字节数组中。这会导致pig在中间的某个地方将行拆分,并开始查找数据类型指示。由于它正好位于行的中间,因此没有有效的数据类型指示,因此会出现错误。
我还不完全确定我将如何着手解决这个问题@winnienicklaus已经提供了一个很好的解决方案,它将脚本分为两部分并存储在两部分之间。另一个选择是让udf返回base64编码的字节数组。这样就永远不会与pig中间存储发生冲突,因为它使用ctrl-a、ctrl-b、ctrl-c、tuple指示符,这些字符都不是字母数字字符。