HBase Basics

Analogy categoryAnalogies

What Is HBase?

Apache HBase is a distributed, column-oriented NoSQL database modeled after Google's Bigtable paper, running on top of HDFS to provide random, real-time read/write access to individual rows, something HDFS and Hive alone cannot do efficiently since HDFS is optimized for large sequential scans and append-only writes rather than point lookups or updates. HBase trades away SQL joins, secondary indexes, and multi-row transactions for horizontal scalability and low-latency access to billions of rows and millions of columns, making it suited to use cases like a real-time recommendation lookup table or a time-series sensor archive rather than ad-hoc analytical queries.

🏏

Cricket analogy: Like a live scoreboard app that can instantly fetch a single player's exact current strike rate on demand, versus a season-end analytics report that scans the entire tournament's ball-by-ball archive, HBase trades bulk-scan power for instant single-row lookups.

Data Model: Rows, Column Families, and Cells

HBase organizes data into tables of rows identified by a unique rowkey, sorted lexicographically, and within each row, columns are grouped into column families declared at table-creation time, with individual column qualifiers created dynamically at write time without any schema change; every cell additionally carries a version, a timestamp, so a get can retrieve the latest value or a specific historical version, and because HBase stores columns physically together per column family rather than per row, queries that touch only one family avoid reading unrelated data. Rowkey design is the single most consequential HBase modeling decision, since all fast lookups and range scans depend on it, a poorly chosen key, like a monotonically increasing timestamp, causes writes to pile onto one region while the rest of the cluster sits idle, a problem called hotspotting.

🏏

Cricket analogy: Choosing a rowkey is like deciding how to file player performance cards, sorting by a raw sequential match number concentrates all new filing into one drawer as the season progresses, exactly the hotspotting problem a salted or reversed rowkey avoids.

bash

# HBase shell examples
create 'user_events', 'info', 'stats'

put 'user_events', 'u1001', 'info:last_login', '2026-07-09T10:15:00'
put 'user_events', 'u1001', 'stats:click_count', '42'

get 'user_events', 'u1001'
get 'user_events', 'u1001', {COLUMN => 'info:last_login', VERSIONS => 3}

scan 'user_events', {STARTROW => 'u1000', STOPROW => 'u1100'}

Salting or reversing a monotonically increasing rowkey, for example hashing the first few characters or reversing a timestamp, spreads sequential writes across regions instead of concentrating them on whichever region currently holds the newest keys.

Architecture: RegionServers and HMaster

An HBase cluster's master daemon, the HMaster, handles table-level DDL, region assignment, and load balancing, while the actual data lives on RegionServers, each hosting many Regions, contiguous rowkey ranges of a table that automatically split once they exceed a configured size threshold, and each RegionServer also colocates with the HDFS DataNode on the same physical machine for data locality. ZooKeeper coordinates cluster state, tracking which RegionServer is currently serving which region and electing a new HMaster if the active one fails, and every write first goes to a Write-Ahead Log (WAL) on that RegionServer before being acknowledged, so a crashed RegionServer's in-memory writes can be replayed from its WAL during recovery.

🏏

Cricket analogy: The HMaster is like a tournament's chief administrator assigning which stadium hosts which match, while each stadium's own ground staff (RegionServer) actually manages a contiguous block of seating (a region), and a written match-day log ensures no result is lost if a stadium loses power mid-match.

Reads, Writes, and Compactions

Writes land first in an in-memory MemStore per column family and are appended to the WAL for durability; once a MemStore fills past a threshold, it's flushed to disk as an immutable HFile, and because a single logical row's data can end up scattered across many HFiles over time, a background minor compaction periodically merges several small HFiles into a larger one, while a more expensive major compaction merges all HFiles for a region into one, permanently discarding cells marked for deletion and old versions beyond the configured retention count. Reads therefore may need to check the MemStore plus multiple HFiles and merge results on the fly, which is why HBase read latency, while still far faster than a full HDFS scan, is typically higher than its write latency.

🏏

Cricket analogy: The MemStore-to-HFile flush is like a scorer jotting live updates on a notepad (MemStore) before periodically transcribing them into the official bound scorebook (HFile), with occasional archive consolidations (compactions) merging multiple scorebooks from a series into one clean volume.

Running a major compaction manually during peak traffic hours can saturate a RegionServer's I/O and CPU, since it rewrites an entire region's data at once; production clusters typically schedule major compactions during off-peak windows or disable automatic major compaction and trigger it manually.

HBase is a distributed, column-oriented NoSQL database modeled on Google's Bigtable, built on top of HDFS.
It trades SQL joins and multi-row transactions for horizontal scalability and low-latency random row access.
Rows are identified by a sorted rowkey; columns are grouped into column families declared at table creation.
Rowkey design directly determines performance -- poorly chosen keys cause hotspotting on a single region.
The HMaster handles DDL and region assignment; RegionServers hold the actual data and colocate with HDFS DataNodes.
Every write goes to a Write-Ahead Log before acknowledgment, enabling recovery if a RegionServer crashes.
Minor compactions merge small HFiles; major compactions merge all of a region's HFiles and purge deleted/expired versions.