fix(executor): bind the gRPC listener before registering with the scheduler (#2225)

* fix(executor): bind the gRPC listener before registering with the scheduler

The executor spawned its tonic server and registered with the scheduler
immediately afterwards. Server::serve binds inside the future it returns,
so the socket did not exist yet, while the scheduler's registration
handler dials that port back via a single connect with no retry. Losing
that race gave ECONNREFUSED, failed registration, and killed the executor
at startup.

Bind the listener on the current task before spawning, and serve from it
with serve_with_incoming_shutdown, so registration cannot run before the
port accepts connections. tonic ignores the builder's tcp_nodelay and
tcp_keepalive when serving from a pre-bound listener, so the new
create_grpc_server_incoming helper applies them itself.

* refactor: tighten create_grpc_server_incoming docs and tests

* test: restore port-in-use test for create_grpc_server_incoming
2 files changed
tree: 46351b497af4ab7cbb75bbc64b3ba09ecca1ea44
  1. .devcontainer/
  2. .github/
  3. ballista/
  4. ballista-cli/
  5. benchmarks/
  6. chaos-testing/
  7. ci/
  8. dev/
  9. docs/
  10. examples/
  11. python/
  12. .asf.yaml
  13. .dockerignore
  14. .gitignore
  15. Cargo.lock
  16. Cargo.toml
  17. CHANGELOG.md
  18. clippy.toml
  19. CODE_OF_CONDUCT.md
  20. CONTRIBUTING.md
  21. docker-compose.yml
  22. header
  23. LICENSE.txt
  24. NOTICE.txt
  25. pre-commit.sh
  26. README.md
  27. ROADMAP.md
  28. rust-toolchain.toml
  29. rustfmt.toml
  30. stale.yml
  31. take.yml
  32. taplo.toml
README.md

Ballista: Making DataFusion Applications Distributed

Apache licensed

Ballista is a distributed query execution engine that enhances Apache DataFusion by enabling the parallelized execution of workloads across multiple nodes in a distributed environment.

Existing DataFusion application:

use datafusion::prelude::*;

#[tokio::main]
async fn main() -> datafusion::error::Result<()> {
    let ctx = SessionContext::new();

    // register the table
    ctx.register_csv("example", "tests/data/example.csv", CsvReadOptions::new())
        .await?;

    // create a plan to run a SQL query
    let df = ctx
        .sql("SELECT a, MIN(b) FROM example WHERE a <= b GROUP BY a LIMIT 100")
        .await?;

    // execute and print results
    df.show().await?;
    Ok(())
}

can be distributed with few lines of code changed:

[!IMPORTANT]
There is a gap between DataFusion and Ballista, which may bring incompatibilities. The community is actively working to close the gap

use ballista::prelude::*;
use datafusion::prelude::*;

#[tokio::main]
async fn main() -> datafusion::error::Result<()> {
    // create SessionContext with ballista support
    // standalone context will start all required
    // ballista infrastructure in the background as well
    let ctx = SessionContext::standalone().await?;

    // everything else remains the same

    // register the table
    ctx.register_csv("example", "tests/data/example.csv", CsvReadOptions::new())
        .await?;

    // create a plan to run a SQL query
    let df = ctx
        .sql("SELECT a, MIN(b) FROM example WHERE a <= b GROUP BY a LIMIT 100")
        .await?;

    // execute and print results
    df.show().await?;
    Ok(())
}

For documentation or more examples, please refer to the Ballista User Guide.

Who is Ballista for

Ballista serves several distinct audiences:

  • DataFusion users going multi-node — you already use Apache DataFusion on a single machine and have outgrown it. Ballista runs the same SQL and DataFrame workloads across a cluster with minimal code changes and the same results.
  • Spark users wanting the same execution model — you run Spark SQL or batch jobs and want a lighter, Rust-native alternative without relearning a new paradigm. Ballista keeps the familiar model: plans split into stages at shuffle boundaries, one task per partition, executors with vcores, and adaptive query execution (AQE).
  • Library users building a specialized engine — you are building a bespoke distributed query engine and want reusable scheduler, executor, and plan-serialization building blocks with extension points, instead of writing distributed execution from scratch.

These audiences are documented in more detail, along with the guarantees each relies on, in the User Personas guide.

Architecture

A Ballista cluster consists of one or more scheduler processes and one or more executor processes. These processes can be run as native binaries and are also available as Docker Images, which can be easily deployed with Docker Compose or Kubernetes.

The following diagram shows the interaction between clients and the scheduler for submitting jobs, and the interaction between the executor(s) and the scheduler for fetching tasks and reporting task status.

Ballista Cluster Diagram

See the architecture guide for more details.

Getting Started

The easiest way to get started is to run one of the standalone or distributed examples. After that, refer to the Getting Started Guide.

Cargo Features

Ballista uses Cargo features to enable optional functionality. Below are the available features for each crate.

ballista (client)

FeatureDefaultDescription
standaloneYesEnables standalone mode with in-process scheduler and executor

ballista-core

FeatureDefaultDescription
arrow-ipc-optimizationsYesEnables Arrow IPC optimizations for better shuffle performance
spark-compatNoEnables Spark compatibility mode via datafusion-spark
build-binaryNoRequired for building binary executables (AWS S3 support, CLI parsing)
force_hash_collisionsNoTesting-only: forces all values to hash to same value

ballista-scheduler

FeatureDefaultDescription
build-binaryYesBuilds the scheduler binary with CLI and logging
substraitNoEnables Substrait plan support
prometheus-metricsNoEnables Prometheus metrics collection
graphviz-supportNoEnables execution graph visualization
spark-compatNoEnables Spark compatibility mode
keda-scalerNoKubernetes Event Driven Autoscaling integration
rest-apiNoEnables REST API endpoints
disable-stage-plan-cacheNoDisables caching of stage execution plans

ballista-executor

FeatureDefaultDescription
arrow-ipc-optimizationsYesEnables Arrow IPC optimizations
build-binaryYesBuilds the executor binary with CLI and logging
mimallocYesUses mimalloc memory allocator for better performance
spark-compatNoEnables Spark compatibility mode

ballista-cli

FeatureDefaultDescription
tuiYesEnables a REST client with Terminal User Interface

TUI Jobs table

Usage Examples

# Build with standalone support (default)
cargo build -p ballista

# Build with Substrait support
cargo build -p ballista-scheduler --features substrait

# Build with Spark compatibility
cargo build -p ballista-executor --features spark-compat

Project Status

Ballista supports a wide range of SQL, including CTEs, Joins, and subqueries and can execute complex queries at scale, but still there is a gap between DataFusion and Ballista which we want to bridge in near future.

Refer to the DataFusion SQL Reference for more information on supported SQL.

Who uses Ballista

The following organizations use Ballista. To add yours, open a pull request.

Organization
Spice AI
Coralogix

Contribution Guide

Please see the Contribution Guide for information about contributing to Ballista.