Blog
Why The World Needs Flarion. Read More
Blog

Spark 4.0's Columnar Journey: Real Progress, Real Limitations

What Spark 4.0 improved in columnar processing, including Arrow integration and UDF support, and which gaps are still there when you look closely.
By
Ran Reichman
•
read time
•
August 18, 2025
Heading 2

Apache Spark 4.0 marks a significant milestone in the framework's evolution toward columnar processing. With enhanced Apache Arrow integration, improved UDF support, and refined plugin architectures, Spark has taken meaningful steps forward. Yet understanding both the advances and the remaining gaps reveals why the journey toward truly efficient columnar processing continues.

The Promise and Reality of Columnar Improvements

Spark 4.0's headline improvements center on Apache Arrow integration. The framework now offers direct DataFrame-to-Arrow conversions, Arrow-optimized Python UDFs achieving up to 1.9x performance improvements, and cleaner APIs for columnar data exchange. These changes particularly benefit PySpark users, who've long suffered from serialization overhead when moving data between JVM and Python processes.

Yet examining Spark's architecture reveals a fundamental reality: the core execution engine remains predominantly row-oriented. While Spark provides hooks for columnar execution through its plugin architecture, the built-in operators - projections, filters, joins, aggregations - still process data row by row through optimized Java code generation. This isn't an oversight but a deliberate design choice that prioritizes compatibility and stability over pure performance.

Where Columnar Support Actually Stands

Understanding Spark 4.0's columnar capabilities requires distinguishing between data format and execution model. Spark has long supported columnar storage formats like Parquet. However, during actual computation, most operations convert this columnar data back to rows for processing.

Built-in SQL expressions execute through Catalyst's code generation, producing tight Java loops that process one row at a time. Complex expressions involving conditionals, nested functions, or custom logic follow this row-wise pattern. The JVM's JIT compiler optimizes these loops well, but they fundamentally lack the vectorized operations that define true columnar processing.

UDF support presents a mixed picture. Pandas UDFs genuinely operate on columnar data, leveraging NumPy's vectorized operations. The new Arrow-optimized Python UDFs improve data transfer efficiency but don't change the scalar execution model - they still process individual values, just with better serialization. Scala and Java UDFs remain entirely row-based, forcing any columnar data to convert back to rows for execution.

The architectural split becomes clear when examining memory management. Spark uses its own ColumnVector implementations for internal operations, not pure Arrow format. Converting between Spark's internal format and Arrow involves either copying or wrapping data, adding overhead that pure columnar engines avoid.

The Performance Gap That Remains

The practical implications become evident in production workloads. Join operations still rely on sort-merge or hash algorithms implemented in Java without SIMD optimization. Aggregations process groups row by row rather than operating on entire column chunks. String operations, mathematical expressions, and date manipulations all follow the same pattern - optimized Java code that processes individual values rather than vectors.

Native columnar engines demonstrate what's possible with true vectorized execution. By leveraging SIMD instructions and processing entire column batches simultaneously, these engines achieve significant speedups - often 2x or more - on the same hardware. This isn't because Spark's code is poorly written; it's because columnar execution with hardware vectorization fundamentally outperforms row-wise processing for analytical workloads.

The memory efficiency gap proves equally significant. Native columnar engines process data in its compressed form, maintaining compression through operations wherever possible. Spark's row-wise operations require decompression and materialization, increasing memory pressure and triggering more frequent garbage collection. For workloads pushing memory limits - a common scenario given how frequently Spark jobs encounter OOM errors - this efficiency difference can determine whether jobs complete successfully.

The Path Forward: Complementary Solutions

Spark 4.0's columnar improvements represent genuine progress, particularly for Python workflows and data interchange scenarios. Yet the core execution engine's row-based nature means achieving optimal columnar performance requires additional components.

Organizations increasingly deploy hybrid architectures that leverage Spark's strengths - distributed orchestration, fault tolerance, broad connector support - while delegating performance-critical operations to specialized columnar engines. Whether through native code execution or hardware acceleration, these complementary technologies fill the gaps in Spark's columnar story. This is precisely where solutions like Flarion's Arrow-based columnar processing provide value - plugging directly into existing Spark deployments to accelerate workloads without requiring code changes, while maintaining the distributed capabilities teams already rely on.

