Why it matters
The HMaster is often misunderstood as the primary controller of HBase. It is more like a background coordinator. Client reads and writes hit RegionServers directly, and the HMaster does no work for them. This means HMaster performance rarely limits HBase throughput — but HMaster failures are still disruptive because they block region assignment and load balancing.
Knowing what the HMaster does helps you avoid overinvesting in HMaster hardware and helps you diagnose the specific problems it does cause.
The architecture
Region assignment is the HMaster's core job. When a RegionServer starts, it registers with ZooKeeper. The HMaster notices the new RegionServer and assigns unassigned regions to it. When a RegionServer dies (ZooKeeper session times out), the HMaster reassigns its regions to other RegionServers.
DDL execution goes through the HMaster. Create table creates the initial regions and assigns them. Alter table can add or remove column families or change table attributes. Drop table decommissions regions and cleans up HFiles.
How it works end to end
The load balancer runs periodically on the HMaster (default every 5 minutes). It computes the ideal distribution of regions across RegionServers and generates a series of region moves to reach it. Balancing considers region count, data locality, table isolation, and rack topology. Balancing is expensive because moving a region requires taking it offline briefly, so the balancer is conservative.
HA works through ZooKeeper. Multiple HMaster processes register as candidates in ZooKeeper; one wins the leader election and becomes active. The standbys keep watching for the active to disappear. On active failure, the next standby is promoted immediately and picks up in-flight work.
The meta table is a special HBase table that stores the mapping from row-key ranges to RegionServers. The HMaster owns updates to meta, but reads from meta come directly from RegionServers (meta itself is hosted like any other table).