Hbase笔记（三）之---原理加强篇（Hbase读写流程、flush、合并拆分、RowKey设计等）

6、Hbase写入数据流程：

前提：

①Hbase中的表包括：行、列族、列和值；其中，key是：行、列族和列，value是：值；

②随着Hbase表中的数据量增加，RegionServer会将Region会分裂成不同的Region，Region在不同的RegionServer中，一个Region对应一个RegionServer；

③每个Region中，存在一个或多个列族Store，每个Store中有一个MemStore实例。数据写入WAL之后就会被放入MemStore；

④MemStore是内存的存储对象，只有当MemStore满了的时候才会将数据刷写（flush）到HFile中；

⑤WAL：暂存日志，不区分Store，是被设计来解决宕机之后的操作恢复问题；

数据到达Region的时候是先写入WAL，然后再被加载到Memstore的；就算Region的机器宕掉了，由于WAL的数据是存储在HDFS上的，所以数据并不会丢失；WAL默认开启；

⑥每个RegionServer中，存在一个CacheStore（基于缓存），用于提高查询效率。

一对Key-Value持久化到HDFS的简易过程：

写入数据流程：

①客户端在put操作之时，会首先找到ZooKeeper，利用ZooKeeper查询rowkey的位置（哪个RegionServer的哪个Region中）；

②通过查找ZooKeeper的root_region_server节点查询ROOT表在哪台RegionServer上；访问ROOT表，查看需要的数据记录在哪个meta表（meta：也叫元数据块。Meta块是可选的，meta块只有在文件关闭的时候才会写入。meta块存储了该HFile文件的元数据信息、表的数量、region的个数、region的起始key和结束key等，在v2之前布隆过滤器（Bloom Filter）的信息直接放在Meta里面存储，v2之后分离出来单独存储），通过这个表就可以查询出你要存取的rowkey属于哪个Region的范围里面；

③ZooKeeper会将查询到的meta表返回给客户端；如果没有查询到meta表，HMaster会自动分配rowkey；

④客户端获取这些信息后，就可以直连拥有要存取rowkey的RegionServer节点，请求节点下载meta表数据；客户端下载完成后，对meta表中的数据进行解析和缓存；

⑤客户端会把meta信息缓存起来，下次操作就不需要进行以上加载hbase:meta的步骤了；

⑥客户端向节点上的Region发送put请求进行数据写入；数据被发出之后第一时间被写入WAL，由于WAL是基于HDFS来实现的，所以也可以说现在单元格就已经被持久化了，但是WAL只是一个暂存的日志，它是不区分Store的。这些数据是不能被直接读取和使用的；

⑦数据随后会立即被放入Memstore中进行整理。Memstore会负责按照LSM树的结构来存放数据；这个过程就像我们在打牌的时候，抓牌之后在手上对牌进行整理的过程；

⑧当数据量超过某个阈值（默认128M），会被MemStore刷写（flush）到HDFS系统中的HFlie文件，文件存储在硬盘上，可以说数据被持久化磁盘上了，就算宕机、断电也不会丢失。（一个列族对应HDFS中的一个文件夹）

7、flush（刷写）的时机：

①手动强制flush；

②单个memStore达到阈值时（默认128M）；

③单个RegionSever的memStore总内存达到60%时；

④日志记录的条数达到100万条。

8、布隆过滤器：

（1）概念：布隆过滤器是一种算法，是在hfile文件上占了很小的一块内存的字节数组，利用这组字节数组判断数据存在与否（利用极小的内存空间换取运算效率）；

布隆过滤器可以实现利用很小的空间和运算代价，实现查找海量数据的存在与否的记录（是否存在于某一个或某几个hfile文件中）。例如：爬虫中可以实现快速判断一个url是否爬取过的记录，或者在hbase中，RegionServer可以利用布隆过滤器快速判断一个RowKey是否存在于一个hfile文件中。

（2）核心思想：

①先将海量数据中的每一个数据，用一个特定的算法映射成若干个特定角标的位置上的1，记录在数组中；

②然后将要进行判断的数据，永通要哪个的算法映射出特定位置，然后在数组中查看是否能够全部匹配：如果能够匹配说明有极大概率数据存在，否则数据不存在。（为什么不是100%：有可能发生hash碰撞，可能其他的数据算出来映射的角标位置与要查询的相同，但是概率极低）

9、Hbase读数据流程：

（1）获取meta表：客户端在进行读取数据时，会先找到ZooKeeper集群，获取连接对象；ZooKeeper返回meta元数据表的位置；

（2）下载meta表：客户端请求meta表所在的机器下载meta表，并把meta表中的信息缓存到本地，方便下次查询；

（3）请求读取数据：客户端根据元信息进行解析表，获取RowKey所在的Region的位置，并请求Region所在的RegionServer读取数据；

