HBase组件
HBase是典型的主从架构，包含三种类型的server。Client直接与Region server通信进行数据读写，HBase Master负责region分配、DDL(创建、删除表)等操作，Zookeeper则负责维护集群状态。
每个RegionServer与DataNode协作的，其所管理的数据都由对应的DataNode存储。所有的HBase数据都保存为HDFS文件形式。这是一种本地化策略，所有的读写操作都是在RegionServer所在机器完成，当然不包括region被移动的情况。
NameNode维护了所有数据块的元数据信息。
Regions
在水平方向上，HBase Tables根据RowKey被划分为多个Region。一个Region包含了在start key和end key之间的所有行。这些Region被分配到集群中不同的节点上，也就是Region Server。一个Region Server大约可以管理1000个Region。
HBase Master
Region分配、DDL操作都是由HBase Master进行管理。
Master负责的内容如下：
-
协调region servers
- 系统启动时分配regions，进行宕机恢复或者负载均衡时重新分配regions
- 管理集群中Region Server实例（监听Zookeeper通知） 管理功能
- 创建、删除、更新表
Zookeeper-协调者
HBase使用Zookeeper实现分布式环境中的一致性，它可以维护集群的共享状态，在Master失败时选举新的Master，在Region Server失败时发送通知，以便恢复。值得注意的是为了保证一致性，我们一般使用3台或者5台机器构建Zookeeper集群。
组件如何协同工作
Zookeeper是用于协调分布式系统成员之间的共享状态信息。Region Servers和活跃的HMaster通过session连接到Zookeeper，然后Zookeeper通过心跳为这些session创建临时结点。
每个Region Server都会创建在Zookeeper中创建一个临时结点，之后HMaster可以通过这些临时结点发现集群中可用的Region Server，当然也可以发现宕机的server。HMasters同样回创建临时结点，Zookeeper会选择第一个创建的HMaster临时结点，将其作为active的主节点，其他HMasters作为备用进行failover。active的HMaster向Zookeeper发送心跳，其他HMasters监听active HMaster失败的通知。
如果某个region sersver或者HMaster无法发送心跳，对应的session会过期，然后对应临时结点会被删除。监听器会监听到结点被删除。HMaster监听到region server不可用时，会进行region server的故障恢复。Inactive的HMaster监听到HMaster的失败时，它会尝试变为active HMaster。
HBase读写
HBase中有一个特殊的表叫做META表，其中保存了regions的位置。而这个表是保存着在Zookeeper中的。
当客户端要向HBase进行读写操作时，流程如下：
1.从Zookeeper获取META表信息
2.根据要查询的RowKey从META中匹配对应的Region Server，这些信息都会缓存下来
3.从对应Region Server读取行
对于接下来的读写请求，client直接使用缓存获取相应Region Server。除非region被移动导致缓存没有命中，它才会重现获取META表并更新缓存。
HBase Meta Table
Meta Table保存了系统中regions列表。
Meta Table像一棵B+树
-
Meta Table的结构如下：
- Key:region start key, region id
- Values:RegionServer
Region Server组成
Region Server是运行在HDFS的datanode之上，包含了以下部分：
- WAL：Write Ahead Log是为了存储还没有持久化数据的插入或者更新日志，以便在fail over时恢复数据。
- BlockCache：读缓存，存储了经常读取的数据，采用LRU算法。
- MemStore：写缓存，存储了还未持久化的新数据，在持久化之前会进行排序。每一个column family,每一个region都有一个MemStore。
- Hfiles：在磁盘上存储了行的排序键值对。
HBase写步骤-1
当client发起一个写请求，首先将数据写入write-ahead log，WAL的特性：
- 编辑操作是追加到WAL文件尾部。
- WAL是为了在服务宕机时恢复还未持久化的数据。
HBase写步骤-2
一旦数据追加到WAL之后，数据就会存入MemStore，然后写请求操作完成，并返回给客户端应答。
HBase MemStore
MemStore在内存中把数据保存为排序键值对，与磁盘上的HFile是一样的。
每个column family一个MemStore，更新操作也会进行排序。
HBase Region刷盘
每当MemStore积累了足够的数据，排序的数据集整个写入到HDFS上的HFile中。HBase每个column family都使用很多个这样的HFile存储实际的Key-Value数据。随着MemStore写满刷盘，会不停的创建HFiles。
这也是HBase限制column family数量的一个原因，因为每个CF有一个MemStore，每当MemStore写满，然后刷盘就会创建这样一个文件。同时最后一个写序号也会持久化。
最大的序号作为HFile的元字段存储，它可以反映持久化在哪里结束，将在哪里开始。当一块Region初始化时，所有序号读入内存，最大的序号被用于新的编辑操作。
HBase HFile
HFile存储了实际的数据，形式是排序的key/values。MemStore刷盘是顺序写的过程，速度非常快。
HBase HFile 结构
HFile使用了三级索引结构使得HBase可以快速查询数据而不用遍历整个文件。多级索引结构比较像B+树。
- key/value是升序存储的。
- 通过rowkey索引“64KB”的blocks
- 每个block有自己的叶子索引
- 每个block最后一个rowkey放在中间索引
- 根索引指向了中间索引
Trailer指向数据块元信息，存储在文件的尾部。Trailer包含bloom filter和时间区间信息，bloom filter可以帮助判断文件是否包含指定rowkey，时间区间也可以帮助判断文件是否同rowkey时间版本一致。
HFile Index
HFile索引被加载到内存中，通过索引可以通过一次磁盘寻址完成查询。
HBase读合并
从上面的内容可以知道，rowkey对应的KeyValue可以出现在很多地方，已经持久化的存储在HFile中，最近读取的缓存在BlockCache中，最近更新的保存在MemStore中，那么当我们读取一行时，HBase是如何返回相应的Column KeyValue？其实读操作会合并从BlockCache、MemStore、HFile查询的结果：
- 首先从读缓存即Block Cache中读row cells。
- 然后从写缓存即MemStore中读row cells。
- 如果在前两步中没有拿到所有的row cells，那么将通过BlockCache和bloom filter将可能包含row的HFile加载到内存中
对于行的内容来说可能分布在多个HFile中，那么读时需要检查多个HFile，这回导致读取速度变慢。
HBase Minor Compaction
HBase会自动的将一些小的HFiles，通过归并排序的方式，合并为大的HFile，从而减少系统中HFile的数量。这个过程叫做minor compaction。
HBase Major Compaction
HBase还可以通过Major Compaction合并整个系统中的HFiles，每个region的每个Column family的HFiles会合并为一个HFile，这可以提高系统的读性能。但是由于在此过程中，HBase需要重写所有的文件，会占用大量的磁盘IO和网络带宽，会影响系统的写性能。
建议Major Compaction在晚上或者周末执行，以免影响系统性能。
Region = Contiguous Keys
下面是一些关于region的描述：
- 表在水平方向上被划分为多个regions，每个region包含了连续的、按key排序的行，key的范围在region的start key和end key之间。
- 每个region默认大小上1GB。
- Region由RegionServer管理，向client提供服务。
- 每个RegionServer可以管理约1000个regions。
Region Split
最开始每个Table只有一个region，当存储的数据越来越多，region分解为两个子region，并向HMaster报告。当集群负载不均衡时，HMaster可能将region分配到其他Region Server。
