Why it matters
Analytics workloads often need to combine batch-scale storage with operational access patterns. A billion-user profile store that also feeds ML training pipelines is a natural HBase workload: massive size, key-based access from serving traffic, and range scans from batch pipelines. Solving this with two separate systems doubles the ops burden and creates consistency problems.
HBase also plays well with the Hadoop ecosystem. Spark and MapReduce can read HBase directly. Phoenix adds SQL. This ecosystem alignment matters when you already have a Hadoop investment.
The architecture
The HBase data model is a sparse, multidimensional, sorted map. A row is identified by a byte-string row key. Each row has one or more column families, and each family holds arbitrary columns (called qualifiers). Each cell — the intersection of row key and column — can hold multiple versions of a value, each timestamped.
Rows are sorted lexicographically by row key across the cluster. This global sort order is what makes range scans efficient: give me all rows starting with 'user123' and HBase can find them in log time. It is also why row-key design is the single most important schema decision in HBase.
How it works end to end
Storage is layered. HBase writes go to a write-ahead log for durability and to an in-memory memstore per column family. When the memstore fills, it flushes to disk as an HFile stored on HDFS. HFiles accumulate and are periodically merged by compaction into fewer, larger files.
Reads consult both memstore and HFiles. A block cache in the RegionServer speeds up hot HFile reads. Bloom filters on each HFile let the RegionServer skip HFiles that cannot contain the target row.
The cluster is partitioned by row key range. Each range is called a region and is served by exactly one RegionServer. As data grows or shrinks, regions split or merge automatically. This gives HBase linear scalability: adding RegionServers spreads regions and increases capacity proportionally.