Hbase----读写流程分析

RegionServer中的核心组件主要是为HBase数据读写而设计。本文将会把这些核心组件串联起来进行介绍。首先介绍数据如何写入MemStore并flush形成HFile文件，然后介绍HBase是如何从HFile、MemStore中检索出待查的数据。读写流程是HBase内核最重要、最复杂的内容，这里只介绍核心主干流程。

1、HBase写入流程

HBase采用LSM树架构，天生适用于写多读少的应用场景。在真实生产线环境中，也正是因为HBase集群出色的写入能力，才能支持当下很多数据激增的业务。需要说明的是，HBase服务端并没有提供update、delete接口，HBase中对数据的更新、删除操作在服务器端也认为是写入操作，不同的是，更新操作会写入一个最新版本数据，删除操作会写入一条标记为deleted的KV数据。所以HBase中更新、删除操作的流程与写入流程完全一致。当然，HBase数据写入的整个流程随着版本的迭代在不断优化，但总体流程变化不大。

1.1　写入流程的三个阶段

HBase写入流程如图所示。

从整体架构的视角来看，写入流程可以概括为三个阶段。

1）客户端处理阶段：客户端将用户的写入请求进行预处理，并根据集群元数据定位写入数据所在的RegionServer，将请求发送给对应的RegionServer。

2）Region写入阶段：RegionServer接收到写入请求之后将数据解析出来，首先写入WAL，再写入对应Region列簇MemStore。

3）MemStore Flush阶段：当Region中MemStore容量超过一定阈值，系统会异步执行flush操作，将内存中的数据写入文件，形成HFile。

用户写入请求在完成Region MemStore的写入之后就会返回成功。MemStore Flush是一个异步执行的过程。

 

（1）.客户端处理阶段

HBase客户端处理写入请求的核心流程基本上可以概括为三步。

步骤1：用户提交put请求后，HBase客户端会将写入的数据添加到本地缓冲区中，符合一定条件就会通过AsyncProcess异步批量提交。HBase默认设置autoflush=true，表示put请求直接会提交给服务器进行处理；用户可以设置autoflush=false，这样，put请求会首先放到本地缓冲区，等到本地缓冲区大小超过一定阈值（默认为2M，可以通过配置文件配置）之后才会提交。很显然，后者使用批量提交请求，可以极大地提升写入吞吐量，但是因为没有保护机制，如果客户端崩溃，会导致部分已经提交的数据丢失。

步骤2：在提交之前，HBase会在元数据表hbase：meta中根据rowkey找到它们归属的RegionServer，这个定位的过程是通过HConnection的locateRegion方法完成的。如果是批量请求，还会把这些rowkey按照HRegionLocation分组，不同分组的请求意味着发送到不同的RegionServer，因此每个分组对应一次RPC请求。

客户端根据写入的表以及rowkey在元数据缓存中查找，如果能够查找出该rowkey所在的RegionServer以及Region，就可以直接发送写入请求（携带Region信息）到目标RegionServer。

·如果客户端缓存中没有查到对应的rowkey信息，需要首先到ZooKeeper上/hbase-root/meta-region-server节点查找HBase元数据表所在的RegionServer。向hbase：meta所在的RegionServer发送查询请求，在元数据表中查找rowkey所在的RegionServer以及Region信息。客户端接收到返回结果之后会将结果缓存到本地，以备下次使用。

·客户端根据rowkey相关元数据信息将写入请求发送给目标RegionServer，RegionServer接收到请求之后会解析出具体的Region信息，查到对应的Region对象，并将数据写入目标Region的MemStore中。

步骤3：HBase会为每个HRegionLocation构造一个远程RPC请求MultiServerCallable，并通过rpcCallerFactory.newCaller（）执行调用。将请求经过Protobuf序列化后发送给对应的RegionServer。

(2).Region写入阶段

