文章目录

  • 1. HBase 读取流程
  • 1.1. Client-Server读取交互逻辑
  • 1.2. Server端Scan框架体系
  • 1.2.1. 构建scanner iterator体系
  • 1.2.2. 执行next函数获取KeyValue并对其进行条件过滤
  • 1.3. 过滤淘汰不符合查询条件的HFile
  • 1.4. 从HFile中读取待查找Key


1. HBase 读取流程

HBase读数据的流程更加复杂。主要基于两个方面的原因：

  • 一是因为HBase一次范围查询可能会涉及多个Region、多块缓存甚至多个数据存储文件；
  • 二是因为HBase中更新操作以及删除操作的实现都很简单，更新操作并没有更新原有数据，而是使用时间戳属性实现了多版本；删除操作也并没有真正删除原有数据，只是插入了一条标记为"deleted"标签的数据，而真正的数据删除发生在系统异步执行Major Compact的时候。
    很显然，这种实现思路大大简化了数据更新、删除流程，但是对于数据读取来说却意味着套上了层层枷锁：读取过程需要根据版本进行过滤，对已经标记删除的数据也要进行过滤。

读流程从头到尾可以分为如下4个步骤：

  1. Client-Server读取交互逻辑；
  2. Server端Scan框架体系；
  3. 过滤淘汰不符合查询条件的HFile；
  4. 从HFile中读取待查找Key。

1.1. Client-Server读取交互逻辑

从API的角度看，HBase数据读取可以分为get和scan两类，get请求通常根据给定rowkey查找一行记录，scan请求通常根据给定的startkey和stopkey查找多行满足条件的记录。但从技术实现的角度来看，get请求也是一种scan请求（最简单的scan请求，scan的条数为1）。从这个角度讲，所有读取操作都可以认为是一次scan操作。

HBase Client端与Server端的scan操作并没有设计为一次RPC请求，这是因为一次大规模的scan操作很有可能就是一次全表扫描，扫描结果非常之大，通过一次RPC将大量扫描结果返回客户端会带来至少两个非常严重的后果：

  • 大量数据传输会导致集群网络带宽等系统资源短时间被大量占用，严重影响集群中其他业务。
  • 客户端很可能因为内存无法缓存这些数据而导致客户端OOM。

实际上HBase会根据设置条件将一次大的scan操作拆分为多个RPC请求，每个RPC请求称为一次next请求，每次只返回规定数量的结果。示例代码

HTable table = ……；
Scan scan = new Scan();
scan.setMaxResultSize(10000);
scan.setCacheing(500);
scan.setBatch(100);
ResultScanner rs = table.getScanner(scan);
for(Result r : rs){
	for(KeyValue kv : r.raw()){
		……
	}
}

for (Result r : rs)语句实际等价于Result r=rs.next()。每执行一次next()操作，客户端先会从本地缓存中检查是否有数据，如果有就直接返回给用户，如果没有就发起一次RPC请求到服务器端获取，获取成功之后缓存到本地。

单次RPC请求的数据条数通过setCacheing()方法设定，默认为Integer.MAX_VALUE。每次RPC请求获取的数据都会缓存到客户端，该值如果设置过大，可能会因为一次获取到的数据量太大导致服务器端/客户端内存OOM；而如果设置太小会导致一次大scan进行太多次RPC，网络成本高。
当表中有非常多的列时，为了防止返回一行数据但数据量很大的情况，客户端可以通过setBatch()方法设置一次RPC请求的数据列数量。
另外，客户端还可以通过setMaxResultSize()方法设置每次RPC请求返回的数据量大小，默认是2G。

1.2. Server端Scan框架体系

从宏观视角来看，一次scan可能会同时扫描一张表的多个Region，对于这种扫描，客户端会根据hbase:meta元数据将扫描的起始区间[startKey, stopKey)进行切分，切分成多个互相独立的查询子区间，每个子区间对应一个Region。
HBase中每个Region都是一个独立的存储引擎，因此客户端可以将每个子区间请求分别发送给对应的Region进行处理。

RegionServer接收到客户端的get/scan请求之后做了两件事情：

  1. 首先构建scanner iterator体系；
  2. 然后执行next函数获取KeyValue，并对其进行条件过滤。

1.2.1. 构建scanner iterator体系

