中的rowkey获取hbase_HBase原理HBase读取流程

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

本节系统地将HBase读取流程的各个环节串起来进行解读。读流程从头到尾可以分为如下4个步骤&＃xff1a;Client-Server读取交互逻辑&＃xff0c;Server端Scan框架体系&＃xff0c;过滤淘汰不符合查询条件的HFile&＃xff0c;从HFile中读取待查找Key。其中Client-Server交互逻辑主要介绍HBase客户端在整个scan请求的过程中是如何与服务器端进行交互的&＃xff0c;理解这点对于使用HBase Scan API进行数据读取非常重要。了解Server端Scan框架体系&＃xff0c;从宏观上介绍HBase RegionServer如何逐步处理一次scan请求。接下来的小节会对scan流程中的核心步骤进行更加深入的分析。

Client-Server读取交互逻辑

Client-Server通用交互逻辑在之前介绍写入流程的时候已经做过解读&＃xff1a;Client首先会从ZooKeeper中获取元数据hbase:meta表所在的RegionServer&＃xff0c;然后根据待读写rowkey发送请求到元数据所在RegionServer&＃xff0c;获取数据所在的目标RegionServer和Region(并将这部分元数据信息缓存到本地)&＃xff0c;最后将请求进行封装发送到目标RegionServer进行处理。

在通用交互逻辑的基础上&＃xff0c;数据读取过程中Client与Server的交互有很多需要关注的点。从API的角度看&＃xff0c;HBase数据读取可以分为get和scan两类&＃xff0c;get请求通常根据给定rowkey查找一行记录&＃xff0c;scan请求通常根据给定的startkey和stopkey查找多行满足条件的记录。但从技术实现的角度来看&＃xff0c;get请求也是一种scan请求(最简单的scan请求&＃xff0c;scan的条数为1)。从这个角度讲&＃xff0c;所有读取操作都可以认为是一次scan操作。

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

•大量数据传输会导致集群网络带宽等系统资源短时间被大量占用&＃xff0c;严重影响集群中其他业务。

•客户端很可能因为内存无法缓存这些数据而导致客户端OOM。

实际上HBase会根据设置条件将一次大的scan操作拆分为多个RPC请求&＃xff0c;每个RPC请求称为一次next请求&＃xff0c;每次只返回规定数量的结果。下面是一段scan的客户端示例代码&＃xff1a;public static void scan(){

HTable table&＃61;... ;

Scan scan&＃61;new Scan();

scan.withStartRow(startRow)

//设置检索起始row

.withStopRow(stopRow)

//设置检索结束row

.setFamilyMap (MapfamilyMap>)

//设置检索的列簇和对应列簇下的列集合

.setTimeRange(minStamp&＃xff0c;maxStamp)

//设置检索TimeRange

.setMaxVersions(maxVersions)

//设置检索的最大版本号

.setFilter(filter)

//设置检索过滤器

scan.setMaxResultSize(10000);

scan.setCacheing(500);

scan.setBatch(100);

ResultScanner rs&＃61;table.getScanner(scan);

for (Result r : rs){

for (KeyValue kv : r.raw()){

......

}

}

}

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

单次RPC请求的数据条数由参数caching设定&＃xff0c;默认为Integer.MAX_VALUE。每次RPC请求获取的数据都会缓存到客户端&＃xff0c;该值如果设置过大&＃xff0c;可能会因为一次获取到的数据量太大导致服务器端/客户端内存OOM&＃xff1b;而如果设置太小会导致一次大scan进行太多次RPC&＃xff0c;网络成本高。

对于很多特殊业务有可能一张表中设置了大量(几万甚至几十万)的列&＃xff0c;这样一行数据的数据量就会非常大&＃xff0c;为了防止返回一行数据但数据量很大的情况&＃xff0c;客户端可以通过setBatch方法设置一次RPC请求的数据列数量。

另外&＃xff0c;客户端还可以通过setMaxResultSize方法设置每次RPC请求返回的数据量大小(不是数据条数)&＃xff0c;默认是2G。

Server端Scan框架体系

从宏观视角来看&＃xff0c;一次scan可能会同时扫描一张表的多个Region&＃xff0c;对于这种扫描&＃xff0c;客户端会根据hbase:meta元数据将扫描的起始区间[startKey, stopKey)进行切分&＃xff0c;切分成多个互相独立的查询子区间&＃xff0c;每个子区间对应一个Region。比如当前表有3个Region&＃xff0c;Region的起始区间分别为&＃xff1a;["a", "c")&＃xff0c;["c", "e")&＃xff0c;["e","g")&＃xff0c;客户端设置scan的扫描区间为["b", "f")。因为扫描区间明显跨越了多个Region&＃xff0c;需要进行切分&＃xff0c;按照Region区间切分后的子区间为["b", "c")&＃xff0c;["c","e")&＃xff0c;["e", "f ")。

HBase中每个Region都是一个独立的存储引擎&＃xff0c;因此客户端可以将每个子区间请求分别发送给对应的Region进行处理。下文会聚焦于单个Region处理scan请求的核心流程。