Understanding both Spark 4.0's advances and its limitations enables informed architectural decisions. While Spark takes important steps toward columnar processing, the journey toward truly efficient columnar execution often requires recognizing where additional acceleration provides essential value. For teams facing today's performance challenges - growing datasets, tightening SLAs, and mounting infrastructure costs - combining Spark's orchestration capabilities with purpose-built columnar acceleration delivers the performance modern data platforms demand.

‍

Resources

Related Posts

Blog
This is some text inside of a div block.
Why the World Needs Flarion

Why we built Flarion: the cost of processing large data volumes, the pressure for faster results, and the approach we took to both.

read time
-
November 27, 2024

Did you know that data-driven organizations spend up to 40% of their IT budgets on data processing alone?

As organizations scale their data processing capabilities, two critical challenges emerge: the mounting costs of processing big data and the pressing need for faster performance. Today, we're sharing our journey and explaining why Flarion is transforming how organizations leverage their data assets while staying competitive in an increasingly data-driven world.

The Journey to Better Data Processing

Through years of experience across diverse industries, Flarion’s co-founders witnessed the universal struggle of escalating data processing costs and performance bottlenecks.

During his years building data processing systems for mass-scale consumer applications and autonomous vehicles, Ran experienced firsthand how organizations struggled with the growing costs and performance demands of expanding datasets. In consumer applications, better insights can help create great experiences for hundreds of millions of people, but the high computational costs and processing limitations often make this prohibitively expensive. In autonomous vehicles, data processing at scale allows us to understand and tackle the toughest "long tail" challenges, but technical limitations can make this slow and cost-inefficient.

Through his extensive work with enterprises across various industries, Udi observed a consistent pattern: organizations were hitting both a performance and cost ceiling in their data processing capabilities. Despite significant investments in infrastructure and talent, companies found themselves constrained by processing limitations that held back their ability to launch new features or products while managing escalating infrastructure costs.

The Evolution of Data Processing Needs

The landscape of data processing has evolved dramatically. What started as simple analytics has transformed into complex data pipelines processing hundreds of terabytes daily. These diverse challenges underline the pressing need for solutions that address both speed and cost at scale.

In automotive, processing speed directly impacts vehicle safety and performance, while processing costs affect vehicle affordability and market competitiveness. In financial services, faster data processing enables real-time decision-making and better risk assessment, but the infrastructure costs of high-frequency trading and real-time analytics can quickly erode profit margins. For e-commerce companies, efficient data processing means better customer recommendations and inventory management, yet the cost of processing massive customer datasets across global markets can be prohibitive. Almost every industry relies heavily on efficient data processing and analytics, making both speed and cost optimization critical factors in maintaining competitive advantage.

A New Approach to Performance

Traditional approaches to improving data processing often involve extensive code changes, specialized expertise, or specific deployment requirements. For enterprises with massive legacy codebases, these solutions are often impractical or impossible to implement, creating additional complexity without solving the fundamental challenges of performance and cost efficiency.

We built Flarion with a different vision: what if organizations could dramatically improve their data processing performance without changing their code or disrupting existing workflows? With new Spark, Hadoop and Ray execution engines, we've created a solution that delivers up to 3x performance improvement while maintaining robust reliability and full compatibility. Most importantly, Flarion can be implemented in just 5 minutes, requiring minimal effort from organizations looking to modernize their data stack.

Enabling Innovation Through Efficiency

The impact of accelerated data processing extends far beyond just faster completion times. When organizations can process their data more efficiently and cost-effectively, they can explore new use cases, launch innovative features, and focus on extracting value from their data rather than managing infrastructure costs.

For AI and machine learning applications, efficient data processing is becoming increasingly crucial. The ability to process large datasets quickly and reliably can mean the difference between a successful model deployment and a missed opportunity. With Flarion, organizations can focus on innovation rather than infrastructure optimization, all while maintaining their existing codebase and operations.

The Future of Data Processing

As we enter an era where data drives competitive advantage, organizations need solutions that enable them to process more data, faster and more cost-effectively. The future of data processing isn't just about handling today's workloads - it's about being ready for tomorrow's challenges while managing costs sustainably.

