HBase架构详解及读写流程

HBase 定义

HBase 是一种分布式、可扩展、支持海量数据存储的 NoSQL 数据库。

HBase的架构图

架构角色:

1）Master

Master是所有Region Server的管理者，其实现为HRegionServer,主要作用有:

对于表的DDL操作：create，delete，alter；对于RegionServer的操作：分配regions到每个RegionServer，监控每个RegionServer的状态，负载均衡和故障转移。

2）Zookeeper：

HBase通过Zookeeper来做Master的高可用、RegionServer的监控、元数据的入口以及集群配置的维护等工作。

3）WAL：

由于数据要经MemStore排序后才能刷写到HFile，但把数据保存在内存中会有很高的概率导致数据丢失，为了解决这个问题，数据会先写入Write-Ahead logfile的文件中，然后再写入到Memstore中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。

4）MemStore：

写缓存，由于HFile中的数据要求是有序的，所以数据是先存储在MemStore中，排好序后，等到达刷写时机才会刷写到HFile，每次刷写都会形成一个新的HFile。

5）StoreFile： 保存实际数据的物理文件，StoreFile以HFile的形式存储在HDFS上。每个Store会有一个或多个StoreFile(HFile)，数据在StoreFile上是有序的。

3，数据模型：

** 1）Name Space** 命名空间，类似于关系型数据库的DataBase概念，每个命名空间下有多个表。HBase有两个自带的命名空间，分别是hbase和default，hbase中存放的是HBase的内置表，default表示用户默认使用的命名空间。

2）Region

类似于关系型数据库的表概念。不同的是，HBase定义表时只需要生命列簇即可，不需要声明具体的列。这意味着，往HBase写入数据时，字段可以动态、按需指定。

**3）Row**

HBase表中的每行数据都由一个RowKey和多个Column(列)组成，数据是按照RowKey的字典顺序存储的，并且查询时智能根据RowKey进行检索，所以RowKey的设计十分重要。

4）Cloumn

HBase中的每个列都由Cloumn Family（列簇）和Cloumn Qualifier（列限定符）进行限定，例如info：name，info：age。建表时，只需指明列簇，而列限定符无需预先定义。

5）Time Stamp

用于标识数据的不同版本（version），每条数据写入时，如果不指定时间戳，系统会自动为其加上该字段，其值为写入HBase的时间。

6）Cell

由

{ RowKey, ColumnFamily: ColumnQualifier, TimeStamp}

唯一确定的单元。cell 中的数据是没有类型的，全部是字节码形式存贮。

Hbase是bigtable的开源山寨版本。是建立的hdfs之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。

它介于nosql和RDBMS之间，仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。主要用来存储非结构化和半结构化的松散数据。

与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。

HBase 中的表一般有这样的特点： 1、大：一个表可以有上十亿行，上百万列； 2、面向列：面向列(族)的存储和权限控制，列(族)独立检索； 3、稀疏:对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏。

HBase储存结构详解

1.1、HDFS 1.2、HMaster 1.3、HRegionServer 1.4、HRegion 1.4.1、Region/Store/StoreFile/Hfile之间的关系

从上面的架构图可以看出HBase是建立在hadoop之上的,HBase底层依赖于HDFS。HBase有3个重要的组件：Zookeeper、HMaster、HRegionServer。

Zookeeper为整个HBase集群提供协助的服务，HMaster主要用于监控和操作集群的所有RegionServer。RegionServer主要用于服务和管理分区（Regions）

1.1、HDFS

HBase底层依赖于HDFS的

1.2、HMaster

HMaster是HBase集群架构中的主节点，通常一个HBase集群存在多个HMaster节点,其中一个为Active Master,其余为Backup Master。

Hbase每时每刻只有一个HMaster主服务器程序在运行，HMaster将region分配给HRegionServer，协调HRegionServer的负载并维护集群的状态。Hmaster不会对外提供数据服务，而是由HRegionServer负责所有regions的读写请求及操作。

由于HMaster只维护表和region的元数据，负责Region的分配及数据库的创建和删除等操作而不参与数据的输入/输出过程，HMaster失效仅仅会导致所有的元数据无法被修改，但表的数据读/写还是可以正常进行的。 备注：region,HRegionServer职责与功能下面内容中会讲解

