Skip to content

Support top-level VariantType in Comet MapInArrow and MapInPandas transport #5437

Description

@peterxcli

What is the problem the feature request solves?

Spark 4.1 supports top-level Variant values through Arrow Python transport. Its JVM Arrow bridge maps Variant to a Struct<value, metadata> and marks the metadata child (ArrowUtils); PySpark converts that shape to and from VariantVal (PySpark Arrow conversion, Variant value conversion).

Comet currently excludes any Variant-bearing input or output from its accelerated MapInArrow/MapInPandas rewrite in EliminateRedundantTransitions. This is a safe fallback, but it leaves the Python batch transport capability untracked.

Describe the potential solution

  • Support direct, top-level Variant inputs and outputs in Comet MapInArrow and MapInPandas operators.
  • Translate only at the Python boundary between Comet's canonical parent arrow.parquet.variant marker and Spark/PyArrow's Variant child marker.
  • Preserve exact [value, metadata] order, Binary children, field names, SQL-null parent bitmap, Variant JSON null, and zero-row streams in both directions.
  • Reject malformed layouts and retain fallback for nested Variant or unsupported Python operator families.

Add parity and plan tests for MapInArrow and MapInPandas identity functions, projected fields around Variant, nullable values, and Python-produced Variant output. Verify Spark receives VariantType, not an ordinary Struct.

Additional context

#5386 tracks scalar Arrow Python UDF expansion and #5123 tracks grouped/window/apply operators generally; neither specifies Variant's logical metadata and layout. #5407 and #5425 define the canonical Comet-side Field contract.

Nested Variant and the other Python operator families remain separate until explicitly supported.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions