Hbase------regionServer

RegionServer是HBase系统中最核心的组件，主要负责用户数据写入、读取等基础操作。RegionServer组件实际上是一个综合体系，包含多个各司其职的核心模块：HLog、MemStore、HFile以及BlockCache。

先对RegionServer进行分解，并对其中的核心模块进行深入介绍。需要注意的是，这里的介绍仅限于分析其核心作用、内部结构等，而对其在整个HBase的读写流程中所起的作用并不展开讨论，后面再介绍HBase的写入读取流程。

1  RegionServer内部结构

RegionServer是HBase系统响应用户读写请求的工作节点组件，由多个核心模块组成，其内部结构如图所示。

一个RegionServer由一个（或多个）HLog、一个BlockCache以及多个Region组成。其中，HLog用来保证数据写入的可靠性；BlockCache可以将数据块缓存在内存中以提升数据读取性能；Region是HBase中数据表的一个数据分片，一个RegionServer上通常会负责多个Region的数据读写。一个Region由多个Store组成，每个Store存放对应列簇的数据，比如一个表中有两个列簇，这个表的所有Region就都会包含两个Store。每个Store包含一个MemStore和多个HFile，用户数据写入时会将对应列簇数据写入相应的MemStore，一旦写入数据的内存大小超过设定阈值，系统就会将MemStore中的数据落盘形成HFile文件。HFile存放在HDFS上，是一种定制化格式的数据存储文件，方便用户进行数据读取。

2　HLog

HBase中系统故障恢复以及主从复制都基于HLog实现。默认情况下，所有写入操作（写入、更新以及删除）的数据都先以追加形式写入HLog，再写入MemStore。大多数情况下，HLog并不会被读取，但如果RegionServer在某些异常情况下发生宕机，此时已经写入MemStore中但尚未flush到磁盘的数据就会丢失，需要回放HLog补救丢失的数据。此外，HBase主从复制需要主集群将HLog日志发送给从集群，从集群在本地执行回放操作，完成集群之间的数据复制。

2.1　HLog文件结构

HLog文件的基本结构如图所示。

说明如下：

·每个RegionServer拥有一个或多个HLog（默认只有1个，1.1版本可以开启MultiWAL功能，允许多个HLog）。每个HLog是多个Region共享的，图中Region A、Region B和Region C共享一个HLog文件。

·HLog中，日志单元WALEntry（图中小方框）表示一次行级更新的最小追加单元，它由HLogKey和WALEdit两部分组成，其中HLogKey由table name、region name以及sequenceid等字段构成。

WALEdit用来表示一个事务中的更新集合，在0.94之前的版本中，如果一个事务对一行row R三列c1、c2、c3分别做了修改，那么HLog中会有3个对应的日志片段，如下所示：

:

:

:

然而，这种日志结构无法保证行级事务的原子性，假如RegionServer更新c2列之后发生宕机，那么一行记录中只有部分数据写入成功。

为了解决这样的问题，HBase将一个行级事务的写入操作表示为一条记录，如下所示：

:

其中，WALEdit会被序列化为格式<-1，#of edits，，，>，比如<-1，3，，，>，-1为标识符，表示这种新的日志结构。

 

2.2　HLog文件存储

HBase中所有数据（包括HLog以及用户实际数据）都存储在HDFS的指定目录（假设为hbase-root）下，可以通过hadoop命令查看hbase-root目录下与HLog有关的子目录，如下所示：

drwxr-xr-x   - hadoop hadoop          0 2017-09-21 17:12 /hbase/WALs

drwxr-xr-x   - hadoop hadoop          0 2017-09-22 06:52 /hbase/oldWALs

其中，/hbase/WALs存储当前还未过期的日志；/hbase/oldWALs存储已经过期的日志。可以进一步查看/hbase/WALs目录下的日志文件，如下所示：

/hbase/WALs/hbase17.xj.bjbj.org,60020,1505980274300

/hbase/WALs/hbase18.xj.bjbj.org,60020,1505962561368

/hbase/WALs/hbase19.xj.bjbj.org,60020,1505980197364