1.2.1HMaster的作用：

A、调控Region server的工作 为Region server分配region, 负责HRegionServer的负载均衡,, 监控集群中的Region server的工作状态, 发现失效的HRegionServer并重新分配其上的Hregion（通过监听zookeeper对于ephemeral node状态的通知）。 备注：HRegion,习惯把它称为region,表的意思HRegionServer,习惯把它称为Region server,HRegionServer是HBase集群架构中的从节点

B、管理数据库 提供创建，删除或者更新表格的接口。

1.3、HRegionServer

HRegionServer是HBase集群架构中的从节点，HBase中的表是根据row key的值水平分割成所谓的region的。一个region包含表中所有row key位于region的起始键值和结束键值之间的行。

集群中负责管理Region的结点叫做Region server。Region server负责数据的读写。每一个Region server大约可以管理1000个region。 备注：HRegionServer,习惯把它称为Region server,HRegionServer是HBase集群架构中的从节点。（一些文章写的是Region server、一些写的是HRegionServer，两个意思都是一样的）

1.3.1、HRegionServer由如下几个部分组成 一个HRegionServer会有多个HRegion和一个HLog。 HLog:预写入日志，防止内存中数据丢失 HRegion：表,一个HRegionServer可以维护多个HRegion（习惯称为一个Region Server可以维护多个Region）

1.3.2、HRegionServer的职责 维护HMaster分配给它的HRegion，处理对这些HRegion的IO请求，也就是说客户端直接和HRegionServer打交道。

参考文章：HBase深入分析之RegionServerhttps

1.4、HRegion

概述

Region是HBase数据管理的基本单位，每个HRegion由多个Store构成，每个Store保存一个列族（Columns Family），表有几个列族，则有几个Store，每个Store由一个MemStore和多个StoreFile组成，MemStore是Store在内存中的内容，写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。 Region相当于数据库中的表

1.4.1、Region/Store/StoreFile/Hfile之间的关系

以下内容转载自文章：Hbase中Region/Store/StoreFile/Hfile之间的关系，这篇文章写的超级好，担心原文删除，将文章内容摘录到本篇文章。

1.4.1.1、 Region

table在行的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不同的region可以分别在不同的Region Server上，但同一个Region是不会拆分到多个server上。

Region按大小分隔，表中每一行只能属于一个region。随着数据不断插入表，region不断增大，当region的某个列族达到一个阈值（默认256M）时就会分成两个新的region。

1.4.1.2、 Store

每一个region有一个或多个store组成，至少是一个store，hbase会把一起访问的数据放在一个store里面，即为每个ColumnFamily建一个store（即有几个ColumnFamily，也就有几个Store）。一个Store由一个memStore和0或多个StoreFile组成。

HBase以store的大小来判断是否需要切分region。 store的数据存储在两个地方MemStore和StoreFile

1.4.1.3、 MemStore

写缓存，memStore 是放在内存里的。由于 HFile 中的数据要求是有序的，所以数据是先存储在 MemStore 中，排好序后，等到达刷写时机才会刷写到 HFile（当memStore的大小达到一个阀值【默认64MB】时，memStore会被flush到文件），每次刷写都会形成一个新的 HFile。

1.4.1.4、StoreFile

memStore内存中的数据写到文件后就是StoreFile（即memstore的每次flush操作都会生成一个新的StoreFile），StoreFile底层是以HFile的格式保存。

1.4.1.5、HFile

HFile是HBase中KeyValue数据的存储格式，是hadoop的二进制格式文件。一个StoreFile对应着一个HFile。而HFile是存储在HDFS之上的。

HBase写流程

1、客户端先访问zookeeper，获取Meta表位于那个region server 2、访问Meta表对应的region server服务器，根据请求的信息（namespace:table/rowkey）,在meta表中查询出目标数据位于哪个region server的哪个region中。并将该表的region信息以及meta表的位置信息缓存到客户端的meta cache，方便下次访问。 3、与目标数据的region server进行通讯 4、将数据写入到WAL中 5、将数据写入到对应的memstore中， 6、向客户端发送写入成功的信息 7、等达到memstore的刷写时机后，将数据刷写到HFILE中

参考文章：查看hbase:meta 表位于哪个 Region Server

MemStore Flush刷写

