HBase中的Memstore,HFile和KeyValue类

WAL和Memstore的意义

• WAL是存储在HDFS上的，Memstore是存储在内存中的，HFile又是存储在HDFS上的。
• 数据是先写入WAL，再被放入Memstore，最后被持久化到HFile中。

数据在进入HFile之前已经被存储到HDFS一次了，为什么还需要被放入Memstore ?

 这是因为HDFS上的文件只能创建、追加、删除，但是不能修改。对于一个数据库来说，按顺序地存放数据是非常重要的，这是性能的保障，所以我们不能按照数据到来的顺序来写入硬盘。虽然很困难，但是办法还是有的。那就是使用内存先把数据整理成顺序存放，然后再一起写入硬盘。这就是Memstore存在的意义。虽然Memstore是存储在内存中的，HFile和WAL是存储在HDFS上的。但由于数据在写入Memstore之前，要先被写入WAL，所以增加Memstore的大小并不能加速写入速度。Memstore存在的意义是维持数据按照rowkey顺序排列，而不是做一个缓存。

数据被写入WAL之后就会被加载到MemStore中去。MemStore的大小增加到超过一定阀值的时候就会被刷写到HDFS上，以HFile的形式被持久化起来。

Memstore的意义

（1）由于HDFS上的文件不可修改，为了让数据顺序存储从而提高读取效率，HBase使用了LSM树结构来存储数据。数据会先在Memstore中整理成LSM树，最后再刷写到HFile上。不过不要想当然地认为读取也是先读取Memstore再读取磁盘！读取的时候是有专门的缓存叫BlockCache，这个BlockCache如果开启了，就是先读BlockCache，读不到才是读HFile+Memstore。

（2）优化数据的存储。比如一个数据添加后就马上删除了，这样在刷写的时候就可以直接不把这个数据写到HDFS上。 

所以MemStore是实现LSM树存储的必须设计组件。在LSM树的实现方式中，有一个必经的步骤，那就是在数据存储之前先对数据进行排序。而LSM树也是保证HBase能稳定地提供高性能的读能力的基本算法。LSM树是Google BigTable和HBase的基本存储算法，它是传统关系型数据库的B+树的改进。算法的关注重心是“如何在频繁的数据改动下保持系统读取速度的稳定性”，算法的核心在于尽量保证数据是顺序存储到磁盘上的，并且会有频率地对数据进行整理，确保其顺序性。而顺序性就可以最大程度保证数据的读取性能稳定。

HFile

HFile是数据存储的实际载体，我们创建的所有表、列等数据都存储在HFile里面。HFile类似Hadoop的TFile类，它模仿了BigTable的SSTable格式。现在我们来看一个HFile中有哪些组成部分:

 我们可以看到HFile是由一个一个的块组成的。在HBase中一个块的大小默认为64KB，由列族上的BLOCKSIZE属性定义。这些块区分了不同的角色：

• Data：数据块。每个HFile有多个Data块。我们存储在HBase表中的数据就在这里。Data块其实是可选的，但是几乎很难看到不包含Data块的HFile。
• Meta：元数据块。Meta块是可选的，Meta块只有在文件关闭的时候才会写入。Meta块存储了该HFile文件的元数据信息，在v2之前布隆过滤器（Bloom Filter）的信息直接放在Meta里面存储，v2之后分离出来单独存储。
• FileInfo：文件信息，其实也是一种数据存储块。FileInfo是HFile的必要组成部分，是必选的。它只有在文件关闭的时候写入，存储的是这个文件的信息，比如最后一个Key（Last Key），平均的Key长度（Avg Key Len）等。
• DataIndex：存储Data块索引信息的块文件。索引的信息其实也就是Data块的偏移值（offset）。DataIndex也是可选的，有Data块才有DataIndex。
• MetaIndex：存储Meta块索引信息的块文件。MetaIndex块也是可选的，有Meta块才有MetaIndex。
• Trailer：必选的，它存储了FileInfo、DataIndex、MetaIndex块的偏移值。

Data数据块

Data数据块的第一位存储的是块的类型，后面存储的是多个KeyValue键值对，也就是单元格（Cell）的实现类。Cell是一个接口，KeyValue是它的实现类。

KeyValue类

 一个KeyValue类里面最后一个部分是存储数据的Value，而前面的部分都是存储跟该单元格相关的元数据信息。如果你存储的value很小，那么这个单元格的绝大部分空间就都是rowkey、column family、column等的元数据，所以大家的列族和列的名字如果很长，大部分的空间就都被拿来存储这些数据了。这时就需要我们去采用合适的压缩算法来节省我们的存储空间。

HBase 数据单元层次图

 

 KeyValue的写入和读出

写入

写入的过程我们可以理解为把数据写道HDFS的过程，也是说一个KeyValue被持久化到HDFS的过程。其流程如下

 

•  WAL：数据被发出之后第一时间被写入WAL。由于WAL是基于HDFS来实现的，所以也可以说现在单元格就已经被持久化了，但是WAL只是一个暂存的日志，它是不区分Store的。这些数据是不能被直接读取和使用。
• Memstore：数据随后会立即被放入Memstore中进行整理。Memstore会负责按照LSM树的结构来存放数据。这个过程就像我们在打牌的时候，抓牌之后在手上对牌进行整理的过程。
• HFile：最后，当Memstore太大了达到尺寸上的阀值，或者达到了刷写时间间隔阀值的时候，HBaes会被这个Memstore的内容刷写到HDFS系统上，称为一个存储在硬盘上的HFile文件。至此，我们可以称为数据真正地被持久化到硬盘上，就算宕机，断电，数据也不会丢失了。

读出

由于有MemStore（基于内存）和HFile（基于HDFS）这两个机制，通常情况下我们会想到先读取MemStore，如果找不到，再去HFile中查询。这是显而易见的机制，可惜HBase在处理读取的时候并不是这样的。实际的读取顺序是先从BlockCache中找数据，找不到了再去Memstore和HFile中查询数据。
由于HDFS的文件不可变特性，你不可能在一个KeyValue被新建之后删除它，HBase所能做的也就是帮你加上一个墓碑标记。但是你别忘了HDFS是不能修改的，数据被写入的时候都是充分地占用了空间，没有位置可以写入墓碑标记了，这可怎么办？

这里我们要记住一点墓碑标记和数据没有存储在一个地方。

在HBase的Scan操作时，没有取到所需要的所有行键对应的信息之前还会继续扫描下去，直到被扫描的数据大于给出的限定条件为止，这样它才能知道哪些数据应该被返回给用户，而哪些应该被舍弃。所以你增加过滤条件也无法减少Scan遍历的行数，只有缩小STARTROW和ENDROW之间的行键范围才可以明显地加快扫描的速度。

在Scan扫描的时候store会创建StoreScanner实例。StoreScanner会把MemStore和HFile结合起来扫描，所以具体从MemStore还是HFile中读取数据，外部的调用者都不需要知道具体的细节。当StoreScanner打开的时候，会先定位到起始行（STARTROW）上，然后开始往下扫描。

其中红色块部分都是属于指定row的数据，Scan要把所有符合条件的StoreScanner都扫描过一遍之后才会返回数据给用户。