Skip to content

[EPIC] Distributed Execution for Reads/Writes #23

Open

Description

@NoahKusaba

Goal

Run Iceberg reads and writes in parallel on
Ballista executors. A codec in
another process has to name each node's type, read what it was built from, and
rebuild an equivalent node from those parts alone. This epic tracks the
datafusion-iceberg and iceberg-rust changes that make that work well.

Most of this is likely relevant to datafusion-distributed too, though it's
written from Ballista's perspective. datafusion-distributed keeps its own
DataSourceExec integration (built on WorkUnitFeeds), so it needs the
planned file tasks to be reachable, but not necessarily the grouping below.
If I've missed anything, let me know and I'll update this epic.

Last updated 2026-11-03.

Open

Partitioned scans (highest priority)

IcebergDataSource reports UnknownPartitioning(1), so every scan runs as one
task on one executor, which lists and reads every file. It also limits writes:
Ballista drops round-robin repartitions, so INSERT INTO t SELECT … FROM <iceberg table> into a table with no identity or bucket partition field writes
from a single task.

Writes

Scans

Catalogs and cached schemas

iceberg-rust (not opened yet, most important first)

  • A scan on a runtime that has shut down returns no rows instead of failing.
  • The REST catalog never refreshes its OAuth token, so a long-lived
    scheduler fails to plan once its token expires.
  • Debug output of FileIO/StorageConfig prints storage credentials.
  • To investigate: whether FileIO can refresh catalog-vended storage
    credentials during a long job.

Done

Dropped

Activity

  1. changed the title [-][EPIC] Distributed execution with Ballista[/-] [+][EPIC] Distributed execution[/+] on Sep 29, 2026
  2. changed the title [-][EPIC] Distributed execution[/-] [+][EPIC] Distributed Execution for Reads/Writes[/+] on Sep 29, 2026
  3. NoahKusaba commented on Sep 29, 2026

    @NoahKusaba
    ContributorAuthor

    cc @mbutrovich

    At your suggestion I put together an EPIC to track unfinished work for distributed datafusion execution, which is relevant for both ballista and datafusion-distributed.

  4. NoahKusaba commented on Sep 29, 2026

    @NoahKusaba
    ContributorAuthor
  5. NoahKusaba commented on Sep 29, 2026

    @NoahKusaba
    ContributorAuthor

    cc @alexanderbianchi --> I know you represent the interested party from datafusion-distributed .

  6. NoahKusaba commented on Sep 29, 2026

    @NoahKusaba
    ContributorAuthor

    As mbutrovich has stated there is more review bandwidth for iceberg-rust PR's, I'm going to first focus on the "idemopotent key change on fast_appends", as it closes the only gap in correct writes and the apache/iceberg-rust#3297 we reviewed, as it's mostly done.

    On the datafusion-iceberg side, I'm going to wait on PR #20 to merge while I'm doing the iceberg-rust stuff, and then start opening the remaining PR's that stack on top of it.

    I've also messaged @toutane on slack about re-opening his partitioned reads PR on this repo, and I'll look to re-open it myself by end-of-october as it's a major blocker.

  7. alexanderbianchi commented on Sep 29, 2026

    @alexanderbianchi

    Thanks for the write-up! A lot of these primitives overlap with what DFD needs, which is great. In DFD, we’ll maintain our own DataSourceExec integration because it’s built on the WorkUnitFeeds abstraction. Ideally, we can reuse upstream for everything else.

    As these APIs become public, I’d like to make sure they also accommodate DFD’s execution model—particularly running writers on workers and collecting their results for a coordinator-side commit.

    Breaking this into sub-issues would help; I know a few engineers looking to pick up tickets, including myself.

    I can ask @toutane whether he wants to move apache/iceberg-rust#2671 here or whether I should carry it forward—we work together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions