参考文献：
[1]《HBase原理与实践》胡争，范欣欣著
1.前言介绍大数据技术的原理书籍有很多，但《HBase原理与实践》这本书真的是我觉得写得特别棒的一本。条理清晰，内容简单明了，个人认为是这两年当之无愧的No.1。
本来想在文章里放个京东链接的，然而发现自己无法开通广告权限，想买的童鞋自行搜索。
在之前大致读过该书后，决定细读第二遍。这次要把所有的知识点都整理下来，记在脑子里。
2.HBase架构hbase-arch.pngHBase体系结构借鉴了Google的BigTable论文，这是众所周知的。它是典型的Master-Slave模型。系统中有一个管理集群的Master节点，以及大量实际提供存储和读写服务的RegionServer节点。HBase中所有数据最终都存储在HDFS上，这与BigTable实际数据存储在GFS中对应。另外还使用了ZooKeeper协助Master进行集群管理。
2.1HBase客户端提供了Shell、JavaAPI、Thrift/RESTAPI接口以及MapReduce接口。
2.2ZooKeeper与Hadoop一样，协助HBase实现高可用，当Master宕机了以后，ZooKeeper会帮忙选出新的Master。
除此之外，ZooKeeper还管理系统核心元数据：比如，管理当前系统中正常工作的RegionServer集合，保存系统元数据表hbase:meta所在的RegionServer地址等。
HBase还通过ZooKeeper实现分布式表锁。HBase对一张表进行各种管理操作需要先上锁，这是通过ZooKeeper来实现的。
2.3MasterMaster主要负责HBase系统的各种管理工作：
处理用户的各种管理请求：包括建表、修改表、权限操作、切分表、合并数据分片以及Compaction等。
管理所有RegionServer，包括RegionServer中Region的负载均衡，RegionServer的宕机恢复，和Region的迁移等。
清理过期WAL。
2.4RegionServer是HBase最核心的模块。由WAL（HLog）、BlockCache和多个Region构成。
WAL（HLog）：HLog在HBase中有两个核心作用：其一，用于实现数据高可靠性。，HBase数据随机写入时，并非直接写入HFile数据文件，而是先写入缓存，再异步刷新落盘。为了防止缓存数据丢失，数据写入缓存之前需要首先顺序写入HLog，这样，即使缓存数据丢失，仍然可以通过HLog日志恢复；其二，用于实现HBase集群间主从复制，通过回放主集群推送过来的HLog日志实现主从复制。
BlockCache：HBase的读缓存。客户端从磁盘读取数据之后通常会将数据缓存到系统内存中，后续访问同一行数据可以直接从内存中获取而不需要访问磁盘。对于带有大量热点读的业务请求来说，缓存机制会带来极大的性能提升。
BlockCache缓存对象是一系列Block块，一个Block默认为64K，由物理上相邻的多个KV数据组成。BlockCache同时利用了空间局部性和时间局部性原理，前者表示最近将读取的KV数据很可能与当前读取到的KV数据在地址上是邻近的，缓存单位是Block（块）而不是单个KV就可以实现空间局部性；后者表示一个KV数据正在被访问，那么近期它还可能再次被访问。当前BlockCache主要有两种实现——LRUBlockCache和BucketCache，前者实现相对简单，而后者在GC优化方面有明显的提升。
Region：数据表的一个分片。当数据表大小超过一定阈值就会“水平切分”，分裂为两个Region。Region是集群负载均衡的基本单位。通常一张表的Region会分布在整个集群的多台RegionServer上，一个RegionServer上会管理多个Region，当然，这些Region一般来自不同的数据表。
每个Store由一个MemStore和一个或多个HFile组成。MemStore称为写缓存，用户写入数据时首先会写到MemStore，当MemStore写满之后（缓存数据超过阈值，默认M）系统会异步地将数据flush成一个HFile文件。显然，随着数据不断写入，HFile文件会越来越多，当HFile文件数超过一定阈值之后系统将会执行Compact操作，将这些小文件通过一定策略合并成一个或多个大文件。
2.5HDFSHBase底层依赖HDFS存储。HBase内部封装了一个名为DFSClient的HDFS客户端组件，负责对HDFS的实际数据进行读写访问。
3.HBase的优缺点3.1优点容量巨大：HBase的单表可以支持千亿行、百万列的数据规模，数据容量可以达到TB甚至PB级别。
良好的可扩展性：HBase集群可以非常方便地实现集群容量扩展，主要包括数据存储节点扩展以及读写服务节点扩展。HBase底层数据存储依赖于HDFS系统，HDFS可以通过简单地增加DataNode实现扩展，HBase读写服务节点也一样，可以通过简单的增加RegionServer节点实现计算层的扩展。
稀疏性：HBase支持大量稀疏存储，即允许大量列值为空，并不占用任何存储空间。
高性能：HBase目前主要擅长于OLTP场景，数据写操作性能强劲，对于随机单点读以及小范围的扫描读，其性能也能够得到保证。对于大范围的扫描读可以使用MapReduce提供的API，以便实现更高效的并行扫描。
多版本：HBase支持多版本特性，即一个KV可以同时保留多个版本，用户可以根据需要选择最新版本或者某个历史版本。
支持过期：HBase支持TTL过期特性，用户只需要设置过期时间，超过TTL的数据就会被自动清理，不需要用户写程序手动删除。
Hadoop原生支持：HBase是Hadoop生态中的核心成员之一，很多生态组件都可以与其直接对接。HBase数据存储依赖于HDFS，这样的架构可以带来很多好处，比如用户可以直接绕过HBase系统操作HDFS文件，高效地完成数据扫描或者数据导入工作；再比如可以利用HDFS提供的多级存储特性（ArchivalStorageFeature），根据业务的重要程度将HBase进行分级存储，重要的业务放到SSD，不重要的业务放到HDD。或者用户可以设置归档时间，进而将最近的数据放在SSD，将归档数据文件放在HDD。另外，HBase对MapReduce的支持也已经有了很多案例，后续还会针对Spark做更多的工作。
3.2缺点HBase本身不支持很复杂的聚合运算（如Join、GroupBy等）。如果业务中需要使用聚合运算，可以在HBase之上架设Phoenix组件或者Spark组件，前者主要应用于小规模聚合的OLTP场景，后者应用于大规模聚合的OLAP场景。
HBase本身并没有实现二级索引功能，所以不支持二级索引查找。好在针对HBase实现的第三方二级索引方案非常丰富，比如目前比较普遍的使用Phoenix提供的二级索引功能。
HBase原生不支持全局跨行事务，只支持单行事务模型。同样，可以使用Phoenix提供的全局事务模型组件来弥补HBase的这个缺陷。
4.基本概念和数据结构4.1KeyValue存储格式HBase最底层的数据存储格式。
hbase-kv.png总体来说，字节数组主要分为以下几个字段。其中Rowkey、Family、Qualifier、Timestamp、Type这5个字段组成KeyValue中的key部分。
keyLen：占用4字节，用来存储KeyValue结构中Key所占用的字节长度。
valueLen：占用4字节，用来存储KeyValue结构中Value所占用的字节长度。
rowkeyLen：占用2字节，用来存储rowkey占用的字节长度。
rowkeyBytes：占用rowkeyLen个字节，用来存储rowkey的二进制内容。
familyLen：占用1字节，用来存储Family占用的字节长度。
familyBytes：占用familyLen字节，用来存储Family的二进制内容。
timestamp：占用8字节，表示timestamp对应的long值。
type：占用1字节，表示这个KeyValue操作的类型，HBase内有Put、Delete、DeleteColumn、DeleteFamily，等等。注意，这是一个非常关键的字段，表明了LSM树内存储的不只是数据，而是每一次操作记录。
qualifierBytes：占用qualifierLen个字节，用来存储Qualifier的二进制内容。注意，HBase并没有单独分配字节用来存储qualifierLen，因为可以通过keyLen和其他字段的长度计算出qualifierLen。
qualifierLen=keyLen(整个key的长度)-2B(存储rowkeyLen的字节)-rowkeyLen(存储rowkeyBytes)-1B(存储familyLen的字节)-familyLen(存储familyBytes)-8B(存储timestamp)-1B(存储type)
在比较KeyValue的大小顺序时，HBase按照如下方式确定大小关系：
int