2016-06-15 21 views
5

Ho salvato una tabella DB remota in Hive usando il metodo saveAsTable, ora quando provo ad accedere ai dati della tabella Hive usando il comando CLI select * from table_name, It's dandomi l'errore qui sotto:parquet.io.ParquetDecodingException: Impossibile leggere il valore a 0 nel blocco -1 nel file

2016-06-15 10:49:36,866 WARN [HiveServer2-Handler-Pool: Thread-96]: 
thrift.ThriftCLIService (ThriftCLIService.java:FetchResults(681)) - 
Error fetching results: org.apache.hive.service.cli.HiveSQLException: 
java.io.IOException: parquet.io.ParquetDecodingException: Can not read 
value at 0 in block -1 in file hdfs: 

Qualche idea di cosa potrei fare storto qui?

+0

È possibile stampare lo schema dati per tale tabella? –

risposta

0

Sei in grado di utilizzare Avro anziché Parquet per memorizzare il tuo tavolo Hive? Mi sono imbattuto in questo problema perché stavo usando il tipo di dati Decimal di Hive, e Parquet di Spark non ha un bell'aspetto con Decimal. Se pubblichi lo schema della tabella e alcuni esempi di dati, il debug sarà più semplice.

Un'altra opzione possibile, from the DataBricks Forum, consiste nell'utilizzare un Doppio anziché un decimale, ma non era un'opzione per i miei dati, quindi non posso segnalare se funziona.

1

Ho avuto un errore simile (ma con un indice positivo in un blocco non negativo), e proveniva dal fatto che avevo creato i dati Parquet con alcuni tipi di dati Spark contrassegnati come non annullabili quando erano effettivamente nullo.

Nel mio caso, interpreto l'errore in quanto Spark tenta di leggere i dati da un determinato tipo non nullable e inciampa su un valore nullo imprevisto.

Per aggiungere confusione, dopo aver letto il file Parquet, Spark segnala con printSchema() che tutti i campi sono annullabili, che siano o meno. Tuttavia, nel mio caso, renderli in realtà null nel file Parquet originale ha risolto il problema.

Ora, il fatto che la domanda si verifichi a "0 nel blocco -1" è sospetto: sembra quasi che i dati non siano stati trovati, poiché il blocco -1 sembra che Spark non abbia nemmeno iniziato a leggere nulla (solo un'ipotesi).

0

Sembra un problema di disallineamento dello schema qui. Se si imposta lo schema come non annullabile e si crea il proprio dataframe con il valore Nessuno, Spark ti getterebbe ValueError: questo campo non è annullabile, ma ha ottenuto l'errore Nessuno.

[Pyspark]

from pyspark.sql.functions import * #udf, concat, col, lit, ltrim, rtrim 
from pyspark.sql.types import * 

schema = ArrayType(StructType([StructField('A', IntegerType(), nullable=False)])) 
# It will throw "ValueError". 
df = spark.createDataFrame([[[None]],[[2]]],schema=schema) 
df.show() 

Ma non è il caso se si utilizza UDF.

Utilizzando lo stesso schema, se si utilizza udf per la trasformazione, non si genera ValueError anche se il proprio udf restituisce un None. Ed è il luogo in cui avviene la mancata corrispondenza dello schema di dati.

Ad esempio:

df = spark.createDataFrame([[[1]],[[2]]], schema=schema) 

def throw_none(): 
    def _throw_none(x): 
     if x[0][0] == 1: 
      return [['I AM ONE']] 
     else: 
      return x 
    return udf(_throw_none, schema) 

# since value col only accept intergerType, it will throw null for 
# string "I AM ONE" in the first row. But spark did not throw ValueError 
# error this time ! This is where data schema type mismatch happen ! 
df = df.select(throw_none()(col("value")).name('value')) 
df.show() 

enter image description here

Poi, la seguente scrittura parquet e leggere vi proietterà l'errore parquet.io.ParquetDecodingException.

df.write.parquet("tmp") 
spark.read.parquet("tmp").collect() 

Quindi state molto attenti al valore nullo se si utilizza UDF, restituire il tipo di dati a destra nella vostra UDF. E a meno che non sia necessario, non impostare nullable = False nel tuo StructField.Set nullable = True risolverà tutto il problema.

Problemi correlati