HBase系统架构

一.HMaster

1.在HBase中，当第一次启动HMaster，会在Zookeeper的/hbase节点下注册一个子节点/hbase/master
2.在HBase，HMaster不存在单点故障问题，因为可以启动多个HMaster，先启动的HMaster作为active节点使用，后启动的HMaster会作为backup节点使用
3.后启动的HMaster会在Zookeeper的/hbase/backup-masters节点下注册一个子节点
4.Active HMaster定时向Zookeeper发送心跳维系/hbase/master节点，如果超过一定时间（默认是180s，实际过程中一般会将这个值调整为60s左右）Zookeeper没有收到心跳，认为这个节点已经lost，Zookeeper就会从backup-masters中选择一个节点切换为active状态
5.Active HMaster和Backup HMaster之间要进行定时更新 - Active HMaster监听Zookeeper中/hbase/backup-masters
6.Backup HMaster也要定时向Zookeeper发送心跳
7.虽然理论上不限制Backup HMaster的数量，但是实际开发中一般是设置1-2个Backup HMaster就行
8.职能：
（1）负责HRegion的分配 - HMaster负责HRegion的负载均衡，将HRegion平均分配到HRegionServer上
（2）负责表的管理：create、drop
（3）监控HRegionServer

二.Zookeeper

1.在HBase作为一个监控者和协调者来使用
2.Zookeeper监控HMaster，负责HMaster之间的状态的切换
3.Zookeeper监控HRegionServer，将Region server的上线和下线信息实时通知给Master

三.HRegionServer

1.HRegionServer负责管理HRegion，每一个HRegionServer最多可以管理1000个HRegion
2.HRegionServer由HRegion、WAL和BlockCache构成

3.WAL - Write Ahead Log — HLog：
（1）WAL用于记录写操作的
（2）HRegionServer在接收到写请求之后，会将写操作先记录到WAL中，然后再更新到memStore中，这样设计的目的是为了崩溃恢复以保证数据的完整性
（3）当WAL达到默认大小（1G）的时候，会产生一个新的WAL
（4）WAL会被定期清理，默认是168H清理一次
（5）在HRegionServer中，默认只有1个在使用的WAL
（6）在0.94版本以前，WAL只允许串行写（多个请求排队）；从0.94版本开始，采用了管道机制允许对WAL进行并行写

4.BlockCache - 读缓存：
（1）每一个HRegionServer只有一个BlockCache
（2）HBase为了提高读取的效率，在BlockCache引入了"局部性原理" - 局部性的原理的目的实际上就是为了提高命中率：
时间局部性：如果某一条数据被读取过一次，那么就认为这条数据再次被读取的概率会大于其他没有被读取的数据，那么就将这条数据放入读缓存中
空间局部性：如果某一条数据被读取，那么就认为这条数据相邻的数据被读取的概率也比其他数据读取的概率大，也会将相邻的数据放入读缓存中
（3）LRU策略：移除最长时间没有被使用的数据

四.写流程

1.先将写操作记录到HLog中，然后将数据更新到memStore中
2.数据在memStore中会进行排序
3.如果memStore达到条件之后，将memStore中数据flush到HFile中：
（1）当memStore达到128M的时候，进行冲刷
（2）当一个HRegionServer上的所有的memStore所占用的内存之和占到总内存35%的时候，大一些的memStore就会被冲刷
（3）当WAL达到1G的时候，memStore也会进行flush，防止数据丢失
4.单个HFile是有序的，所有的HFile是局部有序 - HRegion之间的范围不会重合，但是HFile之间的范围是可能重合的
5…HFile第一个版本的格式

（1）Data Block：数据块
每一个数据块中包含多条数据，数据块默认大小是64KB，可以根据需求设置，大号的Block有利于顺序Scan，小号Block利于随机查询，因而需要权衡
Magic：魔数是一个随机的数字，用于防止数据的破坏，如果当前的datablock被别人修改，则此数会发生变化
读缓存在缓存的时候，也是以DataBlock为单位进行缓存 - 当读取DataBlock中的某一条数据的时候，这个DataBlock会整个的缓存到BlockCache中
（2）Meta Block：元数据块。这个信息实际开发中一般不关心
（3）File Info：对文件信息的描述
（4）Data Index：记录数据的下标，即data起始和结束位置
（5）Meta Index：元数据的下标，即Meta起始和结束位置
（6）Trailer：固定只有4个字节，记录File Info，Data Index，Meta Index起始位置
（7）HFile里面的每个KeyValue对就是一个简单的byte数组。但是这个byte数组里面包含了很多项，并且有固定的结构

