HBase存储架构

http://hi.baidu.com/hontlong/blog/item/c397e32a43f9cc23d52af179.html

HBase存储架构

英文原文：http://www.larsgeorge.com/2009/10/hbase-architecture-101-storage.html

HBase最隐秘的问题之一就是它的数据是如何存储的。虽然大多数用户都不会因为这个问题向你抱怨，但是如果你想学习哪些高级的配置选项并了解它们的意思，你可能就需要来了解一下这个存储问题了。“怎样才能把HBase调整到最适合我需求的状态？”你可能对于这样一系列类似的问题非常感兴趣。那么你就需要绕过这些问题来学习HBase的基础知识。另一个支持你学习这些基础知识的理由是有时候各种各样你想不到的灾难需要你恢复整个HBase。

我首先学习了HBase中控制各种不同文件的独立的类，然后根据我对整个HBase存储系统的理解在脑海中构建HBase架构的图像。但是我发现想要在头脑中构建出一幅连贯的HBase架构图片很困难，于是我就把它画了出来。

你可能注意到了这不是一个UML图或者调用图。这个图混合了类和他们管理控制的文件，将注意力集中到了本文要讨论的主题上。后面我将会讨论这张图所涉及到的细节，包括一些配置文件项是如何影响底层的文件存储系统的。

好，我们现在来分析这张图里面到底包含了什么。首先HBase操控两种基本类型的文件，一种用于存储WAL的log，另一种用于存储具体的数据。这两种文件主要由HRegionServer来管理，但是在有的情况下HMaster会跳过HRegionServer，直接操作这两种文件。你可能注意到了，这些文件都被存储在HDFS上面，并且每个文件包含了多个数据块。配置文件中就有一个选项用来调整系统控制数据的大小。我们后面会详细讨论这个问题。

接下来看一下数据的大致流程。假设你需要通过某个特定的RowKey查询一行记录，首先Client端会连接Zookeeper Qurom，通过Zookeeper，Client能获知哪个Server管理-ROOT- Region。接着Client访问管理-ROOT-的Server，进而获知哪个Server管理.META.表。这两个信息Client只会获取一次并缓存起来。在后续的操作中Client会直接访问管理.META.表的Server，并获取Region分布的信息。一旦Client获取了这一行的位置信息，比如这一行属于哪个Region，Client将会缓存这个信息并直接访问HRegionServer。久而久之Client缓存的信息渐渐增多，即使不访问.META.表也能知道去访问哪个HRegionServer。

注意：当HBase启动的时候HMaster负责分配Region给HRegionServer，这其中当然也包括-ROOT-表和.META.表的Region。

接下来HRegionServer打开这个Region并创建一个HRegion对象。当HRegion打开以后，它给每个table的每个HColumnFamily创建一个Store实例。每个Store实例拥有一个或者多个StoreFile实例。StoreFile对HFile做了轻量级的包装。除了Store实例以外，每个HRegion还拥有一个MemStore实例和一个HLog实例。现在我们就可以看看这些实例是如何在一起工作的，遵循什么样的规则以及这些规则的例外。

保留住Put

现在看一下数据是怎样被写到实际的存储中去的。Client发起了一个HTable.put(Put)请求给HRegionServer，HRegionServer会将请求匹配到某个具体的HRegion上面。紧接着的操作时决定是否写WAL log。是否写WAL log由Client传递的一个标志决定，你可以设置这个标志：Put.writeToWAL(boolean)。WAL log文件是一个标准的Hadoop SequenceFile（现在还在讨论是否应该把文件格式改成一个更适合HBase的格式）。在文件中存储了HLogKey，这些Keys包含了和实际数据对应的序列号，用途是当RegionServer崩溃以后能将WAL log中的数据同步到永久存储中去。做完这一步以后，Put数据会被保存到MemStore中，同时会检查MemStore是否已经满了，如果已经满了，则会触发一个Flush to Disk的请求。HRegionServer有一个独立的线程来处理Flush to Disk的请求，它负责将数据写成HFile文件并存到HDFS上。它也会存储最后写入的数据序列号，这样就可以知道哪些数据已经存入了永久存储的HDFS中。现在让我们来看看这些存储文件。