（4）从Store中的MemStore内存中获取数据：

①如果数据存在于内存中，会将数据先存储到CashStore缓存中，方便下次查询，再由CashStore缓存返回数据给客户端；

②如果数据不在内存中，会到缓存中查找数据，如果在缓存中，会将数据返回给客户端；

（5）从HDFS中获取数据：

①如果数据不在内存中，也不在缓存中，会到HDFS中查找；（HDFS中的目录结构：NameSpace/表/RegionServer/列族/）

②列祖中存放着大量hfile文件，需要读取的数据在其中的一个或几个hflie文件中（可能存在多次对同一数据进行put操作但没有合并的情况，数据就有可能同时在几个文件中），需要从大量的文件中确定哪一个（或哪几个）文件中存储着需要读取的数据；

③遍历所有的文件中的所有数据占用大量资源而且速度也会很慢，不便于效率的提升。

④可以使用布隆过滤器来定位要查找的数据所在的文件；

（6）布隆过滤器：

①利用文件上一块很下的存储空间，经过某种算法来快速地判断文件中绝对不存在所要查询的数据或者极有可能存在所要查询的数据；

②布隆过滤器实际上是一组字节数组，每put一次数据，RowKey经过hash算法得到一组hashcode值，作为角标索引，被放到字节数组中，查询的时候查询这个角标索引判断所要查找的数据是否存储在这个文件中。

（7）hfile文件中查找数据：

①通过布隆过滤器查找到hfile文件后，如果数据有序排列，可以利用二分查找进行数据检索，但是也比较慢；

② 可以通奴工index_block查找数据位置，index_block中记录着每条数据的Key的索引。、

（8）返回数据：数据查询完成，存储到CacheStore缓存中，再由缓存返回给客户端，数据的一次读取完成。

10、合并和拆分：

拆分：

（1）拆分的原因：

①在进行创建表的时候默认一个Region（也可以进行预分Region），当数据量增多，所有的数据都会在同一个Region中，即所有的数据都在同一个RegionServer上；

②当进行大量去屑请求时，可能会存在插入/查询热点问题，因此需要进行Region的拆分，使负载均衡。

（2）拆分方式：

（3）大小拆分：

①计算拆分时机：

对于新文件：第一次：256M；第二次：2G；第三次：6.75G，之后Region到达10G时进行拆分一次。

②存在的问题：

③问题解决：

合并：

（1）前提：

①当进行大量的数据更新、删除操作（一般不会有大量的删除操作），或者数据到达过期时间、版本数量时，需要对数据、文件、region等进行合并，减少资源的浪费；

②进行合并之后，hflie文件减少，数据量减少，region管理的行数减少，如果还用多台机器同时管理多个Region可能造成资源的浪费，此时需要进行不同机器之间的Region合并操作；

（2）合并过程：

①在进行合并的过程中，不同机器上的Region需要进行合并，Region中的文件夹需要合并，文件夹中的hflie文件也需要合并，合并过程会进行大量的读写操作，极大程度上占用资源；

②Region的合并称之为大合并，一般情况下是关闭的，尤其是业务高峰期；平时只会进行hfile文件之间的小合并；只有在业务低峰期（节假日）进行Region之间的大合并；

③Hbase中一般存放标签性质的数据报表，当达到过期时间时需要进行Region之间的合并操作。

11、RowKey

hbase中使用RowKey行键查询速度最快，适合以RowKey为查询纬度的单维度查询。

（1）使用RowKey速度最快的原因：

①对RowKey进行了排序（按ASCII码表进行排序）；

②hfile文件中存在布隆过滤器，提升了查询文件的速度；

③查询数据时使用了index-block块；

④数据可能以前查找过，存在于内存或者缓存中，可以直接获取进行查询。

（2）存在的问题：

hbase中数据查询速度的快慢取决于RowKey行键的设计，设计时候要考虑下面几点：

①数据特点；

②查询纬度和查询频率（热点问题）；

③数据的插入特点。

（3）RowKey主键的设计：

①在设计行键的时候，考虑到数据的查询纬度和查询频次，需要避免查询热点问题，避免在进行查询的时候所有的请求都到达同一个Region、到达同一台RegionServer；

②可以选择将要设计成主键的key打散（key是已经排序好的），如：key前面拼接上随机数，或者拼接上时间戳，或者进行反转等。

③同时还要考虑到，在进行put数据的时候，可能同时插入大量的相同属性的数据，相同数据到达同一机器，可能造成插入热点问题，需要针对数据特点进行设计RowKey主键。

注：因为业务上的差异性，在设计主键时候，需要以业务场景为依据，围绕主键长度固定、主键设计不宜太长、查询/插入热点问题和查询纬度问题进行适时地设计。

12、二级索引