服务器端RegionServer接收到客户端的写入请求后，首先会反序列化为put对象，然后执行各种检查操作，比如检查Region是否是只读、MemStore大小是否超过blockingMemstoreSize等。检查完成之后，执行一系列核心操作,见下图。

1）Acquire locks：HBase中使用行锁保证对同一行数据的更新都是互斥操作，用以保证更新的原子性，要么更新成功，要么更新失败。

2）Update LATEST_TIMESTAMP timestamps：更新所有待写入（更新）KeyValue的时间戳为当前系统时间。

3）Build WAL edit：HBase使用WAL机制保证数据可靠性，即首先写日志再写缓存，即使发生宕机，也可以通过恢复HLog还原出原始数据。该步骤就是在内存中构建WALEdit对象，为了保证Region级别事务的写入原子性，一次写入操作中所有KeyValue会构建成一条WALEdit记录。

4）Append WALEdit To WAL：将3）中构造在内存中的WALEdit记录顺序写入HLog中，此时不需要执行sync操作。当前版本的HBase使用了disruptor实现了高效的生产者消费者队列，来实现WAL的追加写入操作。

5）Write back to MemStore：写入WAL之后再将数据写入MemStore。

6）Release row locks：释放行锁。

7）Sync wal：HLog真正sync到HDFS，在释放行锁之后执行sync操作是为了尽量减少持锁时间，提升写性能。如果sync失败，执行回滚操作将MemStore中已经写入的数据移除。

8）结束写事务：此时该线程的更新操作才会对其他读请求可见，更新才实际生效。

branch-1分支的写入流程设计为：先在第6步释放行锁，再在第7步Sync WAL，最后在第8步打开mvcc让其他事务可以看到最新结果。正是这样的设计，导致了之前提到的“CAS接口是Region级别串行的，吞吐受限”问题。这个问题已经在branch-2中解决。

（3）.MemStore Flush阶段

随着数据的不断写入，MemStore中存储的数据会越来越多，系统为了将使用的内存保持在一个合理的水平，会将MemStore中的数据写入文件形成HFile。flush阶段是HBase的非常核心的阶段，理论上需要重点关注三个问题：

·MemStore Flush的触发时机。即在哪些情况下HBase会触发flush操作。

·MemStore Flush的整体流程。

·HFile的构建流程。HFile构建是MemStore Flush整体流程中最重要的一个部分，这部分内容会涉及HFile文件格式的构建、布隆过滤器的构建、HFile索引的构建以及相关元数据的构建等。

1.2　Region写入流程

数据写入Region的流程可以抽象为两步：追加写入HLog，随机写入MemStore。

1.2.1 追加写入HLog

HBase中HLog的文件格式、生命周期已经在之前做了介绍。HLog保证成功写入MemStore中的数据不会因为进程异常退出或者机器宕机而丢失，但实际上并不完全如此，HBase定义了多个HLog持久化等级，使得用户在数据高可靠和写入性能之间进行权衡。

（1）HLog持久化等级

HBase可以通过设置HLog的持久化等级决定是否开启HLog机制以及HLog的落盘方式。HLog的持久化等级分为如下五个等级。

·SKIP_WAL：只写缓存，不写HLog日志。因为只写内存，因此这种方式可以极大地提升写入性能，但是数据有丢失的风险。在实际应用过程中并不建议设置此等级，除非确认不要求数据的可靠性。

·ASYNC_WAL：异步将数据写入HLog日志中。

·SYNC_WAL：同步将数据写入日志文件中，需要注意的是，数据只是被写入文件系统中，并没有真正落盘。

·FSYNC_WAL：同步将数据写入日志文件并强制落盘。这是最严格的日志写入等级，可以保证数据不会丢失，但是性能相对比较差。

·USER_DEFAULT：如果用户没有指定持久化等级，默认HBase使用SYNC_WAL等级持久化数据。

用户可以通过客户端设置HLog持久化等级，代码如下：

