Skip to main content

2 posts tagged with "Graviton"

AWS Graviton (arm64) compute for Spark and lakehouse workloads

View All Tags

13 Billion Rows into Apache Iceberg in 7 Minutes, for $3.69

· 10 min read
Cazpian Engineering
Platform Engineering Team

12.96 billion rows of raw Parquet into a query-ready Apache Iceberg table in 7 minutes 4 seconds on 32 Graviton workers

A post making the rounds on LinkedIn showed a serverless Spark platform processing "1 TB (40 billion rows)" in 14 minutes 5 seconds: 91 raw Parquet files ingested into a table clustered by date and warehouse. Read closely, the 40 billion is rows read — the post notes the engine read three times more rows than it wrote, 13.3 billion, because clustering on write re-processed the data. It is a good benchmark all the same: no toy data, no caching tricks, a real shuffle and a real write, and a table you can query the moment the job commits.

So we ran the same shape of job on Cazpian.

12,959,823,744 rows — 1.13 TB of raw Parquet — landed in an Apache Iceberg table partitioned by day and sorted within each day, in a median of 7 minutes 4 seconds on 32 AWS Graviton workers. Every row counted, in three runs out of three. About $3.69 of compute per load. Starting from nothing — no cluster running at all — clicking Create Pool to the committed table took 12 minutes 3 seconds.

We Moved Cazpian's Spark Pools to ARM — 2x Faster Under Load

· 12 min read
Cazpian Engineering
Platform Engineering Team

Cazpian Spark pools on Graviton ARM64: median job 5,109 ms vs 9,953 ms on x86 under 100-way concurrency

Conventional wisdom says migrating a data engine to ARM is a performance gamble you take for the discount. We ran the experiment on our own Spark compute pools, and the result inverted the premise: under 100-way concurrency, the ARM64 pool ran every job roughly twice as fast as its x86 twin — at about 20% lower infrastructure cost.

We are publishing the numbers, but also the part benchmark posts usually cut: our first measurement said ARM was 8.5x slower, and that number was wrong in a way that had nothing to do with ARM. If you are planning an ARM migration for your data platform, the detour is probably worth more to you than the table.