Skip to main content

Bassirah Technology

APACHE SPARK · INDEPENDENT ENGINEERING

Distributed Processing, Engineered to Run Predictably.

Design, tune, upgrade and operate self-managed Apache Spark for batch, SQL and streaming workloads, with Spark 4 migrations tested against your own jobs and data.

Independent Apache Spark engineering.

These are independent Bassirah engineering and support offerings. They do not imply endorsement by The Apache Software Foundation or the Apache Spark project, official vendor support rights, enterprise feature entitlement or maintenance guarantees.

Apache Spark, Spark and the Spark logo are trademarks of The Apache Software Foundation. Bassirah is not a partner of Databricks, or of Amazon Web Services, Google Cloud or Microsoft for their Spark services.

Supported releases.

Apache Spark is a project of The Apache Software Foundation, released under the Apache License 2.0. Bassirah provides independent engineering for the 4.2, 4.1 and 4.0 release lines, and for the 3.5 line during its extended long-term support period, with migration planning from 3.5 to Spark 4. The exact versions in scope are named in each statement of work. Last reviewed: 26 October 2026.

Release information from the Apache Spark news archive and versioning policy, accessed 26 October 2026 and re-checked 27 October 2026. The project decides how long each line receives maintenance releases. Under the versioning policy, critical security patches are backported to all actively maintained branches.
Release lineStatus (accessed 26 October 2026)How Bassirah treats it
4.2First released 14 July 2026; latest release 4.2.1, 27 October 2026. The versioning policy states an 18-month maintenance window for 4.2.xDefault target for new deployments and Spark 4 migrations
4.1First released 16 December 2025; latest release 4.1.4, 27 October 2026Supported; upgrade planning to 4.2
4.0First released 23 May 2025; latest release 4.0.5, 27 October 2026Supported; upgrade planning to 4.2
3.5Latest release 3.5.9, 16 July 2026. Extended LTS with security fixes only, ending November 2027Supported for existing workloads; migration to Spark 4 planned before the extended period ends

Starting with 4.3.0, the project plans quarterly feature releases and an annual major release. The policy names 4.5.0 as the planned 4.x long-term support release.

WHY IT MATTERS

One Engine for Batch, SQL and Streaming. Many Ways to Misconfigure It.

Apache Spark runs data processing in parallel across a cluster, with APIs in SQL, Python, Scala, Java and R. Teams use it for large batch transformations, lakehouse pipelines, Structured Streaming and machine learning data preparation.

Each job is split into stages and tasks that run on executors, with data exchanged between stages in shuffles. Partitioning, memory settings, shuffle volume and data layout decide whether a job finishes reliably or fails late in the run. Security also needs deliberate work: the project’s documentation states that authentication is not enabled by default and that no deployment mode is secure by default. Spark 4 changed defaults too, including ANSI SQL mode. Bassirah engineers the platform, tunes the jobs that matter and tests every upgrade against your own workloads.

Abstract illustration of a compute cluster processing data in parallel

WHAT BASSIRAH DELIVERS

Independent Apache Spark Engineering and Operations

  • Platform architecture — Choose the cluster manager, client access model, storage and table formats, and isolation between teams and workloads.
  • Deployment — Deploy self-managed Spark on Kubernetes or Hadoop YARN, with images, configuration and job definitions under version control.
  • Job and SQL tuning — Diagnose slow or failing jobs from the web UI and event logs, then tune partitioning, shuffles, memory and query plans based on evidence.
  • Spark 4 migration — Move workloads from Spark 3.5 to Spark 4 with dependency checks, behavior testing under ANSI SQL mode and reconciled results.
  • Security — Authentication, encryption, access to the web UI and submission endpoints, and network isolation, configured deliberately because none are on by default.
  • Upgrades — Maintenance and feature-release upgrades rehearsed in staging, tracked against the project’s release and security pages.
  • Observability — Metrics, History Server, event logs, executor and shuffle health with actionable alerts.
  • Troubleshooting and managed support — Incident troubleshooting, health reviews of existing clusters and jobs and, where you want it, contracted operations under an agreed scope.

FIT FIRST

When Spark Earns Its Complexity

A Spark platform has many moving parts. We recommend it when the workload needs distributed processing, and we say so when another engine or a single machine is enough.