put.setDurability(Durability.SYNC_WAL );

（2）HLog写入模型

在HBase的演进过程中，HLog的写入模型几经改进，写入吞吐量得到极大提升。之前的版本中，HLog写入都需要经过三个阶段：首先将数据写入本地缓存，然后将本地缓存写入文件系统，最后执行sync操作同步到磁盘。

很显然，三个阶段是可以流水线工作的，基于这样的设想，写入模型自然就想到“生产者-消费者”队列实现。然而之前版本中，生产者之间、消费者之间以及生产者与消费者之间的线程同步都是由HBase系统实现，使用了大量的锁，在写入并发量非常大的情况下会频繁出现恶性抢占锁的问题，写入性能较差。

当前版本中，HBase使用LMAX Disruptor框架实现了无锁有界队列操作。基于Disruptor的HLog写入模型如图所示。

图中最左侧部分是Region处理HLog写入的两个前后操作：append和sync。当调用append后，WALEdit和HLogKey会被封装成FSWALEntry类，进而再封装成RingBufferTruck类放入Disruptor无锁有界队列中。当调用sync后，会生成一个SyncFuture，再封装成RingBufferTruck类放入同一个队列中，然后工作线程会被阻塞，等待notify（）来唤醒。

图中最右侧部分是消费者线程，在Disruptor框架中有且仅有一个消费者线程工作。这个框架会从Disruptor队列中依次取出RingBufferTruck对象，然后根据如下选项来操作：

·如果RingBufferTruck对象中封装的是FSWALEntry，就会执行文件append操作，将记录追加写入HDFS文件中。需要注意的是，此时数据有可能并没有实际落盘，而只是写入到文件缓存。

·如果RingBufferTruck对象是SyncFuture，会调用线程池的线程异步地批量刷盘，刷盘成功之后唤醒工作线程完成HLog的sync操作。

1.2.2 随机写入MemStore

KeyValue写入Region分为两步：首先追加写入HLog，再写入MemStore。MemStore使用数据结构ConcurrentSkipListMap来实际存储KeyValue，优点是能够非常友好地支持大规模并发写入，同时跳跃表本身是有序存储的，这有利于数据有序落盘，并且有利于提升MemStore中的KeyValue查找性能。

KeyValue写入MemStore并不会每次都随机在堆上创建一个内存对象，然后再放到ConcurrentSkipListMap中，这会带来非常严重的内存碎片，进而可能频繁触发Full GC。HBase使用MemStore-Local Allocation Buffer（MSLAB）机制预先申请一个大的（2M）的Chunk内存，写入的KeyValue会进行一次封装，顺序拷贝这个Chunk中，这样，MemStore中的数据从内存flush到硬盘的时候，JVM内存留下来的就不再是小的无法使用的内存碎片，而是大的可用的内存片段。

基于这样的设计思路，MemStore的写入流程可以表述为以下3步。

1）检查当前可用的Chunk是否写满，如果写满，重新申请一个2M的Chunk。

2）将当前KeyValue在内存中重新构建，在可用Chunk的指定offset处申请内存创建一个新的KeyValue对象。

3）将新创建的KeyValue对象写入ConcurrentSkipListMap中。

1.3　MemStore Flush

1.3.1 触发条件

HBase会在以下几种情况下触发flush操作。

·MemStore级别限制：当Region中任意一个MemStore的大小达到了上限（hbase.hregion.memstore.flush.size，默认128MB），会触发MemStore刷新。

·Region级别限制：当Region中所有MemStore的大小总和达到了上限（hbase.hregion.memstore.block.multiplier*hbase.hregion.memstore.flush.size），会触发MemStore刷新。

·RegionServer级别限制：当RegionServer中MemStore的大小总和超过低水位阈值hbase.regionserver.global.memstore.size.lower.limit*hbase.regionserver.global.memstore.

