大数据之HBase的读写流程

大数据之HBase的读写流程

写流程

图示

过程

1. HBase使用memstore和storefile存储对表的更新。数据在更新时首先写入hlog和memstore，memstore中的数据是排序的，当memstore累计到一定的阀值时，就会创建一个新的memstore，并将老的memstore添加到flush队列，由单独的线程flush到磁盘上，成为一个filestore。与此同时，系统会在zookeeper中记录一个checkpoint，表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致memstore中的数据丢失，此时使用hlog来恢复checkpoint之后的数据。
2. Storefile是只读的，一旦创建之后就不可修改。因此hbase的更新就是不断追加的操作。当一个store的storefile达到一定的阀值后，就会进行一次合并操作，将对同一个key的修改合并到一起，同时进行版本合并和数据删除，形成一个大的storefile。当storefile的大小达到一定的阀值后，又会对storefile进行切分操作，等分为两个storefile。
3. Hbase中只有增添数据，所有的更新和删除操作都是在后续的合并中进行的，使得用户的写操作只要进入内存就可以立刻返回，实现了hbase的高速存储。
(1) Client通过Zookeeper的调度，向RegionServer发出写数据请求，在Region中写数据。
(2) 数据被写入Region的MemStore，直到MemStore达到预设阈值。
(3) MemStore中的数据被Flush成一个StoreFile。
(4) 随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。
(5) StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。
(6) 单个StoreFile大小超过一定阈值后，触发Split操作，把当前Region Split成2个新的Region。父Region会下线，新Split出的2个子Region会被HMaster分配到相应的RegionServer上，使得原先1个Region的压力得以分流到2个Region上。

读流程（HBase1.0之前）

图示

过程

Hbase的所有region元数据被存储在.META表中，随着region的增多，.META表中的数据也会增大，并分裂成多个新的region。为了定位.META表中各个region的位置，把.META表中的所有region的元数据保存在-ROOT-表中(1.0之后转移到zk的master目录)，最后由zookeeper记录-ROOT-表的位置信息。所有的客户端访问数据之前，需要首先访问zookeeper获取-ROOT-的位置，然后访问-ROOT-表获得.META表的位置，最后根据.META表中的信息确定用户数据存放的位置。
-ROOT-表永远不会被分割，它只有一个region，这样可以保证最多只需要三次跳转就可以定位任意一个region。为了加快访问速度，.META表的所有region全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据，则询问相关.META表的region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的.META表在哪里。最后，如果前面的信息全部失效，则通过zookeeper重新定位region的信息。所以如果客户端上的缓存全部失效，则需要进行6次网络来定位，才能定位到正确的region。
client-->Zookeeper-->-ROOT-表（master）-->.META.表-->RegionServer-->Region-->client
(1) Client访问Zookeeper，查找-ROOT-表，获取.META.表信息。
(2) 从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer。
(3) 通过RegionServer获取需要查找的数据。
(4) Regionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。

存储模型

图示

详解

1. 数据的存储是每个Region所承担的工作了
	1) 我们知道一个Region代表的是一张 Hbase表中特定Rowkey范围内的数据，
	2) 而Hbase是面向列存储的数据库，所以在一个Region中，有多个文件来存储这些列。
	3) Hbase中数据列是由列簇来组织的，所以每一个列簇都会有对应的一个数据结构，
		3.1) Hbase将列簇的存储数据结构抽象为Store，一个Store代表一个列簇。
总结：所以在这里也可以看出为什么在我们查询的时候要尽量减少不需要的列，而经常一起查询的列要组织到一个列簇里：因为要需要查询的列簇越多，意味着要扫描越多的Store文件，这就需要越多的时间
2. Store中存储数据的方式:Hbase采用的是LSM树的结构，这种结构的关键是:
	1) 每一次的插入操作都会先进入MemStore（内存缓冲区），
	2) 当 MemStore达到上限的时候，Hbase会将内存中的数据输出为有序的StoreFile文件数据（根据Rowkey、版本、列名排序，这里已经和列簇无关了因为Store里都属于同一个列簇）。
	3) 这样会在Store中形成很多个小的StoreFile，当这些小的File数量达到一个阀值的时候，Hbase会用一个线程来把这些小File合并成一个大的File。这样，Hbase就把效率低下的文件中的插入、移动操作转变成了单纯的文件输出、 合并操作。
	由上可知，在Hbase底层的Store数据结构中，
	1） 每个StoreFile内的数据是有序的，
	2） 但是StoreFile之间不一定是有序的，
	3） Store只 需要管理StoreFile的索引就可以了。这里也可以看出为什么指定版本和Rowkey可以加强查询的效率，因为指定版本和Rowkey的查询可以利用 StoreFile的索引跳过一些肯定不包含目标数据的数据。