RegionServer接收到客户端的get/scan请求之后做了两件事情&＃xff1a;首先构建scanneriterator体系&＃xff1b;然后执行next函数获取KeyValue&＃xff0c;并对其进行条件过滤。

1. 构建Scanner Iterator体系

Scanner的核心体系包括三层Scanner&＃xff1a;RegionScanner&＃xff0c;StoreScanner&＃xff0c;MemStoreScanner和StoreFileScanner。三者是层级的关系&＃xff1a;

•一个RegionScanner由多个StoreScanner构成。一张表由多少个列簇组成&＃xff0c;就有多少个StoreScanner&＃xff0c;每个StoreScanner负责对应Store的数据查找。

•一个StoreScanner由MemStoreScanner和StoreFileScanner构成。每个Store的数据由内存中的MemStore和磁盘上的StoreFile文件组成。相对应的&＃xff0c;StoreScanner会为当前该Store中每个HFile构造一个StoreFileScanner&＃xff0c;用于实际执行对应文件的检索。同时&＃xff0c;会为对应MemStore构造一个MemStoreScanner&＃xff0c;用于执行该Store中MemStore的数据检索。

需要注意的是&＃xff0c;RegionScanner以及StoreScanner并不负责实际查找操作&＃xff0c;它们更多地承担组织调度任务&＃xff0c;负责KeyValue最终查找操作的是StoreFileScanner和MemStoreScanner。三层Scanner体系可以用图表示。

Scanner的三层体系

构造好三层Scanner体系之后准备工作并没有完成&＃xff0c;接下来还需要几个非常核心的关键步骤&＃xff0c;如图所示。

Scanner工作流程

1)过滤淘汰部分不满足查询条件的Scanner。StoreScanner为每一个HFile构造一个对应的StoreFileScanner&＃xff0c;需要注意的事实是&＃xff0c;并不是每一个HFile都包含用户想要查找的KeyValue&＃xff0c;相反&＃xff0c;可以通过一些查询条件过滤掉很多肯定不存在待查找KeyValue的HFile。主要过滤策略有&＃xff1a;Time Range过滤、Rowkey Range过滤以及布隆过滤器&＃xff0c;下图中StoreFile3检查未通过而被过滤淘汰。

2)每个Scanner seek到startKey。这个步骤在每个HFile文件中(或MemStore)中seek扫描起始点startKey。如果HFile中没有找到starkKey&＃xff0c;则seek下一个KeyValue地址。HFile中具体的seek过程比较复杂。

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

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

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

1)检查该KeyValue的KeyType是否是Deleted/DeletedColumn/DeleteFamily等&＃xff0c;如果是&＃xff0c;则直接忽略该列所有其他版本&＃xff0c;跳到下列(列簇)。

2)检查该KeyValue的Timestamp是否在用户设定的Timestamp Range范围&＃xff0c;如果不在该范围&＃xff0c;忽略。

3)检查该KeyValue是否满足用户设置的各种filter过滤器&＃xff0c;如果不满足&＃xff0c;忽略。

4)检查该KeyValue是否满足用户查询中设定的版本数&＃xff0c;比如用户只查询最新版本&＃xff0c;则忽略该列的其他版本&＃xff1b;反之&＃xff0c;如果用户查询所有版本&＃xff0c;则还需要查询该cell的其他版本。

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

过滤StoreFile发生在图中第3步&＃xff0c;过滤手段主要有三种&＃xff1a;根据KeyRange过滤&＃xff0c;根据TimeRange过滤&＃xff0c;根据布隆过滤器进行过滤。

1)根据KeyRange过滤&＃xff1a;因为StoreFile中所有KeyValue数据都是有序排列的&＃xff0c;所以如果待检索row范围[ startrow&＃xff0c;stoprow ]与文件起始key范围[ f irstkey&＃xff0c;lastkey ]没有交集&＃xff0c;比如stoprow lastkey&＃xff0c;就可以过滤掉该StoreFile。

2)根据TimeRange过滤&＃xff1a;StoreFile中元数据有一个关于该File的TimeRange属性[ miniTimestamp, maxTimestamp ]&＃xff0c;如果待检索的TimeRange与该文件时间范围没有交集&＃xff0c;就可以过滤掉该StoreFile&＃xff1b;另外&＃xff0c;如果该文件所有数据已经过期&＃xff0c;也可以过滤淘汰。

3)根据布隆过滤器进行过滤&＃xff1a;系统根据待检索的rowkey获取对应的Bloom Block并加载到内存(通常情况下&＃xff0c;热点Bloom Block会常驻内存的)&＃xff0c;再用hash函数对待检索rowkey进行hash&＃xff0c;根据hash后的结果在布隆过滤器数据中进行寻址&＃xff0c;即可确定待检索rowkey是否一定不存在于该HFile。

从HFile中读取待查找Key

在一个HFile文件中seek待查找的Key&＃xff0c;该过程可以分解为4步操作&＃xff0c;如图所示。

HFile读取待查Key流程根据HFile索引树定位目标Block

HRegionServer打开HFile时会将所有HFile的Trailer部分和Load-on-open部分加载到内存&＃xff0c;Load-on-open部分有个非常重要的Block——Root Index Block&＃xff0c;即索引树的根节点。

