HBase存储架构 转.doc

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目录下的每个文件夹对应一个HR