1.当某个MemStore的大小达到了hbase.hregion.memstore.flush.size（默认值 128M），其所在 region 的所有 memstore (对应的列簇)都会刷写。当达到128M的时候会触发flush memstore，当达到128M * n还没法触发flush时候会抛异常来拒绝写入。两个相关参数的默认值如下：

hbase.hregion.memstore.flush.size=128M(默认) hbase.hregion.memstore.block.multiplier=4(默认)

2.当 region server 中 memstore 的总大小达到java_heapsize(应用的堆内存)

hbase.regionserver.global.memstore.size（默认值 0.4） hbase.regionserver.global.memstore.size.lower.limit（默认值 0.95）， region 会按照其所有 memstore 的大小顺序（由大到小）依次进行刷写。直到 region server中所有 memstore 的总大小减小到上述值以下。当 region server 中 memstore 的总大小达到

java_heapsize*hbase.regionserver.global.memstore.size（默认值 0.4）时，会阻止继续往所有的 memstore 写数据。

3.到达自动刷写的时间，也会触发 memstore flush。自动刷新的时间间隔由该属性进行配置 hbase.regionserver.optionalcacheflushinterval（默认 1 小时）。

4.当 WAL 文件的数量超过 hbase.regionserver.maxlogs，region 会按照时间顺序依次进行刷写，直到 WAL 文件数量减小到 hbase.regionserver.maxlogs 以下（该属性名已经废弃，现无需手动设置，最大值为 32）。

数据合并：StoreFile Compaction

由于memstore每次刷写都会生成一个新的HFile，且同一个字段的不同版本(timestamp)和不同类型(Put/Delete)有可能分布在不同的HFile中，因此查询时需要遍历所有的HFile。为了减少HFile的个数，以及清除掉过期和删除的数据，会进行StoreFile Compaction。

Compaction分为两种，分别时Minor Compaction和Major Compaction。Minor Compaction会将临时的若干较小的HFile合并成一个较大的HFile，但不会清理过期和删除的数据。Major Compaction会将一个Store下的所有HFile合并为一个大HFile，并且会清理掉过期和删除的数据。

数据拆分：Region Split

默认情况下，每个 Table 起初只有一个 Region，随着数据的不断写入，Region 会自动进行拆分。刚拆分时，两个子 Region 都位于当前的 Region Server，但处于负载均衡的考虑，HMaster 有可能会将某个 Region 转移给其他的 Region Server。

Region Split 时机：

1.当1个region中的某个Store下所有StoreFile的总大小超过hbase.hregion.max.filesize，该 Region 就会进行拆分（0.94 版本之前）。

2. 当 1 个 region 中的某个 Store 下所有 StoreFile 的总大小超过 Min(R^2 *"hbase.hregion.memstore.flush.size",hbase.hregion.max.filesize")，该 Region 就会进行拆分，其中 R 为当前 Region Server 中属于该 Table 的个数（0.94 版本之后）。

HBase读流程

1、Client客户端先访问zookeeper,获取 hbase:meta 表位于哪个Region Server 2、访问hbase:meta 表对应的region server服务器，根据请求的信息（namespace,table,rowkey)，查询出目标表位于哪个Region Server中的哪个region。并将该表的region信息，以及meta表的位置信息缓存在客户端的缓存中，以便下次访问。 3、与目标表所在的region server 进行通讯 4、分别在Block Cache（读缓存），MemStore和 Store File查询目标数据，并将查到的数据进行合并，此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型（Put/Delete） 5、将从文件中查询到的数据块缓存到block cache 6、将合并后的数据返回给客户端

HBase读数据流程： 1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。 2）访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。 3）与目标 Region Server 进行通讯； 4）分别在 Block Cache（读缓存），MemStore 和 Store File（HFile）中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型（Put/Delete）。 5）将从文件中查询到的数据块（Block，HFile 数据存储单元，默认大小为 64KB）缓存到Block Cache。 6）将合并后的最终结果返回给客户端。

和写流程相比，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体系可以用图表示。

image.png

Scanner的三层体系

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

image.png

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步操作，如图所示。

image.png

HFile读取待查Key流程

根据HFile索引树定位目标Block

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

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

image.png

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查找工作，如图所示。

image.png

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并不是固定长度的，只能遍历扫描查找。