和写流程相比，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原理与实际》一书