存储文件

HBase在HDFS上面的所有文件有一个可配置的根目录，默认根目录是/hbase。通过使用hadoop的DFS工具就可以看到这些文件夹的结构。

在根目录下面你可以看到一个.logs文件夹，这里面存了所有由HLog管理的WAL log文件。在.logs目录下的每个文件夹对应一个HRegionServer，每个HRegionServer下面的每个log文件对应一个Region。

有时候你会发现一些oldlogfile.log文件（在大多数情况下你可能看不到这个文件），这个文件在一种异常情况下会被产生。这个异常情况就是HMaster对log文件的访问情况产生了怀疑，它会产生一种称作“log splits”的结果。有时候HMaster会发现某个log文件没人管了，就是说任何一个HRegionServer都不会管理这个log文件（有可能是原来管理这个文件的HRegionServer挂了），HMaster会负责分割这个log文件（按照它们归属的Region），并把那些HLogKey写到一个叫做oldlogfile.log的文件中，并按照它们归属的Region直接将文件放到各自的Region文件夹下面。各个HRegion会从这个文件中读取数据并将它们写入到MemStore中去，并开始将数据Flush to Disk。然后就可以把这个oldlogfile.log文件删除了。

注意：有时候你可能会发现另一个叫做oldlogfile.log.old的文件，这是由于HMaster做了重复分割log文件的操作并发现oldlogfile.log已经存在了。这时候就需要和HRegionServer以及HMaster协商到底发生了什么，以及是否可以把old的文件删掉了。从我目前遇到的情况来看，old文件都是空的并且可以被安全删除的。

HBase的每个Table在根目录下面用一个文件夹来存储，文件夹的名字就是Table的名字。在Table文件夹下面每个Region也用一个文件夹来存储，但是文件夹的名字并不是Region的名字，而是Region的名字通过Jenkins Hash计算所得到的字符串。这样做的原因是Region的名字里面可能包含了不能在HDFS里面作为路径名的字符。在每个Region文件夹下面每个ColumnFamily也有自己的文件夹，在每个ColumnFamily文件夹下面就是一个个HFile文件了。所以整个文件夹结构看起来应该是这个样子的：

/hbase/<tablename>/<encoded-regionname>/<column-family>/<filename>

在每个Region文件夹下面你会发现一个.regioninfo文件，这个文件用来存储这个Region的Meta Data。通过这些Meta Data我们可以重建被破坏的.META.表，关于.regioninfo的应用你可以参考HBASE-7和HBASE-1867。

有一件事情前面一直没有提到，那就是Region的分割。当一个Region的数据文件不断增长并超过一个最大值的时候（你可以配置这个最大值 hbase.hregion.max.filesize），这个Region会被切分成两个。这个过程完成的非常快，因为原始的数据文件并不会被改变，系统只是简单的创建两个Reference文件指向原始的数据文件。每个Reference文件管理原始文件一半的数据。Reference文件名字是一个ID，它使用被参考的Region的名字的Hash作为前缀。例如：1278437856009925445.3323223323。Reference文件只含有非常少量的信息，这些信息包括被分割的原始Region的Key以及这个文件管理前半段还是后半段。HBase使用HalfHFileReader类来访问Reference文件并从原始数据文件中读取数据。前面的架构图只并没有画出这个类，因为它只是临时使用的。只有当系统做Compaction的时候原始数据文件才会被分割成两个独立的文件并放到相应的Region目录下面，同时原始数据文件和那些Reference文件也会被清除。

前面dump出来的文件结构也证实了这个过程，在每个Table的目录下面你可以看到一个叫做compaction.dir的目录。这个文件夹是一个数据交换区，用于存放split和compact Region过程中生成的临时数据。

HFile

现在我们将深入HBase存储架构的核心，探讨HBase具体的数据存储文件的结构。HFile就是这个数据存储文件的结构（Ryan Rawson就是靠它扬名立万的）。创建HFile这样一个文件结构的目的只有一个：快速高效的存储HBase的数据。HFile是基于Hadoop TFile的（参见 HADOOP-3315）。HFile模仿了Google Bigtable中SSTable的格式。原先HBase使用Hadoop的MapFile，但是这种文件已经被证明了效率差。

