You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Ivan (Jira)" <ji...@apache.org> on 2021/09/20 00:24:00 UTC

[jira] [Updated] (SPARK-36803) ClassCastException: optional int32 col-0 is not a group when reading legacy Parquet files

     [ https://issues.apache.org/jira/browse/SPARK-36803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivan updated SPARK-36803:
-------------------------
    Description: 
When reading Parquet files that have been written in legacy mode and schema evolution, we observed that 2-level LIST annotated types are traversed incorrectly. 

The root cause is the imprecise check on the underlying element type for Array types (and potentially Map types but I have not checked those yet) that happens here: [https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetRowConverter.scala#L606.|https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetRowConverter.scala#L606]

When we write arrays in legacy mode, we use 2-level wrapping like this:

 

{{optional group col-0 (LIST) \{
  repeated group array {
    optional group col-0 {
      optional float col-0;
    }
  }
}}}

It works just fine if the corresponding Spark schema for all of the Parquet files is like this:

 

{{ArrayType(StructType(
  StructField(col-0, StructType(
    StructField(col-0, FloatType, true)
  ))
))}}

When ParquetRowConverter tries to unwrap ArrayType, it checks if the underlying types between Parquet and Spark match. In this case, they do, so it is all good.

The problem arises when (due to schema evolution), parquet schema does not match the Spark one, for example:

 

{{ArrayType(StructType(
  StructField(col-1, LongType, true), <-- added field
  StructField(col-0, StructType(
    StructField(col-0, FloatType, true)
  ))
))}}

Now the L606 in ParquetRowConverter: DataType.equalsIgnoreCompatibleNullability(guessedElementType, elementType) would return false because the check matches the types exactly and in this case they don’t match. The code assumes that we are working with 3 level lists and would incorrectly remove the “dummy” level from the Parquet schema, leaving us with the following:

 

{{optional float col-0
 
StructType(StructField(col-0, FloatType, true))}}

The actual error varies depending on column names - in this case struct type name matches primitive type name so we end up with optional float col-0 is not a group. In other case, it could fail with IndexOutOfBoundException or NoSuchElementException when the column name is not found in the struct.

 

The reason it works with 3-level list, that DataType.equalsIgnoreCompatibleNullability(guessedElementType, elementType) always evaluates to false, we remove the “dummy” level and perform struct match which takes into account schema evolution here: [https://github.com/databricks/runtime/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetRowConverter.scala#L210].

So the check should DataType.equalsIgnoreCompatibleNullability should probably be something like DataType.partiallyContainsSchema, where we can check that the guessedElementType is a subset of the elementType.

IMHO, this creates an impression that the code works rather incidentally for legacy mode due to the check.

 

Logs for converting the offending type for different cases:
 
 

> ClassCastException: optional int32 col-0 is not a group when reading legacy Parquet files 
> ------------------------------------------------------------------------------------------
>
>                 Key: SPARK-36803
>                 URL: https://issues.apache.org/jira/browse/SPARK-36803
>             Project: Spark
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 3.1.2
>            Reporter: Ivan
>            Priority: Major
>
> When reading Parquet files that have been written in legacy mode and schema evolution, we observed that 2-level LIST annotated types are traversed incorrectly. 
> The root cause is the imprecise check on the underlying element type for Array types (and potentially Map types but I have not checked those yet) that happens here: [https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetRowConverter.scala#L606.|https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetRowConverter.scala#L606]
> When we write arrays in legacy mode, we use 2-level wrapping like this:
>  
> {{optional group col-0 (LIST) \{
>   repeated group array {
>     optional group col-0 {
>       optional float col-0;
>     }
>   }
> }}}
> It works just fine if the corresponding Spark schema for all of the Parquet files is like this:
>  
> {{ArrayType(StructType(
>   StructField(col-0, StructType(
>     StructField(col-0, FloatType, true)
>   ))
> ))}}
> When ParquetRowConverter tries to unwrap ArrayType, it checks if the underlying types between Parquet and Spark match. In this case, they do, so it is all good.
> The problem arises when (due to schema evolution), parquet schema does not match the Spark one, for example:
>  
> {{ArrayType(StructType(
>   StructField(col-1, LongType, true), <-- added field
>   StructField(col-0, StructType(
>     StructField(col-0, FloatType, true)
>   ))
> ))}}
> Now the L606 in ParquetRowConverter: DataType.equalsIgnoreCompatibleNullability(guessedElementType, elementType) would return false because the check matches the types exactly and in this case they don’t match. The code assumes that we are working with 3 level lists and would incorrectly remove the “dummy” level from the Parquet schema, leaving us with the following:
>  
> {{optional float col-0
>  
> StructType(StructField(col-0, FloatType, true))}}
> The actual error varies depending on column names - in this case struct type name matches primitive type name so we end up with optional float col-0 is not a group. In other case, it could fail with IndexOutOfBoundException or NoSuchElementException when the column name is not found in the struct.
>  
> The reason it works with 3-level list, that DataType.equalsIgnoreCompatibleNullability(guessedElementType, elementType) always evaluates to false, we remove the “dummy” level and perform struct match which takes into account schema evolution here: [https://github.com/databricks/runtime/blob/master/sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetRowConverter.scala#L210].
> So the check should DataType.equalsIgnoreCompatibleNullability should probably be something like DataType.partiallyContainsSchema, where we can check that the guessedElementType is a subset of the elementType.
> IMHO, this creates an impression that the code works rather incidentally for legacy mode due to the check.
>  
> Logs for converting the offending type for different cases:
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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