With Flarion, organizations are not just keeping pace—they’re leading the charge into a data-driven future. Our solution enables organizations to unlock the full potential of their data assets, whether they're running data processing in the cloud or on-premises. By delivering significant performance improvements through advanced optimization techniques, we're helping organizations process their data more efficiently while reducing their infrastructure costs. Most importantly, we're doing this in a way that respects the reality of enterprise systems - with a solution that can be implemented in minutes, not months.

The future of data processing should empower organizations to focus on innovation and value creation without being held back by legacy infrastructure or rising costs.

At Flarion, we're making that future a reality.

Featured Blog
Blog
The Data Processing Honey Badger: Why Spark Persists

read time
-
September 10, 2026

Development on Apache Spark started at Berkeley in 2009, and the first production release shipped on May 30, 2014. In the twelve years since, it has become the analytics workhorse for most of the large corporations in the world, across industries and scale, from seed-stage startups to Fortune 10 enterprises. Every year or so someone declares it old, past its peak, saddled with the JVM, and generally "legacy." And every year there is more of it. What accounts for the disconnect? In this post we'll walk through what we see across customer deployments and why we expect that in ten years there will still be a whole lot of Spark, and probably much more than there is today.

Infinite Scale

Spark scales very well. It’s not rare to see customers running workloads reading dozens of TB, while at the same time other customers process a few GB per workload. The result: for data engineering teams who don’t know how much data they’ll need to process, it’s a clean and easy decision to adopt Spark.

Network Effects

While it’s quite easy to use Spark, especially with PySpark, it’s not easy to deploy it and maintain it. But once the data platform adopts the tooling and learns how to maintain Spark, it is rarely motivated to migrate a piece of critical infrastructure to an unproven alternative, and instead are motivated to push more people to use Spark.

The Challenge of Migrating

Large companies can have thousands of jobs running at any given time, spread across the entire organization. The idea of pushing the various teams to migrate to a new platform is usually a complete non-starter. Oftentimes even gradually moving to systems like Ray is unwelcome due to the cost of maintaining multipledata platforms.

A First Class Citizen in the Data Lake

Delta Lake, Iceberg, and Hudi were each born with Spark as the reference implementation. The result is that Spark works well out-of-the-box with all three, while other systems are gradually adding support. Engineering teams want the best and most recent lakehouse technology and generally Spark supports it. .

Extensibility

Spark is easy to extend without forking. Catalyst exposes optimizer rules, planning strategies, and catalog plugins. DataSource V2 lets anyone teach Spark to read a new system. User defined functions (UDFs) let teams introduce Python or Scala logic into the middle of a pipeline without leaving the framework. Plug-ins allow the introduction of new libraries into the system. The result is that the thing people would otherwise leave Spark to get, a new connector, a custom optimization, a domain-specific function library, usually shows up inside Spark instead.

The Competition

Flink is used for some streaming use cases, Ray for AI use cases, Trino for interactive SQL, DuckDB and Polars for data that fits on one machine. Data warehouses with proprietary engines are taking some share. But at this point nobody is really trying to invent a new full-fledged system to replace Spark. The competition is either specializing in a lane or building underneath it.

Improved Engines

In Spark, the underlying engine is not static. The API hasn’t changed much since DataFrames arrived, but adding Tungsten improved performance with whole stage code generation that’s close to the hardware, while query optimizations, fast paths, and new operators also make the same workload faster without code changes. Databricks added Photon, we produced Flarion, and open source brought Gluten and Comet. It’s possible to stay on Spark and get modern performance, similar to how PostgreSQL keeps getting better and adding functionality without the API changing.

Summing Up

The Spark API is likely going to be with us for a long time, but under the hood a lot is going to change. Piece by piece the engine is being replaced, and it's plausible that in ten years none of the original execution code will be left, while every job still runs and every DataFrame still looks the same. It's the Ship of Theseus, except in this version the ship gets faster with every plank. 

‍

Featured Blog
Blog
The Hard Part of Upgrading Spark Versions Isn’t the Code

AI agents can now rewrite Spark jobs for upgrades. Slack, Uber, and Facebook's migrations show the real work: proving the output data didn't change.

