体系图：
一.写流程
1.client向hregionserver发送写请求。
2.hregionserver将数据写到hlog（write ahead log）。为了数据的持久化和恢复。
3.hregionserver将数据写到内存（memstore）
4.反馈client写成功。
二.数据flush过程
1.当memstore数据达到阈值（默认是128M），将数据刷到硬盘，将内存中的数据删除，同时删除Hlog中的历史数据。
2.并将数据存储到hdfs中。
3.在hlog中做标记点。
三.数据合并过程
1.当数据块达到8块，hmaster将数据块加载到本地，进行合并
2.当合并的数据超过512M，进行拆分，将拆分后的region分配给不同的hregionserver管理
3.当hregionser宕机后，将hregionserver上的hlog拆分，然后分配给不同的hregionserver加载，修改.META.
4.注意：hlog会同步到hdfs
四.hbase的读流程
1.通过zookeeper .META.表定位hregionserver。
2.数据从内存和硬盘合并后返回给client
3.数据块会缓存
五.hmaster的职责
1.管理用户对Table的增、删、改、查操作；
2.记录region在哪台Hregion server上
3.在Region Split后，负责新Region的分配；
4.新机器加入时，管理HRegion Server的负载均衡，调整Region分布
5.在HRegion Server宕机后，负责失效HRegion Server 上的Regions迁移。
六.hregionserver的职责
HRegion Server主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBASE中最核心的模块。
HRegion Server管理了很多table的分区，也就是region。
七.Region寻址方式
2层结构其实完全能满足业务的需求，因此0.96版本以后将-ROOT-表去掉了。
访问路径变成了3步：
第1步：Client请求ZK获取.META.所在的RegionServer的地址。
第2步：Client请求.META.所在的RegionServer获取访问数据所在的RegionServer地址，client会将.META.的相关信息cache下来，以便下一次快速访问。
第3步：Client请求数据所在的RegionServer，获取所需要的数据。
总结去掉-ROOT-的原因有如下2点：
其一：提高性能
其二：2层结构已经足以满足集群的需求
这里还有一个问题需要说明，那就是Client会缓存.META.的数据，用来加快访问，既然有缓存，那它什么时候更新？如果.META.更新了，比如Region1不在RerverServer2上了，被转移到了RerverServer3上。client的缓存没有更新会有什么情况？
其实，Client的元数据缓存不更新，当.META.的数据发生更新。如上面的例子，由于Region1的位置发生了变化，Client再次根据缓存去访问的时候，会出现错误，当出现异常达到重试次数后就会去.META.所在的RegionServer获取最新的数据，如果.META.所在的RegionServer也变了，Client就会去ZK上获取.META.所在的RegionServer的最新地址。
八.LSM树
为了克服B+树的弱点，HBase引入了LSM树的概念，即Log-Structured Merge-Trees。
为了更好的说明LSM树的原理，下面举个比较极端的例子：
现在假设有1000个节点的随机key，对于磁盘来说，肯定是把这1000个节点顺序写入磁盘最快，但是这样一来，读就悲剧了，因为key在磁盘中完全无序，每次读取都要全扫描；
那么，为了让读性能尽量高，数据在磁盘中必须得有序，这就是B+树的原理，但是写就悲剧了，因为会产生大量的随机IO，磁盘寻道速度跟不上。
LSM树本质上就是在读写之间取得平衡，和B+树相比，它牺牲了部分读性能，用来大幅提高写性能。
它的原理是把一颗大树拆分成N棵小树， 它首先写入到内存中（内存没有寻道速度的问题，随机写的性能得到大幅提升），在内存中构建一颗有序小树，随着小树越来越大，内存的小树会flush到磁盘上。当读时，由于不知道数据在哪棵小树上，因此必须遍历所有的小树，但在每颗小树内部数据是有序的。
版权申明：版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。
