HBASE存储架构.doc

hbase存储架构英文原文：/2009/10/hbase-architecture-101-storage.htmlhbase最隐秘的问题之一就是它的数据是如何存储的。虽然大多数用户都不会因为这个问题向你抱怨，但是如果你想学习哪些高级的配置选项并了解它们的意思，你可能就需要来了解一下这个存储问题了。“怎样才能把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/在每个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具体的数据存储文件的结构。storefile以hfile格式保存在hdfs上。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，开始是固定长度的数值，rowlength表示row的长度，紧接着是row，然后是固定长度的数值，表示family的长度，然后是family，接着是qualifier，然后是两个固定长度的数值，表示time stamp和key type。value部分没有这么复杂的结构，就是纯粹的数据。.apache.hadoop.hbase.keyvalue是用来处理这个keyvalue，你可能会发现在这个类里面有两个方法：getkey和getrow。getkey当然是用来获取key的内容，那么getrow是什么？其实是用来获取rowkey的。rowkey不是hbase的基本元素吗？是的，这个类已经不是纯粹的key&value处理，它已经打上了hbase的烙印。好了，这篇文章就到此为止了，它对hbase的存储架构做了一个大致的介绍。希望这篇文章对于那些想更深入的挖掘hbase细节的人来说，能作为一个起点。hbase 数据文件在hdfs上的存储posted on july 24, 2010 by harry_ding hbase 数据文件在hdfs上的存储英文原文：/2010/05/hbase-file-locality-in-hdfs.html在hdfs上面最不明确的事情之一就是数据的冗余。它完全是自动进行的，因为无法得知其中详细的信息，我们需要做的就是相信它。hbase完全相信hdfs存储数据的安全性和完整性，并将数据文件交给hdfs存储。正是因为hdfs的数据冗余方式对于hbase来说是完全透明的，产生了一个问题：hbase的效率会受到多大的影响？说的简单一点，当hbase需要存取数据时，如何保证有一份冗余的数据块离自己最近？当我们对hbase做一次mapreduce的扫描操作时，这个问题尤其显现出来。所有的regionserver都在从hdfs上面读取数据，理想的状况当然是每个regionserver要读取的数据都离自己很近。这个问题就牵扯到hbase的数据文件是如何在hdfs上面存储的。让我们首先抛开hbase，假设要处理的数据就是hdfs上面的数据块，看看hadoop是如何工作的。mapreduce总是有一个建议，那就是在每个tasktracker上面map/reduce程序要处理的数据在本地就有一份冗余。这样程序只需要与本地数据交互，减少了网络流量并提高了效率。为了做到这一点，hdfs会把大文件分割成很多小文件来存储，我们称之为数据块（block）。每个数据块的大小比操作系统数据块的大小要大得多，默认是64m，但通常我们选择128m，或者某个更大的值（这取决与你的文件大小，最好你的单个文件大小总是大于一个数据块）。在mapreduce中，每个数据块会被分配给一个task，这个task就负责处理这个数据块中的数据。所以数据块越大，产生的task就越少，需要mapper的数量就越少。hadoop自己知道每个数据块存储的位置，这样在任务分配的时候就可以直接在存储数据块的机器上启动task，或者选择一个最近机器启动task。真是因为每个数据块有多份冗余，使得hadoop有更大的选择空间。只要找到一份冗余符合条件就行了，不是吗？这样hadoop就可以保证在mapreduce期间task总是操作本地数据。让我们回到hbase，现在你已经理解了hadoop是如何保证在mapreduce的过程中每个task都尽量处理本地数据。如果你看过hbase的存储架构你就会知道hbase只是简单的将hfile和wal log存储在hdfs上面。通过简单的调用hdfs的api来创建文件：filesystem.create(path path)。接下来你会关心两件事情的效率：1）随机的访问 2)通过mapreduce扫描全表。我们当然希望当每个regionserver读取数据时存储数据的数据块就在本地。它能做到吗？第一种情况，你有两个集群，一个集群装hadoop，另一个集群装hbase，两个集群是分隔开的，只有网线来传输数据。好了，讨论到此为止，神也帮不了你。第二种情况，你有一个大的集群，每台机器都混装了hadoop和hbase，每个regionserver上面都有一个datanode（这是我们最希望看到的）。好，这样的话regionserver就具备了从本地读取数据的前提。我们还剩下一个问题，如何保证每个regionserver管理的region所对应的hfile和wal log就存在本地的datanode上面？设想一种情况，你对hbase创建了大量的数据，每个regionserver都管理了各自的region，这时你重启了hbase，重启了所有的regionserver，所有的region都会被随机的分配给各个regionserver，这种情况下你显然无法保证我们希望的本地数据存储。在讨论如何解决这个问题之前我们先强调一点：hbase不应该频繁的被重启，并且部署的架构不应该被频繁的改变，这是能解决这个问题的一个基础。写入hdfs的文件都有一个特点，一旦写入一个文件就无法更改（由于种种原因）。因此hbase会定期的将数据写入hdfs中并生成一个新文件。这里有一个让人惊奇的地方：hdfs足够聪明，它知道如何将文件写到最合适的地方。换句话说，它知道把文件放到什么地方使得regionserver用起来最方便。如果想知道hdfs如何做到这一点，我们需要深入学习hadoop的源代码，看看前面提到的filesystem.create(path path) 具体是怎么工作的。在hdfs中实际调用的函数是：distributedfilesystem.create(path path), 他看起来是这个样子的：public fsdataoutputstream create(path f) throws ioexception return create(f, true);public fsdataoutputstream create(path f, fspermission permission, boolean overwrite, int buffersize, short replication, long blocksize, progressable progress) throws ioexception return new fsdataoutputstream(dfs.create(getpathname(f), permission, overwrite, replication, blocksize, progress, buffersize), statistics);其中dfs是一个连接到hdfs namenode的dfsclient。当你向hdfs写入数据的时候，数据都流过dfsclient.dfsoutputstream，dfsclient将这些数据收集，积攒到一定程度后，作为一个block写入到datanode里面。将一个block写到datanode的过程都发生在dfsclient.dfsoutputstream.datastreamer里面，它是一个运行在后台的守护线程。注意，从现在开始我们将逐渐揭开解决问题的秘密方法。在接收到一个block以后，datastreamer需要知道这个block应该被写到哪些datanode上面，同时它也应该让namenode知道这个block写到了哪些datanode上面。它的做法是联络namenode：hi，我这里有一个文件的一个block，请告诉我应该写在哪些datanode上面？nodes = nextblockoutputstream(src);-long starttime = system.currenttimemillis();lb = locatefollowingblock(starttime);block = lb.getblock();nodes = lb.getlocations();-return namenode.addblock(src, clientname);这时namenode收到了一个添加block的请求，它包含两个参数：src和clientname其中src标明了这个block属于哪个文件，clientname则是client端的名称。我们跳过一些简单的步骤来看最重要的一步：public locatedblock getadditionalblock(string src, string clientname) throws ioexception inodefileunderconstruction pendingfile = checklease(src, clientname);filelength = pendingfputecontentsummary().getlength();blocksize = pendingfile.getpreferredblocksize();clientnode = pendingfile.getclientnode();replication = (int)pendingfile.getreplication();/ choose targets for the new block tobe allocated.datanodedescriptor targets = replicator.choosetarget(replication, clientnode, null, blocksize);最重要的一步就是replicator.choosetarget()，它的具体实现如下：private datanodedescriptor choosetarget(int numofreplicas, datanodedescriptor writer, list excludednodes, long blocksize, int maxnodesperrack, list results) if (numofreplicas = 0 | clustermap.getnumofleaves()=0) return writer;int numofresults = results.size();boolean newblock = (numofresults=0);if (writer = null & !newblock) writer = (datanodedescriptor)results.get(0);try switch(numofresults) case 0:writer = chooselocalnode(writer, excludednodes, blocksize, maxnodesperrack, results);if (numofreplicas = 0) break;case 1:chooseremoterack(1, results.get(0), excludednodes, blocksize, maxnodesperrack, results);if (numofreplicas =