/hbase/WALs目录下通常会有多个子目录，每个子目录代表一个对应的RegionServer。以hbase17.xj.bjbj.org，60020，1505980274300为例，hbase17.xj.bjbj.org表示对应的RegionServer域名，60020为端口号，1505980274300为目录生成时的时间戳。每个子目录下存储该RegionServer内的所有HLog文件，如下所示：

/hbase/WALs/hbase17.xj.bjbj.org,60020,1505980274300/hbase17.xj.bjbj.org%2C60020%2C1505980274300.default.1506184980449

HLog文件为：

hbase17.xj.bjbj.org%2C60020%2C1505980274300.default.1506012772205

在了解了HLog的文件结构和实际存储结构以后，实践中可能还需要查看HLog文件中的记录内容。HBase提供了如下命令查看HLog文件的内容：

~/hbase-current/bin$ ./hbase hlog

usage: WAL [-h] [-j] [-p] [-r ] [-s ] [-w ]

 -h,--help             Output help message

 -j,--json             Output JSON

-p,--printvals        Print values

 -r,--region      Region to filter by. Pass encoded region name; e.g.

                       '9192caead6a5a20acb4454ffbc79fa14'

 -s,--sequence    Sequence to filter by. Pass sequence number.

 -w,--row         Row to filter by. Pass row name.

比如，可以使用-j参数以json格式打印HLog内容。

除此之外，还可以使用-r参数指定Region，使用-w参数指定row，更加精准化地打印想要的HLog内容。

 

2.3　HLog生命周期

HLog文件生成之后并不会永久存储在系统中，它的使命完成后，文件就会失效最终被删除。HLog整个生命周期如图所示。

HLog生命周期包含4个阶段：

1）HLog构建：HBase的任何写入（更新、删除）操作都会先将记录追加写入到HLog文件中。

2）HLog滚动：HBase后台启动一个线程，每隔一段时间（由参数'hbase.regionserver.logroll.period'决定，默认1小时）进行日志滚动。日志滚动会新建一个新的日志文件，接收新的日志数据。日志滚动机制主要是为了方便过期日志数据能够以文件的形式直接删除。

3）HLog失效：写入数据一旦从MemStore中落盘，对应的日志数据就会失效。为了方便处理，HBase中日志失效删除总是以文件为单位执行。查看某个HLog文件是否失效只需确认该HLog文件中所有日志记录对应的数据是否已经完成落盘，如果日志中所有日志记录已经落盘，则可以认为该日志文件失效。一旦日志文件失效，就会从WALs文件夹移动到oldWALs文件夹。注意此时HLog并没有被系统删除。

4）HLog删除：Master后台会启动一个线程，每隔一段时间（参数'hbase.master.cleaner.interval'，默认1分钟）检查一次文件夹oldWALs下的所有失效日志文件，确认是否可以删除，确认可以删除之后执行删除操作。确认条件主要有两个：

·该HLog文件是否还在参与主从复制。对于使用HLog进行主从复制的业务，需要继续确认是否该HLog还在应用于主从复制。

·该HLog文件是否已经在OldWALs目录中存在10分钟。为了更加灵活地管理HLog生命周期，系统提供了参数设置日志文件的TTL（参数'hbase.master.logcleaner.ttl'，默认10分钟），默认情况下oldWALs里面的HLog文件最多可以再保存10分钟。

 

3　MemStore

HBase系统中一张表会被水平切分成多个Region，每个Region负责自己区域的数据读写请求。水平切分意味着每个Region会包含所有的列簇数据，HBase将不同列簇的数据存储在不同的Store中，每个Store由一个MemStore和一系列HFile组成，如下图所示。

HBase基于LSM树模型实现，所有的数据写入操作首先会顺序写入日志HLog，再写入MemStore，当MemStore中数据大小超过阈值之后再将这些数据批量写入磁盘，生成一个新的HFile文件。LSM树架构有如下几个非常明显的优势：

·这种写入方式将一次随机IO写入转换成一个顺序IO写入（HLog顺序写入）加上一次内存写入（MemStore写入），使得写入性能得到极大提升。大数据领域中对写入性能有较高要求的数据库系统几乎都会采用这种写入模型，比如分布式列式存储系统Kudu、时间序列存储系统Druid等。