现在让我们来看看这个文件结构到底是什么样的。

首先这个文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。正如图中所示的，Trailer中有指针指向其他数据块的起始点。Index数据块记录了每个Data块和Meta块的起始点。Data块和Meta块都是可有可无的，但是对于大部分的HFile，你都可以看到Data块。

那么每个块的大小是如何确定的呢？这个值可以在创建一个Table的时候通过HColumnDescriptor（实际上应该称作FamilyDescriptor）来设定。这里我们可以看一个例子：

{NAME => ‘docs’, FAMILIES => [{NAME => ‘cache’, COMPRESSION => ‘NONE’, VERSIONS => ’3′, TTL => ’2147483647′, BLOCKSIZE => ’65536′, IN_MEMORY => ‘false’, BLOCKCACHE => ‘false’}, {NAME => ‘contents’, COMPRESSION => ‘NONE’, VERSIONS => ’3′, TTL => ’2147483647′, BLOCKSIZE => ’65536′, IN_MEMORY => ‘false’, BLOCKCACHE => ‘false’}, …

从这里可以看出这是一个叫做docs的Table，它有两个Family：cache和contents，这两个Family对应的HFile的数据块的大小都是64K。

关于如何设定数据块的大小，我们应用一段HFile源码中的注释：

我们推荐将数据块的大小设置为8KB至1MB。大的数据块比较适合顺序的查询（比如Scan），但不适合随机查询，想想看，每一次随机查询可能都需要你去解压缩一个大的数据块。小的数据块适合随机的查询，但是需要更多的内存来保存数据块的索引(Data Index)，而且创建文件的时候也可能比较慢，因为在每个数据块的结尾我们都要把压缩的数据流Flush到文件中去（引起更多的Flush操作）。并且由于压缩器内部还需要一定的缓存，最小的数据块大小应该在20KB – 30KB左右。可能从前面的描述你会发现数据块（Data Block）是数据压缩的一个单位。后面我们会深入Data Block内部去了解它的详细构造。

在HBase的配置文件中你会看到一个参数：hfile.min.blocksize.size，这个参数看上去只会用在数据迁移或者通过工具直接创建HFile的过程中。（貌似HBase创建HFile不会使用这个参数，HBase使用的是.META.表中记录的那个值）。

呼——，到现在为止解释的还不错吧。好了，让我们继续。有时候我们可能会想知道一个HFile是否正常以及它里面包含了什么内容。没问题，已经有一个应用程序来做这件事了。

HFile.main()本身就提供了一个用来dump HFile的工具。

这里有一个dump文件的例子：

第一部分是存储具体数据的KeyValue对，每个数据块除了开头的Magic以外就是一个个KeyValue对拼接而成。后面会详细介绍每个KeyValue对的内部构造。第二部分是Tailer块的具体内容，最后一部分是FileInfo块的具体内容。Dump HFile还有一个作用就是检查HFile是否正常。

KeyValue对

HFile里面的每个KeyValue对就是一个简单的byte数组。但是这个byte数组里面包含了很多项，并且有固定的结构。我们来看看里面的具体结构：

开始是两个固定长度的数值，分别表示Key的长度和Value的长度。紧接着是Key，开始是固定长度的数值，表示RowKey的长度，紧接着是RowKey，然后是固定长度的数值，表示Family的长度，然后是Family，接着是Qualifier，然后是两个固定长度的数值，表示Time Stamp和Key Type。Value部分没有这么复杂的结构，就是纯粹的数据。

java.org.apache.hadoop.hbase.KeyValue是用来处理这个KeyValue，你可能会发现在这个类里面有两个方法：getKey和getRow。getKey当然是用来获取Key的内容，那么getRow是什么？其实是用来获取RowKey的。RowKey不是HBase的基本元素吗？是的，这个类已经不是纯粹的Key&Value处理，它已经打上了HBase的烙印。

好了，这篇文章就到此为止了，它对HBase的存储架构做了一个大致的介绍。希望这篇文章对于那些想更深入的挖掘HBase细节的人来说，能作为一个起点。