上图是HRegionServer数据存储关系图。上文提到，HBase使用MemStore和StoreFile存储对表的更新。数据在更新时首先写入HLog和MemStore。MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到Flush队列，由单独的线程Flush到磁盘上，成为一个StoreFile。与此同时，系统会在Zookeeper中记录一个CheckPoint，表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致MemStore中的数据丢失，此时使用HLog来恢复CheckPoint之后的数据。
StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定阈值后，就会进行一次合并操作,将对同一个key的修改合并到一起，形成一个大的StoreFile。当StoreFile的大小达到一定阈值后，又会对 StoreFile进行切分操作，等分为两个StoreFile。
4.1 写操作流程步骤1：Client通过Zookeeper的调度，向HRegionServer发出写数据请求，在HRegion中写数据。
步骤2：数据被写入HRegion的MemStore，直到MemStore达到预设阈值。
步骤3：MemStore中的数据被Flush成一个StoreFile。
步骤4：随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。
步骤5：StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。
步骤6：单个StoreFile大小超过一定阈值后，触发Split操作，把当前HRegion Split成2个新的HRegion。父HRegion会下线，新Split出的2个子HRegion会被HMaster分配到相应的HRegionServer 上，使得原先1个HRegion的压力得以分流到2个HRegion上。
4.2 读操作流程步骤1：client访问Zookeeper，查找-ROOT-表，获取.META.表信息。
步骤2：从.META.表查找，获取存放目标数据的HRegion信息，从而找到对应的HRegionServer。
步骤3：通过HRegionServer获取需要查找的数据。
步骤4：HRegionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。
5 HBase使用场景半结构化或非结构化数据：对于数据结构字段不够确定或杂乱无章，很难按一个概念去进行抽取的数据适合用HBase。如随着业务发展需要存储更多的字段时，RDBMS需要停机维护更改表结构，而HBase支持动态增加。
记录非常稀疏：RDBMS的行有多少列是固定的，为空的列浪费了存储空间。而HBase为空的列不会被存储，这样既节省了空间又提高了读性能。
多版本数据：根据RowKey和列标识符定位到的Value可以有任意数量的版本值（时间戳不同），因此对于需要存储变动历史记录的数据，用HBase将非常方便。
超大数据量：当数据量越来越大，RDBMS数据库撑不住了，就出现了读写分离策略，通过一个Master专门负责写操作，多个Slave负责读操作，服务器成本倍增。随着压力增加，Master撑不住了，这时就要分库了，把关联不大的数据分开部署，一些join查询不能用了，需要借助中间层。随着数据量的进一步增加，一个表的记录越来越大，查询就变得很慢，于是又得搞分表，比如按ID取模分成多个表以减少单个表的记录数。经历过这些事的人都知道过程是多么的折腾。采用HBase就简单了，只需要在集群中加入新的节点即可，HBase会自动水平切分扩展，跟Hadoop的无缝集成保障了数据的可靠性（HDFS）和海量数据分析的高性能（MapReduce）。
6 HBase的MapReduce
HBase中Table和Region的关系，有些类似HDFS中File和Block的关系。由于HBase提供了配套的与MapReduce进行交互的API如TableInputFormat和TableOutputFormat，可以将HBase的数据表直接作为Hadoop MapReduce的输入和输出，从而方便了MapReduce应用程序的开发，基本不需要关注HBase系统自身的处理细节。
Ubuntu Server 14.04 下 Hbase数据库安装