Why it matters
LLAP made Hive competitive with Impala and Presto for interactive workloads. Before LLAP, users had to switch tools when latency mattered. With LLAP, Hive covers both batch and interactive from one engine, using the same metastore, security model, and SQL dialect.
The architecture
An LLAP daemon runs on each worker node. It has a fixed heap for JVM + executors, an off-heap cache for columnar data, and a set of executor threads that run query fragments. Daemons are managed by YARN via Slider.
Query planning goes through the Hive driver as usual. The physical plan then executes on LLAP daemons instead of ephemeral Tez containers. Fragments are dispatched directly to daemons via the LLAP protocol.
How it works end to end
The columnar cache holds decoded ORC and Parquet columns. Hot data stays in cache across queries, so subsequent queries touching the same data hit RAM. Cache eviction is LRU with column-level granularity.
Executor threads run query fragments concurrently. Vectorized execution processes batches of thousands of rows per operator call, dramatically improving CPU efficiency versus tuple-at-a-time.
LLAP is optional: queries can fall back to plain Tez if LLAP daemons are unavailable or overloaded. This gives graceful degradation.