Get fluent in Spark SQL by writing it. Read a short lesson, then answer the kind of question a colleague actually asks — against a practice warehouse with orders, clickstream, FX rates and pipeline telemetry. The cheat sheet stays one click away the whole time, because remembering the exact syntax is not the point.
Loading…
Loading…
QueryDojo has two halves. Learn is ten short modules that go from SELECT to building a
layered pipeline — each lesson is a few paragraphs, one syntax block, and one runnable example.
Practice is 34 exercises phrased the way requests actually arrive: someone asks a question in a
sentence, and you turn it into a query. Your answer is checked against a reference query by comparing the
actual result sets, so any correct approach passes.
Eight tables — users, products, orders, order items, clickstream events, FX rates, profile snapshots and pipeline run telemetry — covering January to June 2025. It is generated from a fixed seed, so everyone sees identical data and every exercise has one stable answer. It also carries the problems real data has: exact duplicate rows, orders pointing at users who don't exist, header totals that don't match their line items, and a currency feed with missing dates. Those aren't bugs; several exercises exist to find them.
Queries run server-side against SQLite with a Spark SQL function library layered on top, so
date_format, datediff, regexp_extract, collect_list,
percentile_approx and the rest behave the way you'd write them in Spark. Window functions,
CTEs, every join type and correlated subqueries all work as expected. It is not Spark, though — the guide
panel lists exactly what differs (no LATERAL VIEW/EXPLODE, no
INTERVAL literals, no QUALIFY, no struct or map columns). Everything is read-only:
INSERT, UPDATE and DROP are blocked, and each query runs against a
fresh copy of the data.
Solved exercises are remembered in your browser's local storage only. There's no account, no login, and nothing about your queries is stored on the server — it runs your SQL, returns the rows, and forgets it.
Most SQL tutorials teach syntax against a toy table of three customers, which is fine right up until the
first time a join silently doubles your revenue number. The gap that actually matters isn't knowing that
GROUP BY exists — it's knowing which of COUNT(*), COUNT(col) and
COUNT(DISTINCT col) the person asking meant, spotting that an INNER JOIN just
dropped six orders, and noticing that a day with zero rows disappeared from the chart instead of showing
zero.
So the exercises here are built around the mistakes rather than the keywords: fan-out, NULL propagation, non-deterministic tie-breaking, missing join keys, reconciliation between two sources that should agree. The data has real defects in it on purpose, and several tasks are simply "find them". The later modules move from single queries to layered transforms — raw, clean, enriched, mart — because that's the shape production work takes once more than one person depends on the output.
It's aimed at people who understand what a database is and roughly what SQL does, but can't recall the exact incantation for "top three per category" or "latest row per key" without looking it up. That's a normal place to be. The fix isn't memorising a reference — it's writing enough queries that the shapes become familiar, with the reference sitting open beside you until it isn't needed.