Why HBase? Strengths, Weaknesses, Real‑World Scenarios, and Architecture Explained

Introduction

HBase is a column‑oriented, distributed storage system that runs on top of Hadoop HDFS. It offers high reliability, high write/read throughput and horizontal scalability, allowing large‑scale structured data to be stored on commodity servers.

Why Use HBase

Advantages

Columns can be added dynamically; empty columns are not stored, which saves space.

Automatic region splitting provides horizontal scalability.

Supports high‑concurrency read and write operations.

Disadvantages

Only row‑key based lookups are supported; there is no secondary indexing or conditional query capability.

Not suitable for traditional OLTP workloads or complex analytical queries that require joins or aggregations.

HBase is a good fit when row structures vary, many columns are sparsely populated, or when fast row‑key lookups are required.

Real‑World Usage Scenarios

Scenario 1 – Seller Operation Logs

Seller operation logs generate massive write‑heavy data (many writes, few reads). Initially all logs were stored in Elasticsearch, but limited ES resources caused performance degradation. The solution stores only the most recent three months in Elasticsearch for flexible queries, while long‑term logs are archived in HBase.

Scenario 2 – Jingmai Message Logs

Jingmai processes tens of millions of messages per day. Real‑time tracing requires the latest week’s logs in Elasticsearch, while comprehensive statistical analysis needs a full copy stored in HBase. Periodically the HBase data is exported to a data‑mart for downstream analytics.

HBase Data Model

Each row consists of three core components: RowKey , Timestamp and Column Family .

RowKey

Primary identifier for a row; can be any byte array up to 64 KB (typical length 10–100 bytes).

Supported access patterns: single‑row lookup, range scan, and prefix scan.

Rows are stored in lexicographic order, so design RowKeys to keep frequently accessed rows adjacent.

Column Family

All columns must belong to a predefined column family; the family is declared in the table schema.

Column names are prefixed with the family name (e.g., info:name).

Data within the same family is stored together on disk, improving read locality.

Timestamp

Each cell can have multiple versions distinguished by a timestamp.

Versions are sorted in reverse chronological order; the latest version is returned by default.

HBase Architecture

Core Modules

Master : Coordinates RegionServers, monitors health, balances load and assigns regions. Multiple Masters can run for HA, but only one is active at a time (managed by ZooKeeper).

RegionServer : Hosts multiple Regions, handles client read/write requests, and stores the actual data.

ZooKeeper : Provides HA for the Master, registers Regions and RegionServers, and acts as the coordination service for the cluster.

Operational Principles

Clients first contact ZooKeeper to discover the RegionServer that hosts the target region.

A Region stores data for a single column family over a contiguous RowKey range. When a region reaches a configured size threshold, it splits into two regions, increasing parallelism and capacity.

Within a region, data is kept in one or more Store objects. Each store contains a MemStore (in‑memory write buffer) and one or more HFiles (on‑disk files stored in HDFS).

Writes are first appended to the MemStore; when the MemStore size exceeds a threshold, it is flushed to a new HFile.

Design Considerations for HBase

Because HBase differs fundamentally from relational databases, schema design directly impacts performance. Key factors to evaluate include:

Number of column families per table (each family incurs separate I/O).

Data types stored in each family (binary vs. textual).

Number of columns per family and column naming conventions (required for read/write).

Cell content and versioning strategy (how many versions to retain).

RowKey design (length, salting, prefixing) to avoid hotspotting and to enable efficient range scans.

Conclusion

HBase provides a scalable, high‑throughput storage layer for large‑scale structured data, especially when row schemas are heterogeneous, columns are sparsely populated, or write volume dominates reads. Selecting HBase should be based on a careful analysis of workload characteristics and thoughtful schema design.