When Spark Earns Its Complexity
RequirementApache Spark is worth evaluating when…Another option is often enough when…
Data volumeTransformations must process more data than one machine handles within your processing windowThe data fits comfortably on one machine, or in a single database
Workload typePipelines combine SQL with Python, Scala or Java code, user-defined functions or machine learning data preparationUsers mainly run interactive SQL over existing tables: a query engine such as Trino or ClickHouse may fit better
StreamingStreams are processed with the same code and tables as batch, using Structured StreamingEach event needs stateful, event-at-a-time processing: Apache Flink may fit better
SchedulingYou pair Spark with an orchestrator for dependencies and retriesYou expect Spark itself to schedule workflows: it does not; see Apache Airflow
OperationsYour team, or a contracted provider, will operate a cluster, or you choose a managed Spark serviceYou want the smallest possible operational footprint

Already decided on a managed Spark service? We can still review job design, data layout and migration plans. See the support routes below.

ARCHITECTURE AND SECURITY

Deployment, Isolation and Recovery, Chosen Deliberately

Spark can run on Kubernetes, Hadoop YARN or its own Standalone cluster manager. Clients can submit applications directly or connect through Spark Connect, a client-server architecture introduced in Spark 3.4. Each choice changes how teams are isolated, how resources scale and how failures are contained. We choose them per workload, secure them explicitly and prove recovery for streaming jobs in tested recovery exercises against objectives you approve.

Deployment, Isolation and Recovery, Chosen Deliberately
DecisionTypical approachTrade-off we make explicit
Cluster managerKubernetes for container-based platforms, YARN where a Hadoop estate already existsFit with existing operations vs. the effort of running a second scheduler
Client accessSpark Connect for remote clients and notebooks, direct submission for scheduled jobsDecoupled clients and upgrades vs. API coverage to test per workload
Resource scalingDynamic allocation of executors with shuffle tracking, sized per workloadShared capacity and cost vs. predictable start times for critical jobs
Storage and tablesObject storage or HDFS with an open table format, partitioned for the main queriesWrite cost and file maintenance vs. read efficiency
SecurityAuthentication, encryption and restricted access to the web UI and submission endpoints, on trusted networks onlySetup and key management effort vs. the exposure of an unsecured cluster
Streaming recoveryStructured Streaming queries with checkpoint locations on durable storageCheckpoint storage and upgrade constraints vs. restart without data loss or duplicates where the sink supports it
Apache Spark platform: notebooks connect through Spark Connect and scheduled jobs are submitted to a driver; a cluster manager such as Kubernetes or YARN allocates executors that run tasks and exchange data in shuffles; executors read and write object storage, event streams and databases; event logs and metrics feed the web UI and History Server, and streaming checkpoints go to durable storage.

Apache Spark platform architecture and support scope

OPERATIONS

Evidence-Led Tuning for Distributed Jobs

Abstract illustration of data redistributed between processing stages

Jobs and shuffles

Read stage and task metrics, find skew and spills, and tune partitioning, joins and Adaptive Query Execution settings for the jobs that cost the most.

Abstract illustration of table files organized in layers in storage

Data layout

Size files and partitions for the queries that matter, and keep table maintenance on a schedule so reads stay efficient.

Abstract illustration of a staged path from one release to the next

Upgrades

Maintenance and feature-release upgrades with dependency checks for Java, Scala, Python and connectors, rehearsed in staging with a rollback decision point.

Abstract illustration of monitoring panels for a compute cluster

Monitoring

Executor health, failed tasks, shuffle and memory pressure, and streaming progress, with History Server retention and actionable alerts.

MIGRATION

Move to Spark 4 With Traceability and Controlled Risk

Delivered through our migration and modernization practice. Spark 4 requires Java 17 or later and Scala 2.13, removes Mesos support, raises minimum PySpark dependency versions and turns on ANSI SQL mode by default.

  1. InventoryCatalog jobs, notebooks, libraries, connectors, Java, Scala and Python versions, configurations and schedules.
  2. Assess compatibilityCheck each item against the Spark 4 SQL, Core and PySpark migration guides, and identify what runs unchanged, what needs rework and what needs a legacy setting for now.
  3. Test behaviorRun representative jobs under ANSI SQL mode and the changed defaults, and compare outputs, errors and resource use.
  4. Parallel run and reconcileRun old and new versions side by side and reconcile results with agreed control checks.
  5. Cut overSwitch production jobs in waves with explicit rollback decision points, then retire legacy settings on a plan.