·HFile中KeyValue数据需要按照Key排序，排序之后可以在文件级别根据有序的Key建立索引树，极大提升数据读取效率。然而HDFS本身只允许顺序读写，不能更新，因此需要数据在落盘生成HFile之前就完成排序工作，MemStore就是KeyValue数据排序的实际执行者。

·MemStore作为一个缓存级的存储组件，总是缓存着最近写入的数据。对于很多业务来说，最新写入的数据被读取的概率会更大，最典型的比如时序数据，80%的请求都会落到最近一天的数据上。实际上对于某些场景，新写入的数据存储在MemStore对读取性能的提升至关重要。

·在数据写入HFile之前，可以在内存中对KeyValue数据进行很多更高级的优化。比如，如果业务数据保留版本仅设置为1，在业务更新比较频繁的场景下，MemStore中可能会存储某些数据的多个版本。这样，MemStore在将数据写入HFile之前实际上可以丢弃老版本数据，仅保留最新版本数据。

3.1　MemStore内部结构

上面说到写入（包括更新删除操作）HBase中的数据都会首先写入MemStore，除此之外，MemStore还要承担业务多线程并发访问的职责。那么一个很现实的问题就是，MemStore应该采用什么样的数据结构，既能够保证高效的写入效率，又能够保证高效的多线程读取效率？

实际实现中，HBase采用了跳跃表这种数据结构，关于跳跃表的基础知识前面进行了详细介绍。当然，HBase并没有直接使用原始跳跃表，而是使用了JDK自带的数据结构ConcurrentSkipListMap。ConcurrentSkipListMap底层使用跳跃表来保证数据的有序性，并保证数据的写入、查找、删除操作都可以在O（logN）的时间复杂度完成。除此之外，ConcurrentSkipListMap有个非常重要的特点是线程安全，它在底层采用了CAS原子性操作，避免了多线程访问条件下昂贵的锁开销，极大地提升了多线程访问场景下的读写性能。

MemStore由两个ConcurrentSkipListMap（称为A和B）实现，写入操作（包括更新删除操作）会将数据写入ConcurrentSkipListMap A，当ConcurrentSkipListMap A中数据量超过一定阈值之后会创建一个新的ConcurrentSkipListMap B来接收用户新的请求，之前已经写满的ConcurrentSkipListMap A会执行异步flush操作落盘形成HFile。flush的触发时机、写入HFile过程会在后续详细分析。

 

4　HFile

MemStore中数据落盘之后会形成一个文件写入HDFS，这个文件称为HFile。HFile参考BigTable的SSTable和Hadoop的TFile实现。

4.1　HFile逻辑结构

HFile V2版本逻辑结构如图所示：

Scanned block	Data Block
	……
	Leaf Index Block/Bloom Block
	……
	Data Block
	……
	Leaf Index Block/Bloom Block
	……
	Data Block
	……
Non-scanned block	Meta Block
	……
	Meta Block
	Intermediate Level Data Index Blocks
Load-on-open	Root Data Index
	MetaIndex
	FileInfo
	Bloom  filter metadata
Trailer	Trailer fields
	version

HFile文件主要分为4个部分：Scanned block部分、Non-scanned block部分、Load-on-open部分和Trailer。

---Scanned Block部分：顾名思义，表示顺序扫描HFile时所有的数据块将会被读取。这个部分包含3种数据块：Data Block，Leaf Index Block以及Bloom Block。其中Data Block中存储用户的KeyValue数据，Leaf Index Block中存储索引树的叶子节点数据，Bloom Block中存储布隆过滤器相关数据。

----Non-scanned Block部分：表示在HFile顺序扫描的时候数据不会被读取，主要包括保存用户自定义的kv对的Meta Block和Intermediate Level Data Index Blocks两部分。

---Load-on-open部分：这部分数据会在RegionServer打开HFile时直接加载到内存中，包括FileInfo、布隆过滤器MetaBlock、Root Data Index和Meta Block的索引Meta IndexBlock。

---Trailer部分：这部分主要记录了HFile的版本信息、其他各个部分的偏移值和寻址信息。

4.2　HFile物理结构

HFile物理结构如图所示。

Data Block

……

Data Block

Leaf Index Block

Data Block