·size，RegionServer开始强制执行flush，先flush MemStore最大的Region，再flush次大的，依次执行。如果此时写入吞吐量依然很高，导致总MemStore大小超过高水位阈值hbase.regionserver.global.memstore.size，RegionServer会阻塞更新并强制执行flush，直至总MemStore大小下降到低水位阈值。

·当一个RegionServer中HLog数量达到上限（可通过参数hbase.regionserver.maxlogs配置）时，系统会选取最早的HLog对应的一个或多个Region进行flush。

·HBase定期刷新MemStore：默认周期为1小时，确保MemStore不会长时间没有持久化。为避免所有的MemStore在同一时间都进行flush而导致的问题，定期的flush操作有一定时间的随机延时。

·手动执行flush：用户可以通过shell命令flush'tablename'或者flush'regionname'分别对一个表或者一个Region进行flush。

1.3.2 执行流程

为了减少flush过程对读写的影响，HBase采用了类似于两阶段提交的方式，将整个flush过程分为三个阶段。

1）prepare阶段：遍历当前Region中的所有MemStore，将MemStore中当前数据集CellSkipListSet（内部实现采用ConcurrentSkipListMap）做一个快照snapshot，然后再新建一个CellSkipListSet接收新的数据写入。prepare阶段需要添加updateLock对写请求阻塞，结束之后会释放该锁。因为此阶段没有任何费时操作，因此持锁时间很短。

2）flush阶段：遍历所有MemStore，将prepare阶段生成的snapshot持久化为临时文件，临时文件会统一放到目录.tmp下。这个过程因为涉及磁盘IO操作，因此相对比较耗时。

3）commit阶段：遍历所有的MemStore，将flush阶段生成的临时文件移到指定的ColumnFamily目录下，针对HFile生成对应的storefile和Reader，把storefile添加到Store的storefiles列表中，最后再清空prepare阶段生成的snapshot。

1.3.2 生成HFile

HBase执行flush操作之后将内存中的数据按照特定格式写成HFile文件，本小节将会依次介绍HFile文件中各个Block的构建流程。

（1）HFile结构

前面已经对HBase中数据文件HFile的格式进行了详细说。

HFile依次由Scanned Block、Non-scanned Block、Load-on-open以及Trailer四个部分组成。

---Scanned Block：这部分主要存储真实的KV数据，包括Data Block、Leaf Index Block和Bloom Block。

---Non-scanned Block：这部分主要存储Meta Block和Intermediate Level Data Index Blocks，Meta Block这种Block大多数情况下可以不用关心。

---Load-on-open：主要存储HFile元数据信息，包括索引根节点、布隆过滤器元数据等，在RegionServer打开HFile就会加载到内存，作为查询的入口。

---Trailer：存储Load-on-open和Scanned Block在HFile文件中的偏移量、文件大小（未压缩）、压缩算法、存储KV个数以及HFile版本等基本信息。Trailer部分的大小是固定的。

MemStore中KV在flush成HFile时首先构建Scanned Block部分，即KV写进来之后先构建Data Block并依次写入文件，在形成Data Block的过程中也会依次构建形成Leaf index Block、Bloom Block并依次写入文件。一旦MemStore中所有KV都写入完成，Scanned Block部分就构建完成。

Non-scanned Block、Load-on-open以及Trailer这三部分是在所有KV数据完成写入后再追加写入的。

（2）构建"Scanned Block"部分

图示为MemStore中KV数据写入HFile的基本流程，可分为以下4个步骤。

1）MemStore执行flush，首先新建一个Scanner，这个Scanner从存储KV数据的CellSkipListSet中依次从小到大读出每个cell（KeyValue）。这里必须注意读取的顺序性，读取的顺序性保证了HFile文件中数据存储的顺序性，同时读取的顺序性是保证HFile索引构建以及布隆过滤器Meta Block构建的前提。

2）appendGeneralBloomFilter：在内存中使用布隆过滤器算法构建Bloom Block，下文也称为Bloom Chunk。