Still on Spark 3.5?

Start with a compatibility review of your own jobs and dependencies.

USE CASES

Where Apache Spark Fits

Lakehouse and batch pipelines

Large transformations that build curated tables in object storage on open table formats.

Streaming with batch code

Structured Streaming jobs that read events, for example from Apache Kafka, and write to the same tables as batch jobs.

Data preparation for analytics and ML

Feature and training data preparation in Python or SQL at a scale one machine cannot handle.

SUPPORT ROUTES

Community, Independent Support or a Managed Spark Service

Apache Spark is open source. Several companies also offer commercial platforms and managed services that run Spark, including Databricks, Amazon EMR, Google Cloud Managed Service for Apache Spark (formerly Dataproc) and, on Microsoft Azure, Azure HDInsight, Spark pools in Azure Synapse Analytics and Microsoft Fabric. Bassirah supports self-managed Apache Spark independently, is not a partner of these vendors and is clear about where its commitments end.

Community, Independent Support or a Managed Spark Service
Decision factorCommunity onlyBassirah independent supportCommercial platform or managed service
Who operates SparkYour teamYour team with Bassirah engineering, or Bassirah under a managed scopeThe vendor operates the service, under its own terms
Help with incidentsPublic community channels, no response commitmentResponse targets per your agreementVendor support under the vendor's own terms
Code defectsReported by you to the projectReproduced, worked around and reported upstream by BassirahHandled by the vendor under its terms
Upstream fixes and releasesOn the project's timelineOn the project's timeline; we track them, test them and apply them through change controlVendor runtime versions and timelines, under the vendor's terms
Commercial productsNot includedNot included: Bassirah does not resell or license commercial Spark platforms or managed Spark servicesContracted directly with the vendor

If you need a commercial platform or a managed Spark service, that is contracted with the vendor. How cases, severities and response targets work for our independent support is set out in our open-source support model. For fully contracted operations, see Managed Services.

WORKS WITH

Apache Spark in the Wider Portfolio

Spark is one engine in our data processing practice. We place it alongside orchestration, streaming, query engines and object storage where each fits, and test every integration first.

Apache Airflow

Orchestrates Spark jobs with dependencies, retries and schedules.

OSS

Apache Kafka

Event streams that Structured Streaming jobs can read from and write to.

OSS

Trino

Interactive SQL over the tables that Spark pipelines produce.

OSS

MinIO AIStor

S3-compatible object storage for lakehouse tables, where the deployment calls for it.

Strategic Partner

Apache Spark: Frequently Asked Questions

Yes. Apache Spark is a project of The Apache Software Foundation, released under the Apache License 2.0. Commercial platforms and managed services built on Spark are separate products with their own terms. Bassirah supports self-managed Apache Spark and is not endorsed by the ASF or the Spark project.

We work on the 4.2, 4.1 and 4.0 release lines, and on 3.5 during its extended long-term support period, which the project says ends in November 2027 with security fixes only. The versions in scope are confirmed in each statement of work.

Spark 4 requires Java 17 or later and Scala 2.13, turns on ANSI SQL mode by default, removes Mesos support and raises minimum Python dependency versions. Some defaults and data source mappings change too. We test your jobs against the project’s migration guides before cutover.

Spark suits large transformations that mix SQL with code. For interactive SQL over existing tables, a query engine such as Trino is often simpler. Many platforms use both, and we help you decide per workload.

No. Bassirah is not a partner of Databricks or of the cloud providers’ managed Spark services, and does not provide vendor support, vendor security fixes or vendor escalation. Our services are independent engineering and support, with scope and response targets defined in your agreement. Code fixes and releases follow the project’s timeline. See our support model.

No. The project’s documentation states that security features such as authentication are not enabled by default, and it advises against exposing clusters to untrusted networks. We configure authentication, encryption and access to the web UI and submission endpoints as part of every deployment.

Make Spark Jobs Predictable.

Tell us about your clusters, jobs and upgrade plans. We will scope an assessment and a practical next step.

Enterprise Lakehouse

Real-Time Analytics

Migration & Modernization

Open-Source Support Model

Related Insights