-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-53659][SQL] Infer Variant shredding schema when writing to Parquet #52406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
gene-db
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cashmand Thanks for this awesome feature! I left a few comments.
| /** | ||
| * | ||
| * Infer a schema when there are Variant values in the shredding schema. | ||
| * Only VariantType values at the top level or nested in struct fields are replaced. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are they replaced with?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant replacing VariantType in the schema with the shredding schema, but I'll change the comment to be are shredded.
| * Infer a schema when there are Variant values in the shredding schema. | ||
| * Only VariantType values at the top level or nested in struct fields are replaced. | ||
| * VariantType nested in arrays or maps are not modified. | ||
| * @param schema The original schema containing VariantType. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this require that the schema must contain a VariantType, and does the VariantType have to be a top-level field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it operates on nested struct fields as well, and it's fine to call it if there's no VariantType at all in the schema, it will just be a no-op.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll change the description to be The original schema, with no shredding.
| .flatten | ||
| } | ||
|
|
||
| private def getValueAtPath(s: StructType, row: InternalRow, p: Seq[Int]): Option[VariantVal] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT:
| private def getValueAtPath(s: StructType, row: InternalRow, p: Seq[Int]): Option[VariantVal] = { | |
| private def getValueAtPath(schema: StructType, row: InternalRow, path: Seq[Int]): Option[VariantVal] = { |
Also, can we comment on what this will return? It looks it will return None of the field will be null?
| } | ||
|
|
||
| /** | ||
| * Update each VariantType with its inferred schema. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it return a copy of the schema (with the updates), or does it update in place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The former. I'll change the comment to Return a new schema, with each VariantType replaced its inferred shredding schema.
gene-db
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this feature!
LGTM
sql/catalyst/src/main/scala/org/apache/spark/sql/internal/SQLConf.scala
Outdated
Show resolved
Hide resolved
sql/catalyst/src/main/scala/org/apache/spark/sql/internal/SQLConf.scala
Outdated
Show resolved
Hide resolved
sql/catalyst/src/main/scala/org/apache/spark/sql/internal/SQLConf.scala
Outdated
Show resolved
Hide resolved
|
The last commit just update the config version doc, no need to wait for CI, thanks, merging to master! |
|
@cloud-fan @gene-db @cashmand, currently, variant is guarded by several internal configs, do you plan to enable variant support in Spark 4.1? |
Hi @pan3793, I think the only remaining item is to update the parquet reader and writer to recognize and write the Variant logical type annotation that was released in the latest version of parquet-java, and then we should be able to enable it by default. |
|
@cashmand, thanks for the information, sounds promising, I hope it can happen in 4.1 |
…quet ### What changes were proposed in this pull request? When writing Variant to Parquet, we want the shredding schema to adapt to the data being written on a per-file basis. This PR adds a new output writer that buffers the first few rows before starting the write, then uses the content of those rows to determine a shredding schema, and only then creates the Parquet writer with that schema. The heuristics for determining the shredding schema are currently fairly simple: if a field appears consistently with a consistent type, we create `value` and `typed_value`, and if it appears with an inconsistent type, we only create `value`. We drop fields that occur in less than 10% of sampled rows, and have an upper bound of 300 total fields (counting `value` and `typed_value` separately) to avoid creating excessively wide Parquet schemas, which can cause performance issues. ### Why are the changes needed? Allows Spark to make use of the [Variant shredding spec](https://github.com/apache/parquet-format/blob/master/VariantShredding.md) without requiring the user to manually set a shredding schema. ### Does this PR introduce _any_ user-facing change? Only if `spark.sql.variant.inferShreddingSchema` and `spark.sql.variant.writeShredding.enabled` are both set to true. They currently false by default. ### How was this patch tested? Unit tests in PR. ### Was this patch authored or co-authored using generative AI tooling? No. Closes apache#52406 from cashmand/variant_shredding_inference. Lead-authored-by: cashmand <david.cashman@databricks.com> Co-authored-by: Wenchen Fan <cloud0fan@gmail.com> Signed-off-by: Wenchen Fan <wenchen@databricks.com>
* Move GlutenStreamingQuerySuite to correct package * Add Spark 4.1 new test suites for Gluten * Enable new and existing Gluten test suites for Spark 4.1 UT * Update workflow trigger paths to exclude Spark 4.0 and 4.1 shims directories for clickhouse backend * Add support for Spark 4.1 in build script * Merge Spark 4.1.0 sql-tests into Gluten Spark 4.1 (three-way merge) Three-way merge performed using Git: - Base: Spark 4.0.1 (29434ea766b) - Left: Spark 4.1.0 (e221b56be7b) - Right: Gluten Spark 4.1 backends-velox Summary: - Auto-merged: 165 files - New tests added: 31 files (collations, edge cases, recursion, spatial, etc.) - Modified tests: 134 files - Deleted tests: 2 files (collations.sql -> split into 4 files, timestamp-ntz.sql) Conflicts resolved: - inputs/timestamp-ntz.sql: Right deleted + Left modified -> DELETED (per resolution rule) New test suites from Spark 4.1.0: - Collations (4 files): aliases, basic, padding-trim, string-functions - Edge cases (6 files): alias-resolution, extract-value, join-resolution, etc. - Advanced features: cte-recursion, generators, kllquantiles, thetasketch, time - Name resolution: order-by-alias, session-variable-precedence, runtime-replaceable - Spatial functions: st-functions (ANSI and non-ANSI variants) - Various resolution edge cases Total files after merge: 671 (up from 613) * Enable additional Spark 4.1 SQL tests by resolving TODOs * Add new Spark 4.1 test files to VeloxSQLQueryTestSettings * [Fix] Replace `RuntimeReplaceable` with its `replacement` to fix UT. see apache/spark#50287 * [4.1.0] Exclude "infer shredding with mixed scale" see apache/spark#52406 * [Fix] Implement Kryo serialization for CachedColumnarBatch see apache/spark#50599 * [4.1.0] Exclude GlutenMapStatusEndToEndSuite and configure parallelism see apache/spark#50230 * [4.1.0] Exclude Spark Structure Steaming tests in Gluten see - apache/spark#52473 - apache/spark#52870 - apache/spark#52891 * [4.1.0] Exclude failing SQL tests on Spark 4.1 * Replace SparkException.require with standard require in ColumnarCachedBatchSerializer to work across different spark versions * [Fix] Replace `RuntimeReplaceable` with its `replacement` to fix UT. see apache/spark#50287 * Exclude Spark 4.0 and 4.1 paths in clickhouse_be_trigger using `!` prefix * [Fix] Update GlutenShowNamespacesParserSuite to use GlutenSQLTestsBaseTrait
What changes were proposed in this pull request?
When writing Variant to Parquet, we want the shredding schema to adapt to the data being written on a per-file basis. This PR adds a new output writer that buffers the first few rows before starting the write, then uses the content of those rows to determine a shredding schema, and only then creates the Parquet writer with that schema.
The heuristics for determining the shredding schema are currently fairly simple: if a field appears consistently with a consistent type, we create
valueandtyped_value, and if it appears with an inconsistent type, we only createvalue. We drop fields that occur in less than 10% of sampled rows, and have an upper bound of 300 total fields (countingvalueandtyped_valueseparately) to avoid creating excessively wide Parquet schemas, which can cause performance issues.Why are the changes needed?
Allows Spark to make use of the Variant shredding spec without requiring the user to manually set a shredding schema.
Does this PR introduce any user-facing change?
Only if
spark.sql.variant.inferShreddingSchemaandspark.sql.variant.writeShredding.enabledare both set to true. They currently false by default.How was this patch tested?
Unit tests in PR.
Was this patch authored or co-authored using generative AI tooling?
No.