Skip to content

Enable the split-operator plan and native Iceberg writes by default #5644

Open

Description

@andygrove

What is the problem the feature request solves?

#6664 made Comet's Iceberg write path the default on every Spark version, and #6962 turned the default back off for 1.2.0, which ships native Iceberg writes as a supported, opt-in feature. spark.comet.write.iceberg.enabled (renamed from spark.comet.iceberg.write.enabled by #5306) is the one setting: it defaults to false, and when it is on it plans both the writer/committer split from #4658 and the iceberg-rust data-file writer from #5361. spark.comet.write.iceberg.splitOperator.enabled is a testing setting that plans the split operator with the native writer off. The split plan changes only the plan shape. The native writer writes the data files of each write its eligibility gate accepts; every other write falls back to iceberg-java's writer, and iceberg-java commits every write. With the setting off, Spark plans its own write operator, as in Comet 1.1.0.

This issue defines what has to be true before a release ships with the default on. Once the 1.2.0 branch is cut, the default can return to true on main, so that it runs as the default for a full release cycle before 1.3.0 (#6962). The 1.2.0 milestone is due on 2026-10-23 (#6550). Everything that had to be fixed before the default flipped is fixed (listed below). What is left is evidence, which CI and the nightly runs keep gathering with the default off: every Iceberg Spark test diff under dev/diffs/iceberg/ and both Iceberg write benchmarks set spark.comet.write.iceberg.enabled=true themselves.

Describe the potential solution

Before a release ships with the default on

Evidence gathered while CI and the nightly runs exercise the native writer:

Spark 3.4 gets the same defaults. No Iceberg Spark test job covers Iceberg 1.5.2, which the 3.4 profile pins, so on 3.4 the evidence is Comet's own suites.

Not blocking the default

Fixed before the defaults flipped

With the native writer on by default, each of these would have reached every user who writes Iceberg tables.

Split plan:

Native writer correctness:

Failure handling:

Memory and performance:

Coverage and evidence:

Done in #6664

  • spark.comet.write.iceberg.enabled moves from CATEGORY_TESTING to CATEGORY_EXEC and switches both layers, and the docs that describe the flags as off by default are updated: user-guide/latest/iceberg-writes.md, iceberg.md, operators.md, contributor-guide/iceberg-writes.md and the Iceberg write review skill
  • Release note: a 1.2.0 upgrade-guide entry names the setting and how to turn it off. Iceberg write plans show IcebergCommit over IcebergWrite (or CometIcebergWrite) in place of Spark's AppendData, OverwriteByExpression, OverwritePartitionsDynamic and ReplaceData exec nodes. The split happens at physical planning, so analyzed and optimized logical plans are unchanged, and listeners that read logical plans (lineage tools) are unaffected. Code that matches Spark's physical write nodes will not find them.

Done in #6962

  • spark.comet.write.iceberg.enabled defaults to false again, so 1.2.0 ships the native writer as a supported, opt-in feature. The user guide, the FAQ, the contributor guide, the roadmap and the Iceberg write review skill describe it as opt-in, and the 1.2.0 upgrade-guide entry covers the move from 1.1.0's testing settings to the one supported setting.

Additional context

Part of #5649. Refreshed on 2026-10-13, after #6664 merged, and on 2026-10-16, after #6962 merged. Earlier versions folded in the original list from 2026-09-02 and the issues the 2026-09-23 audit added (#6138 to #6148). Related: #4658, #5298, #5361.

Activity

  1. self-assigned this
    on Oct 5, 2026
  2. modified the milestones: 1.2.0, 1.3.0 on Oct 13, 2026
  3. Visorgood commented on Nov 14, 2026

    @Visorgood
    Contributor

    @andygrove I'd like to take the manifest metrics parity item from the checklist above, unless you've already started on it.

    Plan: for each data type, write the same rows through iceberg-java and the native writer, then compare value, null and NaN counts and lower/upper bounds per column in the resulting manifests.

    Two questions:

    1. Spark 3.4 has been dropped, so should this cover only Iceberg 1.8.1, 1.10.0 and 1.11.0, or is 1.5.2 still needed?
    2. Should the tests go into Comet's own suites (next to the NaN count checks in CometIcebergWriteActionSuite) or into the Iceberg CI jobs?

    If it helps, I can open a separate sub-issue for this so it can be assigned and tracked.

  4. andygrove commented on Nov 14, 2026

    @andygrove
    MemberAuthor

    @andygrove I'd like to take the manifest metrics parity item from the checklist above, unless you've already started on it.

    Plan: for each data type, write the same rows through iceberg-java and the native writer, then compare value, null and NaN counts and lower/upper bounds per column in the resulting manifests.

    Two questions:

    1. Spark 3.4 has been dropped, so should this cover only Iceberg 1.8.1, 1.10.0 and 1.11.0, or is 1.5.2 still needed?
    2. Should the tests go into Comet's own suites (next to the NaN count checks in CometIcebergWriteActionSuite) or into the Iceberg CI jobs?

    If it helps, I can open a separate sub-issue for this so it can be assigned and tracked.

    Thanks @Visorgood.

    1. I think we can drop 1.5.2
    2. Probably should go into Comet suite? I haven't looked in detail
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions