唯一有点触及主题的帖子在这里,但它不能解决我的问题。
以下是我们收集Parquet地板到本地备份的问题:
$ hadoop fs -getmerge /dir/on/hdfs /local/dir
所犯的错误是,我们认为parquet多个文件组织是由于hdfs编写的,但我们不明白它实际上是parquet文件“正常”组织。所以(不是很聪明)我们使用了hdfs的getmerge来做备份。问题是,我们的数据已经被删除,我们现在正在努力恢复它。
在分析(并阅读文档)Parquet时,我们发现所有文件最初都是由块组成的,块中包含数据+元数据,位于幻数“par1”之间,并将其添加到2-\u metadata和\u common\u metadata-元数据文件中。
通过观察getmerge按顺序处理文件(hdfs上的原始parquet目录),我想出了一个脚本,它将2'par1'之间的数据转换为块文件。前两个生成的文件是(\u common\u metadata,\u metadata)。
filePrefix='part-'
finalFilePrefix='part-r-'
awk 'NR%2==0{ print $0 > "part-"i++ }' RS='PAR1' $1
nbFiles=$(ls -lah | grep 'part-' | wc -l)
for num in $(seq 0 $nbFiles)
do
fileName="$filePrefix$num"
lastName=""
if [ "$num" -eq "0" ]; then
lastName="_common_metadata"
awk '{print "PAR1" $0 "PAR1"}' $fileName > $lastName
else
if [ "$num" -eq "1" ]; then
lastName="_metadata"
awk '{print "PAR1" $0 "PAR1"}' $fileName > $lastName
else
if [ -e $fileName ]; then
count=$( printf "%05d" $(($num-2)) )
lastName="$finalFilePrefix$count.gz.parquet"
awk '{print "PAR1" $0 "PAR1"}' $fileName > $lastName
fi
fi
fi
echo $lastName
truncate --size=-1 $lastName
rm -f "$fileName"
done
mv $1 $1.backup
mkdir $1
mv _* $1
mv part* $1
对剧本的一些观察:
它在参数中接受一个“getmerge”parquet文件
创建的所有零件都被移动到以原始文件命名的目录中(后者被重命名为filename.backup)
必须在每个文件的末尾取一个字节-truncate-根据经验,这是因为spark sc.load.parquet()无法读取元数据文件)
最终我们使用hadoop fs-put将其上传到hdfs。
尝试将其作为Dataframe加载,正如我所说,元数据(和公共元数据文件)读取正常,但在加载块时仍然存在错误:
代码:
val newDataDF = sqlContext.read.parquet("/tmp/userActionLog2-leclerc-culturel-2016.09.04.parquet")
newDataDF.take(1)
错误:
newDataDF: org.apache.spark.sql.DataFrame = [bson: binary]
org.apache.spark.SparkException: Job aborted due to stage failure: Task 0 in stage 1.0 failed 4 times, most recent failure: Lost task 0.3 in stage 1.0 (TID 5, hdp-node4.affinytix.com): java.io.IOException: can not read class org.apache.parquet.format.PageHeader: don't know what type: 13
at org.apache.parquet.format.Util.read(Util.java:216)
at org.apache.parquet.format.Util.readPageHeader(Util.java:65)
at org.apache.parquet.hadoop.ParquetFileReader$WorkaroundChunk.readPageHeader(ParquetFileReader.java:668)
at org.apache.parquet.hadoop.ParquetFileReader$Chunk.readAllPages(ParquetFileReader.java:546)
at org.apache.parquet.hadoop.ParquetFileReader.readNextRowGroup(ParquetFileReader.java:496)
at org.apache.spark.sql.execution.datasources.parquet.UnsafeRowParquetRecordReader.checkEndOfRowGroup(UnsafeRowParquetRecordReader.java:604)
at org.apache.spark.sql.execution.datasources.parquet.UnsafeRowParquetRecordReader.loadBatch(UnsafeRowParquetRecordReader.java:218)
at org.apache.spark.sql.execution.datasources.parquet.UnsafeRowParquetRecordReader.nextKeyValue(UnsafeRowParquetRecordReader.java:196)
at org.apache.spark.rdd.SqlNewHadoopRDD$$anon$1.hasNext(SqlNewHadoopRDD.scala:194)
at scala.collection.Iterator$$anon$11.hasNext(Iterator.scala:327)
at scala.collection.Iterator$$anon$11.hasNext(Iterator.scala:327)
at scala.collection.Iterator$$anon$10.hasNext(Iterator.scala:308)
at scala.collection.Iterator$class.foreach(Iterator.scala:727)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1157)
at scala.collection.generic.Growable$class.$plus$plus$eq(Growable.scala:48)
at scala.collection.mutable.ArrayBuffer.$plus$plus$eq(ArrayBuffer.scala:103)
at scala.collection.mutable.ArrayBuffer.$plus$plus$eq(ArrayBuffer.scala:47)
at scala.collection.TraversableOnce$class.to(TraversableOnce.scala:273)
at scala.collection.AbstractIterator.to(Iterator.scala:1157)
at scala.collection.TraversableOnce$class.toBuffer(TraversableOnce.scala:265)
at scala.collection.AbstractIterator.toBuffer(Iterator.scala:1157)
at scala.collection.TraversableOnce$class.toArray(TraversableOnce.scala:252)
at scala.collection.AbstractIterator.toArray(Iterator.scala:1157)
at org.apache.spark.sql.execution.SparkPlan$$anonfun$5.apply(SparkPlan.scala:212)
at org.apache.spark.sql.execution.SparkPlan$$anonfun$5.apply(SparkPlan.scala:212)
at org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkContext.scala:1881)
at org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkContext.scala:1881)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
at org.apache.spark.scheduler.Task.run(Task.scala:89)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:214)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: parquet.org.apache.thrift.protocol.TProtocolException: don't know what type: 13
at parquet.org.apache.thrift.protocol.TCompactProtocol.getTType(TCompactProtocol.java:806)
at parquet.org.apache.thrift.protocol.TCompactProtocol.readFieldBegin(TCompactProtocol.java:500)
at org.apache.parquet.format.InterningProtocol.readFieldBegin(InterningProtocol.java:158)
at org.apache.parquet.format.PageHeader.read(PageHeader.java:828)
at org.apache.parquet.format.Util.read(Util.java:213)
... 32 more
鉴于我们的数据在这里岌岌可危,如果有人有任何想法,可以帮助,我热烈感谢他(er)提前。
再见
1条答案
按热度按时间7xllpg7q1#
我已经回答了这个问题。
我一开始的基本想法还可以。问题是awk(在解决方案脚本中)正在添加大量字符。所以在那之后Parquet地板块就不可读了。
解决方案是通过编程(python、perl…)来操作合并的文件。下面是我提出的python解决方案。除了不添加无用字符外,它与前一个相同。
代码:
观察:parquet文件不能太大,因为python函数将整个内容作为字符串加载到内存中(几十兆字节就可以了)!必须在linux/unix上执行,因为最后的系统调用是基于unix的。
再见