一、Hbase的整体架构
1、Client客户端2、ZooKeeper集群3、HMaster4、HRegionServer5、Region 1. Hbase的数据存储原理2. Hbase读数据流程3. Hbase写数据流程4. Hbase的flush、compact机制
4.1 Flush触发条件
4.1.1 memstore级别限制4.1.2 region级别限制4.1.3 Region Server级别限制4.1.4 HLog数量上限4.1.5 定期刷新Memstore4.1.6 手动flush 4.2 flush的流程4.3 Compact合并机制4.3.1 minor compaction 小合并4.3.2 major compaction 大合并 5. Hbase表的预分区
5.1 预分区意义5.2 预分区原理5.3 手动指定预分区
一、Hbase的整体架构 1、Client客户端Client是操作Hbase集群的入口，对于管理类的操作，如表的增、删、改操纵，Client通过RPC与HMaster通信完成，对于表数据的读写操作，Client通过RPC与RegionServer交互，读写数据。
Client类型：
Hbase shellJava编程接口Thrift、Avro、Rest等等 2、ZooKeeper集群
作用：
1、实现了HMaster的高可用，多HMaster间进行主备选举
2、保存了Hbase的元数据信息meta表，提供了Hbase表中region的寻址入口的线索数据
3、对HMaster和HRegionServer实现了监控
Hbase集群也是主从架构，HMaster是主的角色，主要负责Table表和Region的相关管理工作，管理Client对Table的增删改的操作，在Region分裂后，负责新Region分配到指定的HRegionServer上，管理HRegionServer间的负载均衡，迁移region分布。当HRegionServer宕机后，负责其上的region的迁移。
4、HRegionServerHbase集群中从的角色，作用为响应客户端的读写数据请求、负责管理一系列的Region、切分在运行过程中变大的region。
5、RegionHbase集群中分布式存储的最小单元，一个Region对应一个Table表的部分数据。
如下为Hbase的整体架构图：
一个HRegionServer会负责管理很多个region，一个region包含很多个store，一个列族就划分成一个store。
（ 如果一个表中只有1个列族，那么这个表的每一个region中只有一个store，如果一个表中有N个列族，那么这个表的每一个region中有N个store）一个store里面只有一个memstore，memstore是一块内存区域，写入的数据会先写入memstore进行缓冲，然后再把数据刷到磁盘。一个store里面有很多个StoreFile, 最后数据是以很多个HFile这种数据结构的文件保存在HDFS上。StoreFile是HFile的抽象对象，如果说到StoreFile就等于HFile。每次memstore刷写数据到磁盘，就生成对应的一个新的HFile文件出来。
2. Hbase读数据流程
说明：Hbase集群，只有一张meta表，此表只有一个region，该region数据保存在一个HRegionServer上
1、客户端首先与zk进行连接；
从zk找到meta表的region位置，即meta表的数据存储在某一HRegionServer上；客户端与此HRegionServer建立连接，然后读取meta表中的数据；meta表中存储了所有用户表的region信息，我们可以通过scan 'hbase:meta'来查看meta表信息 2、根据要查询的namespace、表名和rowkey信息。找到写入数据对应的region信息3、找到这个region对应的regionServer，然后发送请求4、查找并定位到对应的region5、先从memstore查找数据，如果没有，再从BlockCache上读取
Hbase上Regionserver的内存分为两个部分
一部分作为Memstore，主要用来写；另外一部分作为BlockCache，主要用于读数据； 6、如果BlockCache中也没有找到，再到StoreFile上进行读取
从storeFile中读取到数据之后，不是直接把结果数据返回给客户端，而是把数据先写入到BlockCache中，目的是为了加快后续的查询；然后再返回结果给客户端。 3. Hbase写数据流程
1、客户端首先从zk找到meta表的region位置，然后读取meta表中的数据，meta表中存储了用户表的region信息
2、根据namespace、表名和rowkey信息。找到写入数据对应的region信息
3、找到这个region对应的regionServer，然后发送请求
4、把数据分别写到HLog（write ahead log）和memstore各一份
5、memstore达到阈值后把数据刷到磁盘，生成storeFile文件
6、删除HLog中的历史数据
HLog（write ahead log）：也称为WAL意为Write ahead log，类似mysql中的binlog,用来做灾难恢复时用，HLog记录数据的所有变更,一旦数据修改，就可以从log中进行恢复。
4. Hbase的flush、compact机制 4.1 Flush触发条件 4.1.1 memstore级别限制当Region中任意一个MemStore的大小达到了上限（hbase.hregion.memstore.flush.size，默认128MB），会触发Memstore刷新。
4.1.2 region级别限制hbase.hregion.memstore.flush.size 134217728
当Region中所有Memstore的大小总和达到了上限（hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size，默认 2* 128M = 256M），会触发memstore刷新。
4.1.3 Region Server级别限制hbase.hregion.memstore.flush.size 134217728 hbase.hregion.memstore.block.multiplier 4
当一个Region Server中所有Memstore的大小总和超过低水位阈值hbase.regionserver.global.memstore.size.lower.limit*hbase.regionserver.global.memstore.size（前者默认值0.95），RegionServer开始强制flush；先Flush Memstore最大的Region，再执行次大的，依次执行；如写入速度大于flush写出的速度，导致总MemStore大小超过高水位阈值hbase.regionserver.global.memstore.size（默认为JVM内存的40%），此时RegionServer会阻塞更新并强制执行flush，直到总MemStore大小低于低水位阈值
4.1.4 HLog数量上限hbase.regionserver.global.memstore.size.lower.limit 0.95 hbase.regionserver.global.memstore.size 0.4
当一个Region Server中HLog数量达到上限（可通过参数hbase.regionserver.maxlogs配置）时，系统会选取最早的一个 HLog对应的一个或多个Region进行flush
4.1.5 定期刷新Memstore默认周期为1小时，确保Memstore不会长时间没有持久化。为避免所有的MemStore在同一时间都进行flush导致的问题，定期的flush操作有20000左右的随机延时。
4.1.6 手动flush用户可以通过shell命令flush ‘tablename’或者flush ‘region name’分别对一个表或者一个Region进行flush。
4.2 flush的流程为了减少flush过程对读写的影响，将整个flush过程分为三个阶段：
prepare阶段：遍历当前Region中所有的Memstore，将Memstore中当前数据集CellSkipListSet做一个快照snapshot；然后再新建一个CellSkipListSet。后期写入的数据都会写入新的CellSkipListSet中。prepare阶段需要加一把updateLock对写请求阻塞，结束之后会释放该锁。因为此阶段没有任何费时操作，因此持锁时间很短。
flush阶段：遍历所有Memstore，将prepare阶段生成的snapshot持久化为临时文件，临时文件会统一放到目录.tmp下。这个过程因为涉及到磁盘IO操作，因此相对比较耗时。
commit阶段：遍历所有Memstore，将flush阶段生成的临时文件移到指定的ColumnFamily目录下，针对HFile生成对应的storefile和Reader，把storefile添加到HStore的storefiles列表中，最后再清空prepare阶段生成的snapshot。
4.3 Compact合并机制
hbase为了防止小文件过多，以保证查询效率，hbase需要在必要的时候将这些小的store file合并成相对较大的store file，这个过程就称之为compaction。
在hbase中主要存在两种类型的compaction合并
minor compaction 小合并major compaction 大合并 4.3.1 minor compaction 小合并
在将Store中多个HFile合并为一个HFile，在这个过程中会选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，对于超过了TTL的数据、更新的数据、删除的数据仅仅只是做了标记。并没有进行物理删除，一次Minor Compaction的结果是更少并且更大的StoreFile。这种合并的触发频率很高。
minor compaction触发条件由以下几个参数共同决定：
4.3.2 major compaction 大合并hbase.hstore.compactionThreshold 3 hbase.hstore.compaction.max 10 hbase.hstore.compaction.min.size 134217728 hbase.hstore.compaction.max.size 9223372036854775807
合并Store中所有的HFile为一个HFile，将所有的StoreFile合并成一个StoreFile，这个过程还会清理三类无意义数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。合并频率比较低，默认7天执行一次，并且性能消耗非常大，建议生产关闭(设置为0)，在应用空闲时间手动触发。一般可以是手动控制进行合并，防止出现在业务高峰期。
major compaction触发时间条件
hbase.hregion.majorcompaction 604800000
手动触发
##使用major_compact命令 major_compact tableName5. Hbase表的预分区
当一个table刚被创建的时候，Hbase默认的分配一个region给table。也就是说这个时候，所有的读写请求都会访问到同一个regionServer的同一个region中，这个时候就达不到负载均衡的效果了，集群中的其他regionServer就可能会处于比较空闲的状态。
解决这个问题可以用pre-splitting,在创建table的时候就配置好，生成多个region。
增加数据读写效率负载均衡，防止数据倾斜方便集群容灾调度region优化Map数量，当要对Hbase数据进行分析操作时，可以通过它来优化map数量，即一个region对应一个maptask。 5.2 预分区原理
每一个region维护着startRow与endRowKey，如果加入的数据符合某个region维护的rowKey范围，则该数据交给这个region维护。 5.3 手动指定预分区
方式一：直接创建时使用数组指定
create 'person','info1','info2',SPLITS => ['1000','2000','3000','4000']
方式二：也可以把分区规则创建于文件中
cd /book/install vim prepart.txt
文件内容
aaa bbb ccc ddd
hbase shell中，执行命令
create 'student','info',SPLITS_FILE => '/book/install/prepart.txt'
方式三： HexStringSplit 算法
HexStringSplit会将数据从“00000000”到“FFFFFFFF”之间的数据长度按照n等分之后算出每一段的起始rowkey和结束rowkey，以此作为拆分点。
如：
create 'mytable', 'base_info',' extra_info', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