Meta Block

Meta Block

Intermediate Level Data Index Blocks

Root Data Index Block

Meta Index Block

FileInfo

Bloom  filter meta block

Trailer block

实际上，HFile文件由各种不同类型的Block（数据块）构成，虽然这些Block的类型不同，但却拥有相同的数据结构。

Block的大小可以在创建表列簇的时候通过参数blocksize=>'65535'指定，默认为64K。通常来讲，大号的Block有利于大规模的顺序扫描，而小号的Block更有利于随机查询。因此用户在设置blocksize时需要根据业务查询特征进行权衡，默认64K是一个相对折中的大小。

HFile中所有Block都拥有相同的数据结构，HBase将所有Block统一抽象为HFile-Block。HFileBlock支持两种类型，一种类型含有checksum，另一种不含有checksum。我们说的所有HFileBlock都选用不含有checksum的HFileBlock。HFileBlock结构如图所示：

HFileBlock主要包含两部分：BlockHeader和BlockData。其中BlockHeader主要存储Block相关元数据，BlockData用来存储具体数据。Block元数据中最核心的字段是BlockType字段，表示该Block的类型，HBase中定义了8种BlockType，每种BlockType对应的Block都存储不同的内容，有的存储用户数据，有的存储索引数据，有的存储元数据（meta）。对于任意一种类型的HFileBlock，都拥有相同结构的BlockHeader，但是BlockData结构却不尽相同。下表罗列了最核心的几种BlockType。

 

4.3　HFile的基础Block

1.Trailer Block

Trailer Block主要记录了HFile的版本信息、各个部分的偏移值和寻址信息，下图为Trailer Block的数据结构，其中只显示了部分核心字段。

RegionServer在打开HFile时会加载所有HFile的Trailer部分以及load-on-open部分到内存中。实际加载过程会首先会解析Trailer Block，然后再进一步加载load-on-open部分的数据，具体步骤如下：

1）加载HFile version版本信息，HBase中version包含majorVersion和minorVersion两部分，前者决定了HFile的主版本——V1、V2还是V3；后者在主版本确定的基础上决定是否支持一些微小修正，比如是否支持checksum等。不同的版本使用不同的文件解析器对HFile进行读取解析。

2）HBase会根据version信息计算Trailer Block的大小（不同version的Trailer Block大小不同），再根据Trailer Block大小加载整个HFileTrailer Block到内存中。Trailer Block中包含很多统计字段，例如，TotalUncompressedBytes表示HFile中所有未压缩的KeyValue总大小。NumEntries表示HFile中所有KeyValue总数目。Block中字段CompressionCodec表示该HFile所使用的压缩算法，HBase中压缩算法主要有lzo、gz、snappy、lz4等，默认为none，表示不使用压缩。

3）Trailer Block中另两个重要的字段是LoadOnOpenDataOffset和LoadOnOpenDataSize，前者表示load-on-open Section在整个HFile文件中的偏移量，后者表示load-on-open Section的大小。根据此偏移量以及大小，HBase会在启动后将load-on-open Section的数据全部加载到内存中。load-on-open部分主要包括FileInfo模块、Root Data Index模块以及布隆过滤器Metadata模块，FileInfo是固定长度的数据块，主要记录了文件的一些统计元信息，比较重要的是AVG_KEY_LEN和AVG_VALUE_LEN，分别记录了该文件中所有Key和Value的平均长度。Root Data Index表示该文件数据索引的根节点信息，布隆过滤器Metadata记录了HFile中布隆过滤器的相关元数据。

 

2. Data Block

Data Block是HBase中文件读取的最小单元。Data Block中主要存储用户的KeyValue数据，而KeyValue结构是HBase存储的核心。HBase中所有数据都是以KeyValue结构存储在HBase中。

内存和磁盘中的Data Block结构如下图所示：

KeyValue由4个部分构成，分别为Key Length、Value Length、Key和Value。其中，Key Length和Value Length是两个固定长度的数值，Value是用户写入的实际数据，Key是一个复合结构，由多个部分构成：Rowkey、Column Family、Column Qualifier、TimeStamp以及KeyType。其中，KeyType有四种类型，分别是Put、Delete、DeleteColumn和DeleteFamily。

