HBase原理--HBase读取流程

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

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

Client-Server读取交互逻辑

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

在通用交互逻辑的基础上，数据读取过程当中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请求，每次只返回规定数量的结果。下面是一段scan的客户端示例代码：

public static void scan(){
    HTable table=... ;
    Scan scan=new Scan();
    scan.withStartRow(startRow)
        //设置检索起始row
        .withStopRow(stopRow)
        //设置检索结束row
        .setFamilyMap (Map<byte[]，Set<byte[]>familyMap>)
        //设置检索的列簇和对应列簇下的列集合
        .setTimeRange(minStamp，maxStamp)
        //设置检索TimeRange
        .setMaxVersions(maxVersions)
        //设置检索的最大版本号
        .setFilter(filter)
        //设置检索过滤器
    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请求的数据条数由参数caching设定，默认为Integer.MAX_VALUE。每次RPC请求获取的数据都会缓存到客户端，该值若是设置过大，可能会由于一次获取到的数据量太大致使服务器端/客户端内存OOM；而若是设置过小会致使一次大scan进行太屡次RPC，网络成本高。

对于不少特殊业务有可能一张表中设置了大量（几万甚至几十万）的列，这样一行数据的数据量就会很是大，为了防止返回一行数据但数据量很大的状况，客户端能够经过setBatch方法设置一次RPC请求的数据列数量。

另外，客户端还能够经过setMaxResultSize方法设置每次RPC请求返回的数据量大小（不是数据条数），默认是2G。

Server端Scan框架体系

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

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

RegionServer接收到客户端的get/scan请求以后作了两件事情：首先构建scanneriterator体系；而后执行next函数获取KeyValue，并对其进行条件过滤。

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体系能够用图表示。

Scanner的三层体系

构造好三层Scanner体系以后准备工做并无完成，接下来还须要几个很是核心的关键步骤，如图所示。

Scanner工做流程

1）过滤淘汰部分不知足查询条件的Scanner。StoreScanner为每个HFile构造一个对应的StoreFileScanner，须要注意的事实是，并非每个HFile都包含用户想要查找的KeyValue，相反，能够经过一些查询条件过滤掉不少确定不存在待查找KeyValue的HFile。主要过滤策略有：Time Range过滤、Rowkey Range过滤以及布隆过滤器，下图中StoreFile3检查未经过而被过滤淘汰。

2）每一个Scanner seek到startKey。这个步骤在每一个HFile文件中（或MemStore）中seek扫描起始点startKey。若是HFile中没有找到starkKey，则seek下一个KeyValue地址。HFile中具体的seek过程比较复杂。

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

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的其余版本。

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

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

1）根据KeyRange过滤：由于StoreFile中全部KeyValue数据都是有序排列的，因此若是待检索row范围[ startrow，stoprow ]与文件起始key范围[ f irstkey，lastkey ]没有交集，好比stoprow < f irstkey或者startrow > lastkey，就能够过滤掉该StoreFile。

2）根据TimeRange过滤：StoreFile中元数据有一个关于该File的TimeRange属性[ miniTimestamp, maxTimestamp ]，若是待检索的TimeRange与该文件时间范围没有交集，就能够过滤掉该StoreFile；另外，若是该文件全部数据已通过期，也能够过滤淘汰。

3）根据布隆过滤器进行过滤：系统根据待检索的rowkey获取对应的Bloom Block并加载到内存（一般状况下，热点Bloom Block会常驻内存的），再用hash函数对待检索rowkey进行hash，根据hash后的结果在布隆过滤器数据中进行寻址，便可肯定待检索rowkey是否必定不存在于该HFile。

从HFile中读取待查找Key

在一个HFile文件中seek待查找的Key，该过程能够分解为4步操做，如图所示。

HFile读取待查Key流程

1. 根据HFile索引树定位目标Block

HRegionServer打开HFile时会将全部HFile的Trailer部分和Load-on-open部分加载到内存，Load-on-open部分有个很是重要的Block——Root Index Block，即索引树的根节点。

一个Index Entry，由BlockKey、Block Offset、BlockDataSize三个字段组成。

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

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

一次查询的索引过程，基本流程能够表示为：

1）用户输入rowkey为'fb'，在Root Index Block中经过二分查找定位到'fb'在'a'和'm'之间，所以须要访问索引'a'指向的中间节点。由于Root IndexBlock常驻内存，因此这个过程很快。

2）将索引'a'指向的中间节点索引块加载到内存，而后经过二分查找定位到fb在index 'd'和'h'之间，接下来访问索引'd'指向的叶子节点。

3）同理，将索引'd'指向的中间节点索引块加载到内存，经过二分查找定位找到fb在index 'f'和'g'之间，最后须要访问索引'f'指向的Data Block节点。

4）将索引'f'指向的Data Block加载到内存，经过遍历的方式找到对应KeyValue。

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

2. BlockCache中检索目标Block

从BlockCache中定位待查Block都很是简单。Block缓存到BlockCache以后会构建一个Map，Map的Key是BlockKey，Value是Block在内存中的地址。其中BlockKey由两部分构成——HFile名称以及Block在HFile中的偏移量。BlockKey很显然是全局惟一的。根据BlockKey能够获取该Block在BlockCache中内存位置，而后直接加载出该Block对象。若是在BlockCache中没有找到待查Block，就须要在HDFS文件中查找。

3. HDFS文件中检索目标Block

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

HDFS文件检索Block

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

使用FSDataInputStream读取HFile中的数据块，命令下发到HDFS，首先会联系NameNode组件。NameNode组件会作两件事情：

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

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

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

DataNode读取数据其实是向磁盘发送读取指令，磁盘接收到读取指令以后会移动磁头到给定位置，读取出完整的64K数据返回。

4. 从Block中读取待查找KeyValue
HFile Block由KeyValue（由小到大依次存储）构成，但这些KeyValue并非固定长度的，只能遍历扫描查找。

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