Why it matters
Region splits are the primary mechanism by which HBase scales. Without them, a growing table would grow into a single region and become a single-server bottleneck. With them, tables scale linearly as data grows: more data means more regions, and more regions spread across more RegionServers.
The cost of leaving splits entirely automatic is that hot tables can generate constant splits, which affect availability. Understanding split policies lets you choose behavior that matches your workload's tolerance for brief region unavailability.
The architecture
Each region has a size threshold (default 10 GB) called the split threshold. When any store file (HFile plus memstore) within the region exceeds this size, the RegionServer schedules a split. The split finds a midpoint row key that divides the region roughly in half.
Actual splitting is fast because it does not rewrite data. The two daughter regions share HFiles with the parent, using reference files that point into the parent's HFiles with byte-range offsets. The parent is marked offline and the daughters take over. Later, compaction rewrites the reference files into standalone HFiles.
How it works end to end
Pre-splitting is the technique of creating a table with multiple initial regions instead of one. If you know the row key distribution in advance, you can specify split points at table creation time so that writes distribute across regions immediately without waiting for automatic splits. This is essential for high-write-rate tables with monotonic keys.
Split policies control when splits happen. ConstantSizeRegionSplitPolicy uses a fixed threshold. IncreasingToUpperBoundRegionSplitPolicy adjusts the threshold based on region count per RegionServer (larger threshold for tables with many regions). SteppingSplitPolicy splits at fixed 1 GB then 10 GB thresholds.
Manual splits via hbase shell can force a specific split point. This is useful when a particular row key range has become hot and automatic splits would leave it as one big region.