HBase架构实现

1、 存储

不同的排序、搜索算法在性能上差别可以非常大，从O(n^2)到O(log2N)甚至O(1)。同样不能的存储模型和索引结构对数据库的读写性能影响很大。HBase通过LSM存储模型提高写性能的同时又能保证读性能。
B+树比B树更适合做数据库系统索引。尤其是对于HBase这类常用区间扫描的数据库，因为B+树只需要遍历所有叶子节点即可实现区间扫描，B+树的最大性能问题就是插入，随着越来越多的数据插入，叶子节点会慢慢分裂，逻辑上会存储到磁盘的不痛快，做区间扫描产生大量随机读IO，同时数据写入时维护树的分裂、合并也会产生大量随机写IO。

2、 LSM树

为了解决B+树随机写IO的问题，HBase引入了LSM树（log structured merge-trees）,LSM的核心思想是将一颗大树拆分成多棵小树，HBase数据的写入都会先写MemStore，在内存中构建一颗有序的小树，当MemStore达到一定条件时即会刷新输出写入到磁盘，所以写入速度很快。这里的弊端是随着数据量的增大，StoreFile（即小树）会越来越多，导致查询数据时需要扫描所有的文件，显然文件越多，扫描效率越低。

LSM的merge（合并），当MemStore刷新后StoreFile达到配置的数量或者距离上次压缩时间满足配置的间隔时，HBase即会自动触发压缩（MINOR和MAJOR），合并成一棵大树。

LSM的核心思想是通过牺牲一定的读性能来换取写能力的最大化。为了避免读性能下降成为瓶颈，HBase也提供了一些其他策略。例如：布隆过滤器等过滤查询所需要读取的文件数量以提高读性能。
LSM为了提高写性能，数据先写入内存，如果服务器宕机或者断点，就会导致内存数据丢失，为了解决该问题，HBase引入了WAL。

3、 预写入日志（WAL）

WAL（write ahead log）即预写入日志。由于LSM为了提高写性能，数据先写入内存，如果服务器宕机或者断点会导致内存数据丢失，HBase写入内存之前也需要写WAL以便异常恢复。

USE_DEFAULT:默认的持久化策略
SKIP_WAL:不写WAL
ASYNC_WAL:异步写入
FSYNC_WAL:等同于sync_wal

当HBase客户端向服务端分区服务器提交数据修改请求后，分区服务器的RPC处理线程池负责接收处理这些请求，客户端与服务端的数据交互格式为Protobuf。在WAL的写入过程中使用了一个叫做LMAX Disruptor的高性能缓存对垒RingBuffer，RPCHandler作为生产者向RingBuffer按序列添加数据变更封装成的WALEdit，而FSHLog的内部类作为消费者从队列读取数据然后写入文件系统，这个生产消费模型是一个多生产者单消费者模型，单消费者按RingBuffer序列顺序刷新数据到文件系统，保证WAL并发写入只有一个线程在真正写入文件，做到分区服务器全局唯一，WAL的实现类为FSHLog.java。

4、 数据写入读取

HBase数据的写入与读取需要客户端先通过读取HMaster节点上的元数据定位到本次插入或者读取数据所在分区由那个分区服务器负责，之后HBase客户端直接与定位到的分区服务器通信。

分区是Hbase浮在均衡的最小单元，均衡的分布在HBase集群的每台分区服务器。HBase客户端进行数据查询、修改、删除等操作时，都需要先定位操作数据所在的分区，以及分区由那个分区服务器负责。HBase依赖Zookeeper来实现分区服务器的定位。

第三步，由于前面已经缓存了分区的开始结束行键以及所在分区服务器地址，因此之后的数据操作请求只需与对应的分区服务器交互，除非hbase客户端捕捉到IOException，此时HBase客户端会清除缓存，重新拉取分区位置信息。

注意：HBase客户端会将hbase：meta表数据缓存在本地，因此大部分情况下前两步只有在客户端第一次做数据操作请求的时候发生，因而对Zookeeper集群的压力很小。

HBase提供的客户端数据查询操作类包括Scan、Get，Get请求会被封装成Scan，然后当成一个特殊的Scan类型处理。

5、 协处理器

通过协处理器，我们可以把客户端复杂的计算逻辑移动到分区服务器去处理，即在数据的实际存储位置执行计算，这就是常说的移动“计算”比移动“数据”容易，数据在服务端处理完之后，再讲处理结果返回给客户端，这样就避免了大量的网络IO，效率大大提高。
因为协处理器是运行在服务端的，一旦代码有bug或者性能问题，对HBase集群性能甚至数据完整性等都有可能造成不可恢复的影响。

协处理器分为两大类：观察者类型协处理器、断点类型协处理器。

协处理器的具体使用方式请自行查找，不做更新