由Data Block的结构可以看出，HBase中数据在最底层是以KeyValue的形式存储的，其中Key是一个比较复杂的复合结构，这点在前面介绍HBase数据模型时就提到过。因为任意KeyValue中都包含Rowkey、Column Family以及Column Qualifier，因此这种存储方式实际上比直接存储Value占用更多的存储空间。这也是HBase系统在表结构设计时经常强调Rowkey、Column Family以及Column Qualifier尽可能设置短的根本原因。

4.4 HFile中与布隆过滤器相关的Block

布隆过滤器的基本原理前面已做介绍。布隆过滤器对HBase的数据读取性能优化至关重要。前面介绍过HBase是基于LSM树结构构建的数据库系统，数据首先写入内存，然后异步flush到磁盘形成文件。这种架构天然对写入友好，而对数据读取并不友好，因为随着用户数据的不断写入，系统会生成大量文件，用户根据Key获取对应的Value，理论上需要遍历所有文件，在文件中查找指定的Key，这无疑是很低效的做法。使用布隆过滤器可以对数据读取进行相应优化，对于给定的Key，经过布隆过滤器处理就可以知道该HFile中是否存在待检索Key，如果不存在就不需要遍历查找该文件，这样就可以减少实际IO次数，提高随机读性能。布隆过滤器通常会存储在内存中，所以布隆过滤器处理的整个过程耗时基本可以忽略。

HBase会为每个HFile分配对应的位数组，KeyValue在写入HFile时会先对Key经过多个hash函数的映射，映射后将对应的数组位置为1，get请求进来之后再使用相同的hash函数对待查询Key进行映射，如果在对应数组位上存在0，说明该get请求查询的Key肯定不在该HFile中。当然，如果映射后对应数组位上全部为1，则表示该文件中有可能包含待查询Key，也有可能不包含，需要进一步查找确认。

可以想象，HFile文件越大，里面存储的KeyValue值越多，位数组就会相应越大。一旦位数组太大就不适合直接加载到内存了，因此HFile V2在设计上将位数组进行了拆分，拆成了多个独立的位数组（根据Key进行拆分，一部分连续的Key使用一个位数组）。这样，一个HFile中就会包含多个位数组，根据Key进行查询时，首先会定位到具体的位数组，只需要加载此位数组到内存进行过滤即可，从而降低了内存开销。

在文件结构上每个位数组对应HFile中一个Bloom Block，因此多个位数组实际上会对应多个Bloom Block。为了方便根据Key定位对应的位数组，HFile V2又设计了相应的索引Bloom Index Block，对应的内存和逻辑结构如图所示。

整个HFile中仅有一个Bloom Index Block数据块，位于load-on-open部分。Bloom Index Block（见图左侧部分）从大的方面看由两部分内容构成，其一是HFile中布隆过滤器的元数据基本信息，其二是构建了指向Bloom Block的索引信息。

Bloom Index Block结构中TotalByteSize表示位数组大小，NumChunks表示Bloom Block的个数，HashCount表示hash函数的个数，HashType表示hash函数的类型，TotalKeyCount表示布隆过滤器当前已经包含的Key的数目，TotalMaxKeys表示布隆过滤器当前最多包含的Key的数目。

Bloom Index Entry对应每一个Bloom Block的索引项，作为索引分别指向scanned block部分的Bloom Block，Bloom Block中实际存储了对应的位数组。Bloom Index Entry的结构见图中间部分，其中BlockKey是一个非常关键的字段，表示该Index Entry指向的Bloom Block中第一个执行Hash映射的Key。BlockOffset表示对应Bloom Block在HFile中的偏移量。

因此，一次get请求根据布隆过滤器进行过滤查找需要执行以下三步操作：

1）首先根据待查找Key在Bloom Index Block所有的索引项中根据BlockKey进行二分查找，定位到对应的Bloom Index Entry。

2）再根据Bloom Index Entry中BlockOffset以及BlockOndiskSize加载该Key对应的位数组。

3）对Key进行Hash映射，根据映射的结果在位数组中查看是否所有位都为1，如果不是，表示该文件中肯定不存在该Key，否则有可能存在。

4.5　HFile中索引相关的Block