3）appendDeleteFamilyBloomFilter：针对标记为"DeleteFamily"或者"DeleteFamilyVersion"的cell，在内存中使用布隆过滤器算法构建Bloom Block，基本流程和appendGeneralBloomFilter相同。

4）（HFile.Writer）writer.append：将cell写入Data Block中，这是HFile文件构建的核心。

 

（3）构建Bloom Block

图为Bloom Block构建示意图， chunk和Block两者等价。

布隆过滤器内存中维护了多个称为chunk的数据结构，一个chunk主要由两个元素组成：

·一块连续的内存区域，主要存储一个特定长度的数组。默认数组中所有位都为0，对于row类型的布隆过滤器，cell进来之后会对其rowkey执行hash映射，将其映射到位数组的某一位，该位的值修改为1。

---firstkey，第一个写入该chunk的cell的rowkey，用来构建Bloom Index Block。

cell写进来之后，首先判断当前chunk是否已经写满，写满的标准是这个chunk容纳的cell个数是否超过阈值。如果超过阈值，就会重新申请一个新的chunk，并将当前chunk放入ready chunks集合中。如果没有写满，则根据布隆过滤器算法使用多个hash函数分别对cell的rowkey进行映射，并将相应的位数组位置为1。

（4）构建Data Block

一个cell在内存中生成对应的布隆过滤器信息之后就会写入Data Block，写入过程分为两步。

1）Encoding KeyValue：使用特定的编码对cell进行编码处理，HBase中主要的编码器有DiffKeyDeltaEncoder、FastDiffDeltaEncoder以及PrefixKeyDeltaEncoder等。编码的基本思路是，根据上一个KeyValue和当前KeyValue比较之后取delta，展开讲就是rowkey、column family以及column分别进行比较然后取delta。假如前后两个KeyValue的rowkey相同，当前rowkey就可以使用特定的一个flag标记，不需要再完整地存储整个rowkey。这样，在某些场景下可以极大地减少存储空间。

2）将编码后的KeyValue写入DataOutputStream。

随着cell的不断写入，当前Data Block会因为大小超过阈值（默认64KB）而写满。写满后Data Block会将DataOutputStream的数据flush到文件，该Data Block此时完成落盘。

（5）构建Leaf Index Block

Data Block完成落盘之后会立刻在内存中构建一个Leaf Index Entry对象，并将该对象加入到当前Leaf Index Block。Leaf Index Entry对象有三个重要的字段。

---firstKey：落盘Data Block的第一个key。用来作为索引节点的实际内容，在索引树执行索引查找的时候使用。

---blockOffset：落盘Data Block在HFile文件中的偏移量。用于索引目标确定后快速定位目标Data Block。

---blockDataSize：落盘Data Block的大小。用于定位到Data Block之后的数据加载。

Leaf Index Entry的构建如图所示。

同样，Leaf Index Block会随着Leaf Index Entry的不断写入慢慢变大，一旦大小超过阈值（默认64KB），就需要flush到文件执行落盘。需要注意的是，Leaf Index Block落盘是追加写入文件的，所以就会形成HFile中Data Block、Leaf Index Block交叉出现的情况。

和Data Block落盘流程一样，Leaf Index Block落盘之后还需要再往上构建Root Index Entry并写入Root Index Block，形成索引树的根节点。但是根节点并没有追加写入"Scanned block"部分，而是在最后写入"Load-on-open"部分。

可以看出，HFile文件中索引树的构建是由低向上发展的，先生成Data Block，再生成Leaf Index Block，最后生成Root Index Block。而检索rowkey时刚好相反，先在Root Index Block中查询定位到某个Leaf Index Block，再在Leaf Index Block中二分查找定位到某个Data Block，最后将Data Block加载到内存进行遍历查找。

（6）构建Bloom Block Index