a.开始是两个固定长度的数值，分别表示Key的长度和Value的长度
b.然后是Key，key的开始是固定长度的数值，表示RowKey的长度，紧接着是 RowKey，然后是固定长度的数值，表示Family的长度，然后是Family，接着是Qualifier，然后是两个固定长度的数值，表示Time Stamp和Key Type（string/int）
c.Value部分没有这么复杂的结构，就是纯粹的二进制数据了。随着HFile版本迁移，KeyValue(Cell)的格式并未发生太多变化，只是在V3版本，尾部添加了一个可选的Tag数组，用来记录数据是否删除。

6.HFile在第二个版本中，基于第一个版本的基础上添加了Bloom Filter - 布隆过滤器。

布隆过滤器:
概述：
1.Bloom Filter是1970年由布隆（Burton Howard Bloom）提出的
2.它实际上是一个很长的二进制向量和一系列随机映射函数（Hash函数）
3.布隆过滤器可以用于检索一个元素是否在一个集合中
4.它的优点是空间效率和查询时间都远远超过一般的算法
5.Bloom Filter广泛的应用于各种需要查询的场合中，如：Google 著名的分布式数据库 Bigtable 使用了布隆过滤器来查找不存在的行或列，以减少磁盘查找的IO次数
6.在很多Key-Value系统中也使用了布隆过滤器来加快查询过程，如 Hbase，Accumulo，Leveldb，一般而言，Value 保存在磁盘中，访问磁盘需要花费大量时间，然而使用布隆过滤器可以快速判断某个Key对应的Value是否存在，因此可以避免很多不必要的磁盘IO操作，只是引入布隆过滤器会带来一定的内存消耗

Bloom Filter 原理：
1.如果想判断一个元素是不是在一个集合里，一般想到的是将所有元素保存起来，然后通过比较确定，链表，树等等数据结构都是这种思路.。但是随着集合中元素的增加，需要的存储空间越来越大，检索速度也越来越慢。
2.一个Bloom Filter是基于一个m位的位向量（b1,…bm），这些位向量的初始值为0。另外，还有一系列的hash函数（h1,…hk）（默认是3个哈希函数），这些hash函数的值域属于1~m。下图是一个bloom filter插入x,y,z并判断某个值w是否在该数据集的示意图：

3.布隆过滤器的缺点和优点一样明显。误算率（False Positive）是其中之一。随着存入的元素数量增加，误算率随之增加。但是如果元素数量太少，则使用散列表足矣
4.总结：Bloom Filter 通常应用在一些需要快速判断某个元素是否属于集合，但是并不严格要求100%正确的场合。此外，引入布隆过滤器会带来一定的内存消耗

五.读流程

1.首先对新写入的Cell，它会存在于MemStore中；然后对之前已经Flush到HFile中的Cell，它会存在于某个或某些StoreFile(HFile)中；最后，对刚读取过的Cell，它可能存在于BlockCache中
2.既然相同的Cell可能存储在三个地方，在读取的时候只需要扫瞄这三个地方，然后将结果合并即可(Merge Read)，在HBase中扫瞄的顺序依次是：BlockCache、MemStore、StoreFile(HFile)（这个扫描顺序的目的也是为了减少磁盘的I/O次数）
3.其中StoreFile的扫瞄先会使用Bloom Filter(布隆过滤算法）过滤那些不可能符合条件的HFile，然后使用Block Index快速定位Cell，并将其加载到BlockCache中，然后从BlockCache中读取。
4.一个HStore可能存在多个StoreFile(HFile)，此时需要扫瞄多个HFile，如果HFile过多又是会引起性能问题

六.Compaction机制

1.MemStore每次Flush会创建新的HFile，而过多的HFile会引起读的性能问题。为了解决这个问题，HBase采用Compaction机制来解决这个问题。在HBase中Compaction分为两种：Minor Compaction和Major Compaction
2.Minor Compaction是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次Minor Compaction的结果是减少Store File的数量但是产生更大的StoreFile

3.Major Compaction是指将所有的StoreFile合并成一个StoreFile，在这个过程中，标记为Deleted的Cell会被删除，而那些已经Expired的Cell会被丢弃，那些已经超过最多版本数的Cell会被丢弃。一次Major Compaction的结果是一个HStore只有一个StoreFile存在。Major Compaction可以手动或自动触发，然而由于它会引起很多的I/O操作而引起性能问题，因而它一般会被安排在周末、凌晨等集群比较闲的时间