read time
-
August 18, 2026

A few weeks ago AWS shipped the Spark Upgrade Agent, an AI agent that migrates Spark jobs to Spark 4.0. You point it at a repo, it rewrites deprecated APIs, adjusts for behavioral changes, updates the build for Scala 2.13, submits the result to an EMR cluster, and iterates on failures until the job runs. It handles both Scala and PySpark, and it works the way you'd hope an agent would: plan, transform, validate, repeat. The potential payoff is large - newer Spark versions have better performance and years of accumulated bug fixes.

It looks like a good tool and data teams looking into a Spark migration should consider it, but what we’ve found is that in the enterprise, rewriting code isn’t the main impediment to upgrading Spark workloads. Spark programs are part of complex pipelines, parts of which are poorly understood or maintained, and making changes to a sensitive system is inherently risky. There’s no guarantee that the output data will actually remain the same, and data integrity is the fundamental challenge of completing such a migration.

Several companies have written in detail about major Spark upgrades, and the data integrity challenge is a recurring theme.

Slack

Slack's migration from Spark 2 to Spark 3 took about a year across 60+ EMR clusters and 40+ teams. They saw some code-level breakage: `RAND()` in join keys became an `AnalysisException`, some casts that Spark 2 tolerated started failing, the `Greatest` function handled NULLs differently than its Hive counterpart. Validation was a much larger effort. For billing pipelines, Slack required exact matches, building test tables from production data on Spark 3 and running `EXCEPT` and `COUNT` comparisons in Trino against the Spark 2 outputs, with a Python framework for digging into every discrepancy. The discrepancies weren't all bugs. Non-deterministic row ordering, timestamp variations, and genuine semantic differences between Hive and Spark implementations all produce diffs that need to be investigated. Some are noise, some are real regressions.

Uber

Uber's version of this is bigger and more instructive. They migrated from Spark 2.4 to 3.3 with over two million Spark applications running daily. The code transformation was automated with Polyglot Piranha, their structural rewrite tool. It parses the source code into an AST, matches patterns, and applies transformation rules, including inserting legacy flags like `spark.sql.legacy.allowUntypedScalaUDF` where old behavior had to be preserved. This scaled well. The problem that shaped the whole project was stated plainly: "We had over 40,000 Spark apps, so we couldn't decentralize the data validation." No staging environment, no test cases, no way to ask every team to eyeball their own outputs.

So the flagship engineering artifact of Uber's Spark upgrade wasn't actually a code migrator but Iron Dome: a shadow-testing framework which runs the migrated job against production inputs, rewrites output paths at runtime so results land in staging instead of production, puts guardrails at the Hadoop FileSystem interface so a misrouted write can't touch real data, then compares the shadow output against the production run and only marks the job migrated when they agree. 

Facebook

None of this is specific to the Spark 2-to-3 transition, or even to Spark versions. When Facebook moved Hive workloads onto Spark SQL back in 2017, they ran shadow pipelines writing to tables suffixed `_spark_shadow` so downstream jobs were never exposed, used count checks as a cheap first filter, and reached for full hash validation of outputs only reluctantly (because, as they put it, the hash validation was "sometimes even heavier than the query itself.") Funny enough, proving the new engine produced the same answer could cost more compute than producing the answer. They note that non-deterministic UDFs made validation hard, the same diff-adjudication problem Slack hit eight years later.

Takeaway

In the enterprise, migrations are rightfully considered risky projects that take time and incur risk. This is especially true in the age of AI given that the things that AI doesn’t necessarily deliver are also the riskiest parts of the migration - edge cases, data integrity, the long tail, etc. This isn’t to say that AI can’t help with building tooling for a migration, it clearly can, but usually an agent isn’t going to do the trick alone.

At Flarion, a major goal of ours is to give users the best possible performance and access to modern features without requiring a code migration. If you can get the benefits of Spark 4.2 while staying on Spark 3.4 then that’s a huge time save and reduction in risk. Of course, the data integrity problem doesn’t disappear, it’s now Flarion’s responsibility. One we’re happy to shoulder.

‍

Oops! Something went wrong while submitting the form.