完成Data Block落盘还有一件非常重要的事情：检查是否有已经写满的Bloom Block。如果有，将该Bloom Block追加写入文件，在内存中构建一个Bloom Index Entry并写入Bloom Index Block。

整个流程与Data Block落盘后构建Leaf Index Entry并写入Leaf Index Block的流程完全一样。在此不再赘述。

基本流程总结：flush阶段生成HFile和Compaction阶段生成HFile的流程完全相同，不同的是，flush读取的是MemStore中的KeyValue写成HFile，而Compaction读取的是多个HFile中的KeyValue写成一个大的HFile，KeyValue来源不同。KeyValue数据生成HFile，首先会构建Bloom Block以及Data Block，一旦写满一个Data Block就会将其落盘同时构造一个Leaf Index Entry，写入Leaf Index Block，直至Leaf Index Block写满落盘。实际上，每写入一个KeyValue就会动态地去构建"Scanned Block"部分，等所有的KeyValue都写入完成之后再静态地构建"Non-scanned Block"部分、"Load on open"部分以及"Trailer"部分。

1.4 MemStore Flush对业务的影响

在实践过程中，flush操作的不同触发方式对用户请求影响的程度不尽相同。正常情况下，大部分MemStore Flush操作都不会对业务读写产生太大影响。比如系统定期刷新MemStore、手动执行flush操作、触发MemStore级别限制、触发HLog数量限制以及触发Region级别限制等，这几种场景只会阻塞对应Region上的写请求，且阻塞时间较短。

然而，一旦触发RegionServer级别限制导致flush，就会对用户请求产生较大的影响。在这种情况下，系统会阻塞所有落在该RegionServer上的写入操作，直至MemStore中数据量降低到配置阈值内。

2、　HBase读取流程

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

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

2.1　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。

2.2　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请求之后做了两件事情：首先构建scanner iterator体系；然后执行next函数获取KeyValue，并对其进行条件过滤。

2.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体系可以用图示。

构造好三层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集合，保证有序性。

KeyValue的有序性在前面有阐述，这里不再赘述。

2.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的其他版本。

 

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

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

1）根据KeyRange过滤：因为StoreFile中所有KeyValue数据都是有序排列的，所以如果待检索row范围[startrow，stoprow]与文件起始key范围[firstkey，lastkey]没有交集，比如stoprow<firstkey或者startrow>lastkey，就可以过滤掉该StoreFile。

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

3）根据布隆过滤器进行过滤：StoreFile中布隆过滤器相关Data Block结构在前面已经做过介绍，系统根据待检索的rowkey获取对应的Bloom Block并加载到内存（通常情况下，热点Bloom Block会常驻内存的），再用hash函数对待检索rowkey进行hash，根据hash后的结果在布隆过滤器数据中进行寻址，即可确定待检索rowkey是否一定不存在于该HFile。

2.4 从HFile中读取待查找Key

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

2.4.1 根据HFile索引树定位目标Block

HRegionServer打开HFile时会将所有HFile的Trailer部分和Load-on-open部分加载到内存，Load-on-open部分有个非常重要的Block——Root Index 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 Index Block常驻内存，所以这个过程很快。

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.4.2  BlockCache中检索目标Block

BlockCache根据内存管理策略的不同经历了LRUBlockCache、SlabCache以及BucketCache等多个方案的发展，在内存管理优化、GC优化方面都有了很大的提升。

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

2.4.3  HDFS文件中检索目标Block

上文说到根据文件索引提供的Block Offset以及Block DataSize这两个元素可以在HDFS上读取到对应的Data Block内容（核心代码可以参见HFileBlock.java中内部类FSReaderImpl的readBlockData方法）。这个阶段HBase会下发命令给HDFS，HDFS执行真正的Data Block查找工作。

2.4.4 从Block中读取待查找KeyValue

HFile Block由KeyValue（由小到大依次存储）构成，但这些KeyValue并不是固定长度的，只能遍历扫描查找。