Hbase 架构及其读写原理
1、HBase 简介
HBase —— hadoop Database的简称，Google BigTable的另一种开源实现方式，从问世之初，就为了解决用大量廉价的机器高速存取海量数据、实现数据分布式存储提供可靠的方案。
从功能上来讲，HBase不折不扣是一个数据库，与我们熟悉的Oracle、MySQL、MSSQL等一样，对外提供数据的存储和读取服务。
从应用的角度来说，HBase与一般的数据库又有所区别，HBase本身的存取接口相当简单，不支持复杂的数据存取，更不支持SQL等结构化的查询语言；HBase也没有除了rowkey以外的索引，所有的数据分布和查询都依赖rowkey。
所以，HBase在表的设计上会有很严格的要求。架构上，HBase是分布式数据库的典范，这点比较像MongoDB的sharding模式，能根据键值的大小，把数据分布到不同的存储节点上，MongoDB根据configserver来定位数据落在哪个分区上；HBase通过访问Zookeeper来获取-ROOT-表所在地址，通过-ROOT-表得到相应.META.表信息，从而获取[数据存储]的region位置。
2、架构
HBase是一个分布式的架构，除去底层存储的HDFS外，HBase本身从功能上可以分为三块：Zookeeper群、Master群和RegionServer群。
2.1 Zookeeper群：
主要用于存储Master地址、协调Master和RegionServer等上下线、存储临时数据等。
hmaster启动时候会将hbase系统表-ROOT-表(获取当前系统表.META.的存储所对应的regionserver信息) 加载到 zookeeper cluster。
2.2 Master群：
为Region server分配region
负责Region server的负载均衡
发现失效的Region server并重新分配其上的region
HDFS上的垃圾文件回收
处理schema更新请求
2.3 RegionServer群：
RegionServer群是真正数据存储的地方，每个RegionServer由Hlog和若干个region组成，而一个region维护了一定区间rowkey值的数据。
3 RegionServer定位
访问HBase通过HBase客户端(或API)进行，整个HBase提供给外部的地址，其实是Zookeeper的入口，Zookeeper中有保存-ROOT-所在的RegionServer地址，从-ROOT-表可以获取.META.表信息，根据.META.表可以获取region在RegionServer上的分布，整个region寻址过程大致如下：
首先，Client通过访问Zookeeper来请求目标数据的地址。
Zookeeper中保存了-ROOT-表的地址，所以ZK通过访问-ROOT-表来请求数据地址。
同样，-ROOT-表中保存的是.META.的信息，通过访问.META.表来获取具体的RegionServer。
.META.表查询到具体RS信息后返回具体RegionServer地址给Client。
Client端获取到目标地址后，然后直接向该地址发送数据请求。
4 Region数据写入
HBase通过ZK —> -ROOT- —> .META.的访问获取RS地址后，直接向该RS上进行数据写入操作，客户端整个过程如下图：
服务端整个流程：
5 Region数据读取(服务端整个流程)
6 Compact
大量HFile的产生，会消耗更多的文件句柄，同时会造成RegionServer在数据查询等的效率大幅度下降，HBase为解决这个问题，引入了compact操作，RegionServer通过compact把大量小的HFile进行文件合并，生成大的HFile文件。RegionServer上的compact根据功能的不同，可以分为两种不同类型，即：minor compact和major compact。
6.1 Minor Compact
minor compact又叫small compact，在RegionServer运行过程中会频繁进行，主要通过参数hbase.hstore.compactionThreshold进行控制，该参数配置了HFile数量在满足该值时，进行minor compact，minor compact只选取region下部分HFile进行compact操作，并且选取的HFile大小不能超过hbase.hregion.max.filesize参数设置。
6.2 Major Compact
相反major compact也被称之为large compact，major compact会对整个region下相同列簇的所有HFile进行compact，也就是说major
compact结束后，同一个列簇下的HFile会被合并成一个。major compact是一个比较长的过程，对底层I/O的压力相对较大。
major compact除了合并HFile外，另外一个重要功能就是清理过期或者被删除的数据。前面提到过，HBase的delete操作也是通过append的方式写入，一旦某些数据在HBase内部被删除了，在内部只是被简单标记为删除，真正在存储层面没有进行数据清理，只有通过major compact对HFile进行重组时，被标记为删除的数据才能被真正的清理。
compact操作都有特定的线程进行，一般情况下不会影响RegionServer上数据写入的性能，当然也有例外：在compact操作速度跟不上region中HFile增长速度时，为了安全考虑，RegionServer会在HFile达到一定数量时，对写入进行锁定操作，直到HFile通过compact降到一定的范围内才释放锁。
7 Split
compact将多个HFile合并单个HFile文件，随着数据量的不断写入，单个HFile也会越来越大，大量小的HFile会影响数据查询性能，大的HFile也会，HFile越大，相对的在HFile中搜索的指定rowkey的数据花的时间也就越长，HBase同样提供了region的split方案来解决大的HFile造成数据查询时间过长问题。一个较大的region通过split操作，会生成两个小的region，称之为Daughter，一般Daughter中的数据是根据rowkey的之间点进行切分的，region的split过程大致如下图：
region split流程
region先更改Zookeeper中该region的状态为SPLITING。
Master检测到region状态改变。
region会在存储目录下新建.split文件夹用于保存split后的daughter region信息。
Parent region关闭数据写入并触发flush操作，保证所有写入Parent region的数据都能持久化。
在.split文件夹下新建两个region，称之为daughter A、daughter B。
Daughter A、Daughter B拷贝到HBase根目录下，形成两个新的region。
Parent region通知修改.META.表后下线，不再提供服务。
Daughter A、Daughter B上线，开始向外提供服务。
如果开启了balance_switch服务，split后的region将会被重新分布。
split的整个过程，split过程非常快，速度基本会在秒级内，那么在这么快的时间内，region中的数据怎么被重新组织的？其实，split只是简单的把region从逻辑上划分成两个，并没有涉及到底层数据的重组，split完成后，Parent region并没有被销毁，只是被做下线处理，不再对外部提供服务。而新产生的region Daughter A和Daughter B，内部的数据只是简单的到Parent region数据的索引，Parent region数据的清理在Daughter A和Daughter B进行major compact以后，发现已经没有到其内部数据的索引后，Parent region才会被真正的清理。
8 HHFile存储数据主要是Data Block