根据索引层级的不同，HFile中索引结构分为两种：single-level和multi-level，前者表示单层索引，后者表示多级索引，一般为两级或三级。HFile V1版本中只有single-level一种索引结构，V2版本中引入多级索引。之所以引入多级索引，是因为随着HFile文件越来越大，Data Block越来越多，索引数据也越来越大，已经无法全部加载到内存中，多级索引可以只加载部分索引，从而降低内存使用空间。同布隆过滤器内存使用问题一样，这也是V1版本升级到V2版本最重要的因素之一。

V2版本Index Block有两类：Root Index Block和NonRoot Index Block。NonRoot Index Block又分为Intermediate Index Block和Leaf Index Block两种。HFile中索引是树状结构，Root Index Block表示索引数根节点，Intermediate Index Block表示中间节点，Leaf Index Block表示叶子节点，叶子节点直接指向实际Data Block，如下图所示。

需要注意的是，这三种Index Block在HFile中位于不同的部分，Root Index Block位于“load-on-open”部分，会在RegionServer打开HFile时加载到内存中。Intermediate Index Block位于“Non-Scanned block”部分，Leaf Index Block位于“scanned block”部分。

HFile中除了Data Block需要索引之外，Bloom Block也需要索引，Bloom索引结构实际上采用了单层结构，Bloom Index Block就是一种Root Index Block。

对于Data Block，由于HFile刚开始数据量较小，索引采用单层结构，只有Root Index一层索引，直接指向Data Block。当数据量慢慢变大，Root Index Block大小超过阈值之后，索引就会分裂为多级结构，由一层索引变为两层，根节点指向叶子节点，叶子节点指向实际Data Block。如果数据量再变大，索引层级就会变为三层。

 

下面针对Root index Block和NonRoot index Block两种结构进行解析（Intermediate Index Block和Ieaf Index Block在内存和磁盘中存储格式相同，都为NonRoot Index Block格式）。

4.5.1 Root Index Block

Root Index Block表示索引树根节点索引块，既可以作为Bloom Block的直接索引，也可以作为Data Block多极索引树的根索引。对于单层和多级这两种索引结构，对应的Root Index Block结构略有不同，单层索引结构是多级索引结构的一种简化场景。我们以多级索引结构中的Root Index Block为例进行分析，下图为Root Index Block的结构图。

图中Index Entry表示具体的索引对象，每个索引对象由3个字段组成：Block Offset表示索引指向Data Block的偏移量，BlockDataSize表示索引指向Data Block在磁盘上的大小，BlockKey表示索引指向Data Block中的第一个Key。

除此之外，还有另外3个字段用来记录MidKey的相关信息，这些信息用于在对HFile进行split操作时，快速定位HFile的切分点位置。需要注意的是单层索引结构和多级索引结构相比，仅缺少与MidKey相关的这三个字段。

Root Index Block位于整个HFile的“load-on-open”部分，因此会在RegionServer打开HFile时直接加载到内存中。此处需要注意的是，在Trailer Block中有一个字段为DataIndexCount，表示Root Index Block中Index Entry的个数，只有知道Entry的个数才能正确地将所有Index Entry加载到内存。

4.5.2  NonRoot Index Block

当HFile中Data Block越来越多，单层结构的根索引会不断膨胀，超过一定阈值之后就会分裂为多级结构的索引结构。多级结构中根节点是Root Index Block。而索引树的中间层节点和叶子节点在HBase中存储为NonRoot Index Block，但从Block结构的视角分析，无论是中间节点还是叶子节点，其都拥有相同的结构，如图所示。

和Root Index Block相同，NonRoot IndexBlock中最核心的字段也是Index Entry，用于指向叶子节点块或者Data Block。不同的是，NonRoot Index Block结构中增加了Index Entry的内部索引Entry Offset字段，Entry Offset表示Index Entry在该Block中的相对偏移量（相对于第一个Index Entry），用于实现Block内的二分查找。通过这种机制，所有非根节点索引块（包括Intermediate Index Block和Leaf Index Block）在其内部定位一个Key的具体索引并不是通过遍历实现，而是使用二分查找算法，这样可以更加高效快速地定位到待查找Key。