Why it matters
Impala's execution model is worth studying because it demonstrates what modern SQL engines look like. Vectorization and JIT are standard in Spark 3, DuckDB, ClickHouse, and others. Impala was early to this pattern.
The architecture
Operators process row batches (typically 1024 rows). This amortizes function call overhead and enables SIMD instructions. The result is 5-10x throughput versus tuple-at-a-time.
LLVM JIT compiles per-query expressions. A WHERE clause with several conditions becomes tight native code specific to those column types and offsets. Compilation takes tens of milliseconds; execution then runs at hardware speed.
How it works end to end
Fragments stream data to each other via TCP. When a fragment produces a batch, it sends the batch immediately to the destination fragment. No batches wait for the source fragment to fully complete. This pipelining hides sort or aggregation latency.
Runtime filters flow backwards through the pipeline. When a join builds its hash table, it emits a bloom filter to upstream scans, letting them skip rows that provably will not match the join.
Admission control queues incoming queries when resources are constrained. This prevents thundering herd from overwhelming Impala with concurrent queries.