feat: Add direct native shuffle execution optimization [experimental]

[andygrove]

Summary

This PR introduces an experimental optimization that allows the native shuffle writer to directly execute the child native plan instead of reading intermediate batches via JNI. This avoids the JNI round-trip for single-source native plans.

It also avoids double allocating the memory pool for the task, as described in #3921.

Current flow:

Native Plan → ColumnarBatch → JNI → ScanExec → ShuffleWriterExec

Optimized flow:

Native Plan → (directly in native) → ShuffleWriterExec

Configuration

The optimization is controlled by a new config option:

• spark.comet.exec.shuffle.directNative.enabled (default: false)

Scope

The optimization currently applies when:

• Native shuffle mode is enabled (spark.comet.shuffle.mode=native)
• The shuffle's child is a single-source native plan with CometNativeScanExec
• The partitioning is not RangePartitioning (which requires sampling)

Changes

File	Change
CometShuffleDependency.scala	Added childNativePlan field to pass native plan to writer
CometShuffleExchangeExec.scala	Added detection logic for single-source native plans
CometShuffleManager.scala	Pass native plan to shuffle writer
CometNativeShuffleWriter.scala	Use child native plan directly when available
CometConf.scala	Added COMET_SHUFFLE_DIRECT_NATIVE_ENABLED config option
CometDirectNativeShuffleSuite.scala	Comprehensive test suite with 15 tests

Test plan

• Added CometDirectNativeShuffleSuite with 15 tests covering:
  • Basic optimization with single scan source
  • Filter/project operators
  • Single partition and multi-partition cases
  • Config enable/disable behavior
  • Range partitioning fallback
  • JVM shuffle mode fallback
  • Various data types
  • Edge cases (empty tables, filtered results)
  • Correctness comparison between optimized and non-optimized paths
• Verified existing CometNativeShuffleSuite tests still pass (16/16)

🤖 Generated with Claude Code

[codecov-commenter]

Codecov Report

❌ Patch coverage is 63.43284% with 49 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.96%. Comparing base (f09f8af) to head (6132098).
⚠️ Report is 863 commits behind head on main.

Files with missing lines	Patch %	Lines
...t/execution/shuffle/CometShuffleExchangeExec.scala	20.51%	27 Missing and 4 partials ⚠️
...t/execution/shuffle/CometNativeShuffleWriter.scala	79.06%	9 Missing and 9 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #3230      +/-   ##
============================================
+ Coverage     56.12%   59.96%   +3.83%     
- Complexity      976     1433     +457     
============================================
  Files           119      170      +51     
  Lines         11743    15819    +4076     
  Branches       2251     2616     +365     
============================================
+ Hits           6591     9486    +2895     
- Misses         4012     5008     +996     
- Partials       1140     1325     +185     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[andygrove]

@viirya I'm curious what you think about this idea. Does it make sense?

[viirya]

Looks like CometNativeShuffleWriter was added after, I am not familiar with its design. I took a quick look at the code. So it is basically a ShuffleWriter and executes a native plan to write inputs from an iterator of ColumnarBatch into shuffle file. Although it executes a native plan to write, its input is still coming from JVM even its input plan maybe a native plan too.

So this idea is to avoid the JVM/JNI overhead on the input. It sounds good.

[andygrove]

Looks like CometNativeShuffleWriter was added after, I am not familiar with its design. I took a quick look at the code. So it is basically a ShuffleWriter and executes a native plan to write inputs from an iterator of ColumnarBatch into shuffle file. Although it executes a native plan to write, its input is still coming from JVM even its input plan maybe a native plan too.

So this idea is to avoid the JVM/JNI overhead on the input. It sounds good.

Thanks for taking a look! I will keep experimenting with this.