Scanner的核心体系包括三层Scanner：RegionScanner，StoreScanner，MemStoreScanner和StoreFileScanner。三者是层级的关系：

  • 一个RegionScanner由多个StoreScanner构成。一张表由多少个列簇组成，就有多少个StoreScanner，每个StoreScanner负责对应Store的数据查找。
  • 一个StoreScanner由MemStoreScanner和StoreFileScanner构成。每个Store的数据由内存中的MemStore和磁盘上的StoreFile文件组成。
    相对应的，StoreScanner会为当前该Store中每个HFile构造一个StoreFileScanner，用于实际执行对应文件的检索。同时会为对应MemStore构造一个MemStoreScanner，用于执行该Store中MemStore的数据检索。

需要注意的是，RegionScanner以及StoreScanner并不负责实际查找操作，它们更多地承担组织调度任务，负责KeyValue最终查找操作的是StoreFileScanner和MemStoreScanner。

三层Scanner体系如下图所示：

hbase 从kafka获取数据并存储 hbase 读数据_数据

构造好三层Scanner体系之后准备工作并没有完成，接下来还需要几个非常核心的关键步骤：

hbase 从kafka获取数据并存储 hbase 读数据_数据_02

1）过滤淘汰部分不满足查询条件的Scanner。

StoreScanner为每一个HFile构造一个对应的StoreFileScanner，需要注意的事实是，并不是每一个HFile都包含用户想要查找的KeyValue，相反，可以通过一些查询条件过滤掉很多肯定不存在待查找KeyValue的HFile。主要过滤策略有：Rowkey Range过滤、Time Range过滤以及布隆过滤器。详见1.3章节。

2）每个Scanner seek到startKey。

这个步骤在每个HFile文件中（或MemStore）中seek扫描起始点startKey。如果HFile中没有找到starkKey，则seek下一个KeyValue地址。详见1.4章节。

3）KeyValueScanner合并构建最小堆。

将该Store中的所有StoreFileScanner和MemStoreScanner合并形成一个heap（最小堆），所谓heap实际上是一个优先级队列。在队列中，按照Scanner排序规则将Scanner seek得到的KeyValue由小到大进行排序。最小堆管理Scanner可以保证取出来的KeyValue都是最小的，这样依次不断地pop就可以由小到大获取目标KeyValue集合，保证有序性。

1.2.2. 执行next函数获取KeyValue并对其进行条件过滤

经过Scanner体系的构建，KeyValue此时已经可以由小到大依次经过KeyValueScanner获得，但这些KeyValue是否满足用户设定的TimeRange条件、版本号条件以及Filter条件还需要进一步的检查。检查规则如下：

  1. 检查该KeyValue的KeyType是否是Deleted/DeletedColumn/DeleteFamily等，如果是，则直接忽略该列所有其他版本，跳到下列（列簇）。
  2. 检查该KeyValue的Timestamp是否在用户设定的Timestamp Range范围，如果不在该范围，忽略。
  3. 检查该KeyValue是否满足用户设置的各种filter过滤器，如果不满足，忽略。
  4. 检查该KeyValue是否满足用户查询中设定的版本数，比如用户只查询最新版本，则忽略该列的其他版本；反之，如果用户查询所有版本，则还需要查询该cell的其他版本。

1.3. 过滤淘汰不符合查询条件的HFile

过滤手段主要有三种：根据Rowkey Range过滤，根据Time Range过滤，根据布隆过滤器进行过滤。

  • 根据Rowkey Range过滤：因为StoreFile中所有KeyValue数据都是有序排列的，所以如果待检索row范围[ startrow，stoprow ]与文件起始key范围[ firstkey，lastkey ]没有交集，就可以过滤掉该StoreFile。
  • 根据Time Range过滤：StoreFile中元数据有一个关于该HFile的TimeRange属性[ miniTimestamp, maxTimestamp ]，如果待检索的TimeRange与该文件时间范围没有交集，就可以过滤掉该StoreFile；另外，如果该文件所有数据已经过期，也可以过滤淘汰。
  • 根据布隆过滤器进行过滤：系统根据待检索的rowkey获取对应的Bloom Block并加载到内存（通常情况下，热点Bloom Block会常驻内存的），再用hash函数对待检索rowkey进行hash，根据hash后的结果在布隆过滤器数据中进行寻址，即可确定待检索rowkey是否一定不存在于该HFile。

1.4. 从HFile中读取待查找Key

在一个HFile文件中seek待查找的Key，该过程可以分解为4步操作：

  1. 根据HFile索引树定位目标Block；
  2. BlockCache中检索目标Block；
  3. HDFS文件中检索目标Block；
  4. 从Block中读取待查找KeyValue