[ 
https://issues.apache.org/jira/browse/SPARK-16632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15574253#comment-15574253
 ] 

Dongjoon Hyun commented on SPARK-16632:
---------------------------------------

{code}
spark-2.0:branch-2.0$ git log --oneline | grep SPARK-16632
933d76a [SPARK-16632][SQL] Revert PR #14272: Respect Hive schema when merging 
parquet schema
f9367d6 [SPARK-16632][SQL] Use Spark requested schema to guide vectorized 
Parquet reader initialization
c2b5b3c [SPARK-16632][SQL] Respect Hive schema when merging parquet schema.
{code}

> Vectorized parquet reader fails to read certain fields from Hive tables
> -----------------------------------------------------------------------
>
>                 Key: SPARK-16632
>                 URL: https://issues.apache.org/jira/browse/SPARK-16632
>             Project: Spark
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 2.0.0
>         Environment: Hive 1.1 (CDH)
>            Reporter: Marcelo Vanzin
>            Assignee: Marcelo Vanzin
>             Fix For: 2.0.1, 2.1.0
>
>
> The vectorized parquet reader fails to read certain tables created by Hive. 
> When the tables have type "tinyint" or "smallint", Catalyst converts those to 
> "ByteType" and "ShortType" respectively. But when Hive writes those tables in 
> parquet format, the parquet schema in the files contains "int32" fields.
> To reproduce, run these commands in the hive shell (or beeline):
> {code}
> create table abyte (value tinyint) stored as parquet;
> create table ashort (value smallint) stored as parquet;
> insert into abyte values (1);
> insert into ashort values (1);
> {code}
> Then query them with Spark 2.0:
> {code}
> spark.sql("select * from abyte").show();
> spark.sql("select * from ashort").show();
> {code}
> You'll see this exception (for the byte case):
> {noformat}
> 16/07/13 12:24:23 ERROR datasources.InsertIntoHadoopFsRelationCommand: 
> Aborting job.
> org.apache.spark.SparkException: Job aborted due to stage failure: Task 0 in 
> stage 0.0 failed 4 times, most recent failure: Lost task 0.3 in stage 0.0 
> (TID 3, scm-centos71-iqalat-2.gce.cloudera.com): 
> org.apache.spark.SparkException: Task failed while writing rows
>       at 
> org.apache.spark.sql.execution.datasources.DefaultWriterContainer.writeRows(WriterContainer.scala:261)
>       at 
> org.apache.spark.sql.execution.datasources.InsertIntoHadoopFsRelationCommand$$anonfun$run$1$$anonfun$apply$mcV$sp$1.apply(InsertIntoHadoopFsRelationCommand.scala:143)
>       at 
> org.apache.spark.sql.execution.datasources.InsertIntoHadoopFsRelationCommand$$anonfun$run$1$$anonfun$apply$mcV$sp$1.apply(InsertIntoHadoopFsRelationCommand.scala:143)
>       at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:70)
>       at org.apache.spark.scheduler.Task.run(Task.scala:85)
>       at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:274)
>       at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>       at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>       at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
>       at 
> org.apache.spark.sql.execution.vectorized.OnHeapColumnVector.getByte(OnHeapColumnVector.java:159)
>       at 
> org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIterator.processNext(Unknown
>  Source)
>       at 
> org.apache.spark.sql.execution.BufferedRowIterator.hasNext(BufferedRowIterator.java:43)
>       at 
> org.apache.spark.sql.execution.WholeStageCodegenExec$$anonfun$8$$anon$1.hasNext(WholeStageCodegenExec.scala:370)
>       at 
> org.apache.spark.sql.execution.datasources.DefaultWriterContainer$$anonfun$writeRows$1.apply$mcV$sp(WriterContainer.scala:253)
>       at 
> org.apache.spark.sql.execution.datasources.DefaultWriterContainer$$anonfun$writeRows$1.apply(WriterContainer.scala:252)
>       at 
> org.apache.spark.sql.execution.datasources.DefaultWriterContainer$$anonfun$writeRows$1.apply(WriterContainer.scala:252)
>       at 
> org.apache.spark.util.Utils$.tryWithSafeFinallyAndFailureCallbacks(Utils.scala:1325)
>       at 
> org.apache.spark.sql.execution.datasources.DefaultWriterContainer.writeRows(WriterContainer.scala:258)
>       ... 8 more
> {noformat}
> This works when you point Spark directly at the files (instead of using the 
> metastore data), or when you disable the vectorized parquet reader.
> The root cause seems to be that Hive creates these tables with a 
> not-so-complete schema:
> {noformat}
> $ parquet-tools schema /tmp/byte.parquet 
> message hive_schema {
>   optional int32 value;
> }
> {noformat}
> There's no indication that the field is a 32-bit field used to store 8-bit 
> values. When the ParquetReadSupport code tries to consolidate both schemas, 
> it just chooses whatever is in the parquet file for primitive types (see 
> ParquetReadSupport.clipParquetType); the vectorized reader uses the catalyst 
> schema, which comes from the Hive metastore, and says it's a byte field, so 
> when it tries to read the data, the byte data stored in "OnHeapColumnVector" 
> is null.
> I have tested a small change to {{ParquetReadSupport.clipParquetType}} that 
> fixes this particular issue, but I haven't run any other tests, so I'll do 
> that while I wait for others to chime in and maybe tell me that's not the 
> right place to fix this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

Reply via email to