parquet-java
parquet-java copied to clipboard
apache
PARQUET-2069: Allow list and array record types to be compatible.
This PR addresses the following JIRA entry: https://issues.apache.org/jira/browse/PARQUET-2069
ParquetMR breaks compatibility with itself by including a JSON representation of a schema that names a record "list", when it should be named "array" to match with the rest of the metadata. The proposed change allows Avro to detect that the "array" and "list" types are compatible.
I'm not sure how to add a whole new test. I'll see if I can figure it out. Also, the best way to test this would be to include the parquet file from the bug report, and I'm not sure where I'd put that in the source tree.
Any suggestions would be much appreciated.
I won't be able to add a test any time soon. Here's why.
First take note of the two parquet files attached to https://issues.apache.org/jira/browse/PARQUET-2069.
When I implement my own Parquet reader, the fix in this PR is able to make the "modified.parquet" file readable by ParquetMR. So what I did was copy org.apache.parquet.avro.TestBackwardCompatibility and modify it to read a new parquet file that I added to the resources folder, imitating the way I did it in my own reader. If I make my new test (TestArrayListCompatibility) point to original.parquet, it reads just fine, and the test passes. But if I make it point to modified.parquet, then I get an exception no matter whether this PR's fix is in or not. And the exception thrown is not the same as the exception described in the bug report. Instead, I get this:
org.apache.parquet.io.InvalidRecordException: Parquet/Avro schema mismatch: Avro field 'elements' not found
This has exposed some other bug(s) in Parquet/Avro. The thing is, since this isn't reproducible when I use my own reader, then the only way to reproduce it is to use tests built into ParquetMR. But due to ParquetMR's unfortunate reliance on runtime-generated code, it's impossible to run tests from the IDE, which makes them incredibly difficult to debug. If someone has a solution to that problem, I'd really appreciate some help.
OK, check out the code changes. I've redone this completely. Now what it does is try out the avro schema, and if that fails, it catches the exception and tries again with an avro schema that it converts from the parquet schema. This fixes not only 2069 but at least one other bug (whose number I can't remember).
@theosib-amazon I've hit a similar issue. Tried your fix and I see this error unfortunately. Can you test on Map<string, struct<bigint, string>>?
Warning, Avro schema doesn't match Parquet schema, falling back to conversion: java.lang.ClassCastException: required binary element (STRING) is not a group
Unknown error
java.lang.RuntimeException: Failed on record 0
at org.apache.parquet.cli.commands.CatCommand.run(CatCommand.java:86)
at org.apache.parquet.cli.Main.run(Main.java:157)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
at org.apache.parquet.cli.Main.main(Main.java:187)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.hadoop.util.RunJar.run(RunJar.java:221)
at org.apache.hadoop.util.RunJar.main(RunJar.java:136)
Caused by: org.apache.parquet.io.ParquetDecodingException: Can not read value at 0 in block -1 in file dbg.parquet
at org.apache.parquet.hadoop.InternalParquetRecordReader.nextKeyValue(InternalParquetRecordReader.java:264)
at org.apache.parquet.hadoop.ParquetReader.read(ParquetReader.java:132)
at org.apache.parquet.hadoop.ParquetReader.read(ParquetReader.java:136)
at org.apache.parquet.cli.BaseCommand$1$1.advance(BaseCommand.java:363)
at org.apache.parquet.cli.BaseCommand$1$1.
@islamismailov Can you provide me with a parquet file and changes to the test bench that reproduce this error?
I debugged this some more and it looks like some of the problem is coming from conversion between parquet and avro. Especially if you read parquetSchema, convert it to avro and set projection in avro schema format, it would get converted back to parquet and it will look different from the original.
System.out.println("ORIGINAL PARQUET " + fileSchema); Schema avroSchema = new AvroSchemaConverter(configuration).convert(fileSchema); MessageType parquetSchema = new AvroSchemaConverter(configuration).convert(avroSchema); System.out.println("RECONSTRUCTED PARQUET " + parquetSchema);
Yes, there are some major problems with the conversions between schemas that we should turn our attention to.
This is a "list" AND a "map" issue, not just list. If you're using Iceberg, good news: just apply this PR to your iceberg branch https://github.com/apache/iceberg/pull/3309
Link to the original issue: https://github.com/apache/iceberg/issues/2962
This worked for us. If you still want to fix it in parquet you might be interested in this change, or something along those lines (not recommended as I didn't fully test this change):
commit 1918276ec7f01279cb9906b9378cb8986f6ad3ea
Author: Islam Ismailov <[email protected]>
Date: Wed May 25 19:03:33 2022 +0000
Attempt a fix on avro-parquet conversion
diff --git a/parquet-avro/src/main/java/org/apache/parquet/avro/AvroSchemaConverter.java b/parquet-avro/src/main/java/org/apache/parquet/avro/AvroSchemaConverter.java
index 7d1f3cab..960aae22 100644
--- a/parquet-avro/src/main/java/org/apache/parquet/avro/AvroSchemaConverter.java
+++ b/parquet-avro/src/main/java/org/apache/parquet/avro/AvroSchemaConverter.java
@@ -190,7 +190,7 @@ public class AvroSchemaConverter {
} else if (type.equals(Schema.Type.ARRAY)) {
if (writeOldListStructure) {
return ConversionPatterns.listType(repetition, fieldName,
- convertField("array", schema.getElementType(), REPEATED, schemaPath));
+ convertField("list", schema.getElementType(), REPEATED, schemaPath));
} else {
return ConversionPatterns.listOfElements(repetition, fieldName,
convertField(AvroWriteSupport.LIST_ELEMENT_NAME, schema.getElementType(), schemaPath));
diff --git a/parquet-column/src/main/java/org/apache/parquet/schema/ConversionPatterns.java b/parquet-column/src/main/java/org/apache/parquet/schema/ConversionPatterns.java
index 8ae66f00..db1b546d 100644
--- a/parquet-column/src/main/java/org/apache/parquet/schema/ConversionPatterns.java
+++ b/parquet-column/src/main/java/org/apache/parquet/schema/ConversionPatterns.java
@@ -84,8 +84,7 @@ public abstract class ConversionPatterns {
LogicalTypeAnnotation.mapType(),
new GroupType(
Repetition.REPEATED,
- mapAlias,
- LogicalTypeAnnotation.MapKeyValueTypeAnnotation.getInstance(),
+ "map",
keyType,
valueType)
);
This patch of yours is cool. I can't tell you without further analysis if it's a universal fix, but how about you make your own PR but borrow the test I've included in my PR?