HBase的工作机制详解

1. 读数据流程

• 从zookeeper找到meta表的region的位置，然后读取meta表中的数据。而meta中又存储了用户表的region信息
• 根据namespace、表名和rowkey根据meta表中的数据找到对应的region信息
• 找到对应的regionserver，查找对应的region
• 从MemStore找数据，再去BlockCache中找，如果没有，再到StoreFile上读
• 可以把MemStore理解为一级缓存，BlockCache为二级缓存，但注意scan的时候BlockCache意义不大，因为scan是顺序扫描

2. 写数据流程

HBase的数据存储过程是分为几个阶段的。写入的过程与HBase的LSM结构对应。

• 为了提高HBase的写入速度，数据都是先写入**到MemStore（内存）**结构中
• MemStore写到一定程度（默认128M），由后台程序将MemStore的内容flush刷写到HDFS中的StoreFile
• 数据量较大时，会产生很多的StoreFile。这样对高效读取不利，HBase会将这些小的StoreFile合并，一般3-10个文件合并成一个更大的StoreFile

3. MemStore的溢写合并

解释:

• 当MemStore写入的值变多，触发溢写操作（flush），进行文件的溢写，成为一个StoreFile
• 当溢写的文件过多时，会触发文件的合并（Compact）操作，合并有两种方式（major，minor）

条件:

• 一旦MemStore达到128M时，则触发Flush溢出（Region级别）

	hbase.hregion.memstore.flush.size
	134217728
	hbase-default.xml

• MemStore的存活时间超过1小时（默认），触发Flush溢写（RegionServer级别）

<property>
	<name>hbase.regionserver.optionalcacheflushinterval</name>
	<value>3600000</value>
	<source>hbase-default.xml</source>
</property>

• 当MemStore超过阀值的时候，就要flush到HDFS上生成一个StoreFile。因此随着不断写入，HFile的数量将会越来越多，根据前面所述，StoreFile数量过多会降低读性能
• 为了避免对读性能的影响，需要对这些StoreFile进行compact操作，把多个HFile合并成一个HFile
• compact操作需要对HBase的数据进行多次的重新读写，因此这个过程会产生大量的IO。可以看到compact操作的本质就是以IO操作换取后续的读性能的提高

4. Master的工作机制

Master启动(上线)步骤:

• 1.从zookeeper上获取唯一一个代表active master的锁，用来阻止其它master成为master
• 2.一般hbase集群中总是有一个master在提供服务，还有一个以上的‘master’在等待时机抢占它的位置。
• 3.扫描zookeeper上的server父节点，获得当前可用的region server列表
• 4.和每个region server通信，获得当前已分配的region和region server的对应关系
• 5.扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表

Master下线:

5. Region的管理

region的分配:

• 任何时刻，一个region只能分配给一个region server
• Master记录了regionserver的具体分配情况
• Master使用ZooKeeper来跟踪region server状态

region的分裂:

• 当region中的数据逐渐变大之后，达到某一个阈值，会进行裂变
• 一个region等分为两个region，并分配到不同的RegionServer
• 原本的Region会下线，新Split出来的两个Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。

<-- Region最大文件大小为10G -->

	
	hbase.hregion.max.filesize
	10737418240
	false
	hbase-default.xml