Why it matters
Scans are the workhorse of analytical access to HBase. Batch jobs, ML training pipelines, and reporting queries all use scans. Scan performance often dominates total pipeline runtime, so tuning it pays back across every job.
Scans also dominate RegionServer load on scan-heavy workloads. A poorly-tuned scan can lock up a RegionServer with excessive memory allocation. Understanding scan mechanics protects the cluster from user mistakes.
The architecture
A Scan object on the client specifies startRow (inclusive), stopRow (exclusive), column selectors, filters, and control parameters like caching and batching. The client sends the Scan to the RegionServer holding the first row in the range. The RegionServer opens a scanner that iterates cells in sorted order.
Caching controls how many rows the server prepares per RPC round trip. Batching controls how many cells per row per RPC. Smaller values mean more RPCs; larger values mean higher memory use per RPC.
How it works end to end
The server-side scanner is a heap of per-store scanners (one per HFile plus memstore). At each step it advances the store scanner with the smallest current row+column and returns the corresponding cell. This gives a merged sorted stream across all storage layers.
Once caching worth of rows accumulates, the server returns them to the client in one RPC. The client processes the batch and requests the next. This continues until the stopRow is reached or the client closes the scanner.
Filters can be attached to the scan. They run server-side, reducing network bytes by skipping rows or cells the client would filter out anyway. Server-side filtering is far more efficient than client-side filtering for large scans.