一个Index Entry&＃xff0c;由BlockKey、Block Offset、BlockDataSize三个字段组成。

BlockKey是整个Block的第一个rowkey&＃xff0c;如Root Index Block中"a", "m", "o","u"都为BlockKey。Block Offset表示该索引节点指向的Block在HFile的偏移量。

HFile索引树索引在数据量不大的时候只有最上面一层&＃xff0c;随着数据量增大开始分裂为多层&＃xff0c;最多三层。

一次查询的索引过程&＃xff0c;基本流程可以表示为&＃xff1a;

1)用户输入rowkey为&＃39;fb&＃39;&＃xff0c;在Root Index Block中通过二分查找定位到&＃39;fb&＃39;在&＃39;a&＃39;和&＃39;m&＃39;之间&＃xff0c;因此需要访问索引&＃39;a&＃39;指向的中间节点。因为Root IndexBlock常驻内存&＃xff0c;所以这个过程很快。

2)将索引&＃39;a&＃39;指向的中间节点索引块加载到内存&＃xff0c;然后通过二分查找定位到fb在index &＃39;d&＃39;和&＃39;h&＃39;之间&＃xff0c;接下来访问索引&＃39;d&＃39;指向的叶子节点。

3)同理&＃xff0c;将索引&＃39;d&＃39;指向的中间节点索引块加载到内存&＃xff0c;通过二分查找定位找到fb在index &＃39;f&＃39;和&＃39;g&＃39;之间&＃xff0c;最后需要访问索引&＃39;f&＃39;指向的Data Block节点。

4)将索引&＃39;f&＃39;指向的Data Block加载到内存&＃xff0c;通过遍历的方式找到对应KeyValue。

上述流程中&＃xff0c;Intermediate Index Block、Leaf Index Block以及Data Block都需要加载到内存&＃xff0c;所以一次查询的IO正常为3次。但是实际上HBase为Block提供了缓存机制&＃xff0c;可以将频繁使用的Block缓存在内存中&＃xff0c;以便进一步加快实际读取过程。

2. BlockCache中检索目标Block

从BlockCache中定位待查Block都非常简单。Block缓存到BlockCache之后会构建一个Map&＃xff0c;Map的Key是BlockKey&＃xff0c;Value是Block在内存中的地址。其中BlockKey由两部分构成——HFile名称以及Block在HFile中的偏移量。BlockKey很显然是全局唯一的。根据BlockKey可以获取该Block在BlockCache中内存位置&＃xff0c;然后直接加载出该Block对象。如果在BlockCache中没有找到待查Block&＃xff0c;就需要在HDFS文件中查找。

3. HDFS文件中检索目标Block

上文说到根据文件索引提供的Block Offset以及Block DataSize这两个元素可以在HDFS上读取到对应的Data Block内容。这个阶段HBase会下发命令给HDFS&＃xff0c;HDFS执行真正的Data Block查找工作&＃xff0c;如图所示。

HDFS文件检索Block

整个流程涉及4个组件&＃xff1a;HBase、NameNode、DataNode以及磁盘。其中HBase模块做的事情上文已经做过了说明&＃xff0c;需要特别说明的是FSDataInputStream这个输入流&＃xff0c;HBase会在加载HFile的时候为每个HFile新建一个从HDFS读取数据的输入流——FSDataInputStream&＃xff0c;之后所有对该HFile的读取操作都会使用这个文件级别的InputStream进行操作。

使用FSDataInputStream读取HFile中的数据块&＃xff0c;命令下发到HDFS&＃xff0c;首先会联系NameNode组件。NameNode组件会做两件事情&＃xff1a;

•找到属于这个HFile的所有HDFSBlock列表&＃xff0c;确认待查找数据在哪个HDFSBlock上。众所周知&＃xff0c;HDFS会将一个给定文件切分为多个大小等于128M的Data Block&＃xff0c;NameNode上会存储数据文件与这些HDFSBlock的对应关系。

•确认定位到的HDFSBlock在哪些DataNode上&＃xff0c;选择一个最优DataNode返回给客户端。HDFS将文件切分成多个HDFSBlock之后&＃xff0c;采取一定的策略按照三副本原则将其分布在集群的不同节点&＃xff0c;实现数据的高可靠存储。HDFSBlock与DataNode的对应关系存储在NameNode。

NameNode告知HBase可以去特定DataNode上访问特定HDFSBlock&＃xff0c;之后&＃xff0c;HBase会再联系对应DataNode。DataNode首先找到指定HDFSBlock&＃xff0c;seek到指定偏移量&＃xff0c;并从磁盘读出指定大小的数据返回。

DataNode读取数据实际上是向磁盘发送读取指令&＃xff0c;磁盘接收到读取指令之后会移动磁头到给定位置&＃xff0c;读取出完整的64K数据返回。

4. 从Block中读取待查找KeyValue

HFile Block由KeyValue(由小到大依次存储)构成&＃xff0c;但这些KeyValue并不是固定长度的&＃xff0c;只能遍历扫描查找。

文章基于《HBase原理与实践》一书