一、HBase数据检索流程

        上图中，我们可以看出不管客户端读或写一个表的数据，首先链接Zookeeper，因为需要到Zookeeper中找读的数据，表是通过Region来管理，每个Region由RegionServer管理，每个Region都有startkey及endkey。

        HBase的表格分为User Tables（用户表）和Catalog Tables（系统自带表）。

        User Tables（用户表）包含user信息、region信息（startkey和endkey）。例：user表的region-01存在regionserver-03中。该信息是保存在meta-table中。

       在HBase新版本中，有类似于RDBMS（关系数据库管理系统）中DataBase的命名空间的概念。HBase的所有表都在data目录下，data下包含default目录和hbase目录，这里的目录就是命名空间的概念。

       用户自定义的表默认情况下命名空间为default，而系统自带的元数据表的命名空间为hbase。

       meta表只有一个Region，它的Region也需要RegionServer管理，即为meta-region-server的功能。用户首先找到meta-region-server，然后找到meta表，scan命令可以看到表格中column被什么server管理。

       综上所述，用户表由很多region组成，region信息存储在hbase：meta中。用户表的每一个region都有key。Client需要先读zookeeper，其实通过meta-region-server找到的是meta表的region，找到后扫描meta表的数据，然后再找到数据再操作。

二、HBase数据存储

2.1 HBase结构详解

       HBase能高速实现数据存储和访问源于HBase数据存储。

       1. 连接Zookeeper，从Zookeeper中找到要读的数据。我们需要知道表中RowKey在region的位置。

       2. 客户端查找HRegionServer，HRegionServer管理众多Region。

       3. HMaster也需要连接Zookeeper，连接的作用是：HMaster需要知道哪些HRegionServer是活动的及HRegionServer所在的位置，然后管理HRegionServer。

       4. HBase内部是把数据写到HDFS上的，DFS有客户端。

       5. Region中包含HLog、Store。一张表有几个列簇，就有几个Store。Store中有很多memStore及StoreFile。StoreFile是对HFile的封装。StoreFile真正存储在HDFS上。

       6. 写数据时，先往HLog上写一份，再往memStore上写一份。当memStore达到一定大小则往StoreFile上写。若memStore数据有丢失，则从HLog上恢复。

       7. 读数据先到memStore上读，再到StoreFile上读，之后合并。

2.2 HBase数据存储详解

       1. HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，主要包括两种文件类型：

       1）HFile：HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFIle就是对HFile做了轻量级的包装，进行数据的存储。

       2）HLog File：HBase中WAL（Write Ahead Log）的存储格式，物理上是Hadoop的Sequence File。

       2. HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了table中的一个region，HRegion中由多个HStore组成。每个HStore对应了Table中的一个column family的存储，可以看出每个columnfamily其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个column family中，这样最高效。

       3. HStore存储是HBase存储的核心，由两部分组成，一部分是MemStore，一部分是StoreFile。

       4. MemStore是 Sorted Memory Buffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile）。

       5. HLog 文件结构：WAL意为Write ahead log，类似Mysql中的binlog，用来做灾难恢复。Hlog记录数据的所有变更，一旦数据修改，就可以从log中进行恢复。 

       6. 每个HRegionServer维护一个HLog,而不是每个HRegion一个。这样不同region（来自不同table）的日志会混在一起，这样做的目的是不断追加单个文件，相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。带来的麻烦是，如果一台HRegionServer下线，为了恢复其上的region，需要将HRegionServer上的log进行拆分，然后分发到其它HRegionServer上进行恢复。

2.3 用户写入数据流程

        1. Client客户端写入数据后 -> 数据存入MemStore，一直到MemStore满之后 Flush成一个StoreFile，直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile。

        2. 同时进行版本合并和数据删除 -> 当StoreFiles Compact后，逐步形成越来越大的StoreFile ->单个StoreFile大小超过一定阈值后，触发Split操作，把当前Region分成2个Region，Region会下线，新分出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。