Build Once, Probe Many: Hash Table Caching in Velox
TL;DR
Broadcast joins are common in analytical workloads because they avoid repartitioning both inputs when one side is small enough to replicate across workers. Compared with partitioned hash or sort-merge joins, they are often more efficient because the large probe side remains in place, avoiding its substantial network and storage shuffle cost.
In materialized execution engines such as Presto-on-Spark and Spark with
Gluten, build-side splits are planned for every join task. Without additional
coordination, each task reads the same data and constructs an identical hash
table. Velox's HashTableCache replaces this build-per-task behavior with a
build-once, reuse-many protocol within each worker process, delivering
significant cost savings for broadcast-join workloads by eliminating repeated
table construction and build-side I/O.