Hbase进阶

一、RegionServer 架构

1&＃xff09;StoreFile
保存实际数据的物理文件&＃xff0c;StoreFile以Hfile的形式存储在HDFS上。每个Store会有一个或多个StoreFile&＃xff08;HFile&＃xff09;&＃xff0c;数据在每个StoreFile中都是有序的。
2&＃xff09;MemStore
写缓存&＃xff0c;由于HFile中的数据要求是有序的&＃xff0c;所以数据是先存储在MemStore中&＃xff0c;排好序后&＃xff0c;等到达刷写时机才会刷写到HFile&＃xff0c;每次刷写都会形成一个新的HFile。
3&＃xff09;WAL
由于数据要经MemStore排序后才能刷写到HFile&＃xff0c;但把数据保存在内存中会有很高的概率导致数据丢失&＃xff0c;为了解决这个问题&＃xff0c;数据会先写在一个叫做Write-Ahead logfile的文件中&＃xff0c;然后再写入MemStore中。所以在系统出现故障的时候&＃xff0c;数据可以通过这个日志文件重建。
4&＃xff09;BlockCache
读缓存&＃xff0c;每次查询出的数据会缓存在BlockCache中&＃xff0c;方便下次查询。

二、写流程

写流程&＃xff1a;
1&＃xff09;Client先访问zookeeper&＃xff0c;获取hbase:meta表位于哪个Region Server。
2&＃xff09;访问对应的Region Server&＃xff0c;获取hbase:meta表&＃xff0c;根据读请求的namespace:table/rowkey&＃xff0c;查询出目标数据位于哪个Region Server中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache&＃xff0c;方便下次访问。
3&＃xff09;与目标Region Server进行通讯&＃xff1b;
4&＃xff09;将数据顺序写入&＃xff08;追加&＃xff09;到WAL&＃xff1b;
5&＃xff09;将数据写入对应的MemStore&＃xff0c;数据会在MemStore进行排序&＃xff1b;
6&＃xff09;向客户端发送ack&＃xff1b;
7&＃xff09;等达到MemStore的刷写时机后&＃xff0c;将数据刷写到HFile。

三、MemStore Flush

MemStore刷写时机&＃xff1a;
1.当某个memstore的大小达到了hbase.hregion.memstore.flush.size&＃xff08;默认值128M&＃xff09;&＃xff0c;其所在region的所有memstore都会刷写。
当memstore的大小达到了
hbase.hregion.memstore.flush.size&＃xff08;默认值128M&＃xff09;
hbase.hregion.memstore.block.multiplier&＃xff08;默认值4&＃xff09;
时&＃xff0c;会阻止继续往该memstore写数据。

2.当region server中memstore的总大小达到
java_heapsize
*hbase.regionserver.global.memstore.size&＃xff08;默认值0.4&＃xff09;
*hbase.regionserver.global.memstore.size.lower.limit&＃xff08;默认值0.95&＃xff09;&＃xff0c;
region会按照其所有memstore的大小顺序&＃xff08;由大到小&＃xff09;依次进行刷写。直到region server中所有memstore的总大小减小到上述值以下。
当region server中memstore的总大小达到
java_heapsize
*hbase.regionserver.global.memstore.size&＃xff08;默认值0.4&＃xff09;
时&＃xff0c;会阻止继续往所有的memstore写数据。

3.到达自动刷写的时间&＃xff0c;也会触发memstore flush。自动刷新的时间间隔由该属性进行配置hbase.regionserver.optionalcacheflushinterval&＃xff08;默认1小时&＃xff09;。

4.当WAL文件的数量超过hbase.regionserver.max.logs&＃xff0c;region会按照时间顺序依次进行刷写&＃xff0c;直到WAL文件数量减小到hbase.regionserver.max.logs以下&＃xff08;该属性名已经废弃&＃xff0c;现无需手动设置&＃xff0c;最大值为32&＃xff09;。

四、读流程

1&＃xff09;整体流程

2&＃xff09;Merge细节

五、读流程

1&＃xff09;Client先访问zookeeper&＃xff0c;获取hbase:meta表位于哪个Region Server。
2&＃xff09;访问对应的Region Server&＃xff0c;获取hbase:meta表&＃xff0c;根据读请求的namespace:table/rowkey&＃xff0c;查询出目标数据位于哪个Region Server中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache&＃xff0c;方便下次访问。
3&＃xff09;与目标Region Server进行通讯&＃xff1b;
4&＃xff09;分别在MemStore和Store File&＃xff08;HFile&＃xff09;中查询目标数据&＃xff0c;并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本&＃xff08;time stamp&＃xff09;或者不同的类型&＃xff08;Put/Delete&＃xff09;。
5&＃xff09;将查询到的新的数据块&＃xff08;Block&＃xff0c;HFile数据存储单元&＃xff0c;默认大小为64KB&＃xff09;缓存到Block Cache。
6&＃xff09;将合并后的最终结果返回给客户端。
StoreFile Compaction
由于memstore每次刷写都会生成一个新的HFile&＃xff0c;且同一个字段的不同版本&＃xff08;timestamp&＃xff09;和不同类型&＃xff08;Put/Delete&＃xff09;有可能会分布在不同的HFile中&＃xff0c;因此查询时需要遍历所有的HFile。为了减少HFile的个数&＃xff0c;以及清理掉过期和删除的数据&＃xff0c;会进行StoreFile Compaction。
Compaction分为两种&＃xff0c;分别是Minor Compaction和Major Compaction。Minor Compaction会将临近的若干个较小的HFile合并成一个较大的HFile&＃xff0c;并清理掉部分过期和删除的数据。Major Compaction会将一个Store下的所有的HFile合并成一个大HFile&＃xff0c;并且会清理掉所有过期和删除的数据。

六、Region Split

默认情况下&＃xff0c;每个Table起初只有一个Region&＃xff0c;随着数据的不断写入&＃xff0c;Region会自动进行拆分。刚拆分时&＃xff0c;两个子Region都位于当前的Region Server&＃xff0c;但处于负载均衡的考虑&＃xff0c;HMaster有可能会将某个Region转移给其他的Region Server。
Region Split时机&＃xff1a;
1.当1个region中的某个Store下所有StoreFile的总大小超过hbase.hregion.max.filesize&＃xff0c;该Region就会进行拆分&＃xff08;0.94版本之前&＃xff09;。
2.当1个region中的某个Store下所有StoreFile的总大小超过Min(initialSizeR^3 ,hbase.hregion.max.filesize")&＃xff0c;该Region就会进行拆分。其中initialSize的默认值为2hbase.hregion.memstore.flush.size&＃xff0c;R为当前Region Server中属于该Table的Region个数&＃xff08;0.94版本之后&＃xff09;。
具体的切分策略为&＃xff1a;
第一次split&＃xff1a;1^3 * 256 &＃61; 256MB
第二次split&＃xff1a;2^3 * 256 &＃61; 2048MB
第三次split&＃xff1a;3^3 * 256 &＃61; 6912MB
第四次split&＃xff1a;4^3 * 256 &＃61; 16384MB > 10GB&＃xff0c;因此取较小的值10GB
后面每次split的size都是10GB了。
3.Hbase 2.0引入了新的split策略&＃xff1a;如果当前RegionServer上该表只有一个Region&＃xff0c;按照2 * hbase.hregion.memstore.flush.size分裂&＃xff0c;否则按照hbase.hregion.max.filesize分裂。