HBase与BigTable的比较

HBase与BigTable的比较(翻译)博客分类：HadoopHBaseHadoopMapreduce数据结构配置管理知，HBase是Google的BigTable架构的一个开源实现。但是我个人觉得，要做到充分了解下面两点还是有点困难的：一HBase涵盖了BigTable规范的哪些部分？二HBase与BigTable仍然有哪些区别？下面我将对这两个系统做些比较。在做比较之前，我要指出一个事实：HBase是非常接近BigTable论文描述的东西。撇开一些细微的不同，比如HBase0.20使用ZooKeeper做它的分布式协调服务，HBase已经基本实现了BigTable所有的功能，所以我下面的篇幅重点落在它们细微的区别上，当然也可以说是HBase小组正在努力改进的地方上。比较范围本文比较的是基于七年前发表的论文（OSDI’06）所描叙的GoogleBigTable系统,该系统从2005年开始运作。就在论文发表的2006年末到2007年初，作为Hadoop的子项目的HBase也产生了。在那时，HBase的版本是0.15.0.如今大约2年过去了，Hadoop0.20.1和HBase0.20.2都已发布，你当然希望有一些真正的改进。要知道我所比较的是一篇14页的技术论文和一个从头到脚都一览无余的开源项目。所以下面的比较内容里关于HBase怎么做的讲得比较多点。在文章的结尾，我也会讨论一些BigTable的如今的新功能，以及HBase跟它们比较如何。好，我们就从术语开始。术语有少数几个不同的术语被两个系统用来描述同样的事物。最显著的莫过于HBase中的regions和BigTable中的tablet。自然地，它们各自把一连串的行（Rows）切分交给许多Regionserver或者tabletserver管理。特性比较接下来的就是特性比较列表，列表中是BigTable跟HBase的特性比较。有的是一些实现细节，有的是可配置的选项等。让人感到有困惑的是，将这些特性分类很难。特性BigTableHBase说明读/写/修改的原子性支持，每行支持，每行因为BigTable不像关系型数据库，所以不支持事务。最接近事务的就是让对每行数据访问具有原子性。HBase同样实现了”行锁”的API，让用户访问数据时给一行或者几行数据加锁。词典顺序的行排序支持支持所有行都按照词典顺序排序数据块支持支持支持在数据存储文件中，数据是由更小的数据块构成的。这使从大的存储文件读取数据更快。数据块的大小是可配置的，典型配置是64K。数据块压缩支持，按ColumnFamily支持，按ColumnFamilyGoogle使用BMDiff和Zippy做两步处理。BMDiff工作得很好是因为存储文件中相邻的key-value对的内容经常非常相似。因为数据支持多个版本，几个版本的内容会被排序然后被存在一起，它们之间有很多相同的内容。或者rowkey也会被用这样的方式处理，比如如果用URL来作为rowkey，而这些URL来自统一个网站，那么rowkey也会有很多相似之处。Zippy使用的是改进的LZW算法。HBase使用的是Java支持的标准的GZip，以及一点点GPLlicensedLZO格式支持。Hadoop也有想使用BMDiff和Zippy的征兆。ColumnFamily数量限制最多几百小于100理论上行数和列数是无限的，可是列族（columnfamily）却不是。这个只是设计上的一些折中考率.ColumnFamil命名格式可打印可打印HBase这样做的主要原因是ColumnFamil的名称会被作为文件系统中的目录名称Qualifier命名的格式任意任意任意的字节数组Key/Value对的格式任意任意任意的字节数组访问控制支持无BigTable支持columnfamily级别的访问控制。HBase暂不支持Cell多版本支持支持多版本支持是基于时间戳。版本数目限制可以基于cloumnfamily级别自由配置自定义时间戳支持支持两个系统都支持用户设定时间戳，如果用户不指定，则使用当前时间作为时间戳。数据TTL支持支持除了数据可以有多个版本，用户还可制定TTL（time-to-live），当数据到期后会被清除批量写入支持支持都支持批量表操作值计数器支持支持两者都可使用特定的列作为原子计数器。HBase实现是：当计数器的值要增长时，它必须获得行锁。行过滤器支持支持两者都支持扫描行时支持行过滤器客户端脚本执行支持不支持BigTable使用Sawzall使客户端可以处理存储的数据。MapReduce支持支持支持两者都有方便的工具类让MapReduceJob扫描表。底层文件系统GFSHDFS,S3,S3N,EBSBigTable工作在GFS之上，HBase可以使用任何文件系统，只要有该文件系统的代理或者驱动即可。存储文件格式SSTableHFile块索引在文件最后在文件最后两者都有相似的块结构化的存储文件格式，并且块索引被放在文件的最后内存映射支持不支持BigTable可以让存储文件直接映射到内存。锁服务ChubbyZooKeeperZooKeeper被HBase用来协调任务并非当成锁服务。总体说来，HBase使用ZooKeeper达到了BigTable使用Chubby的效果，只有语义有点细微区别。单个Master是不是HBase近来支持多个Master。多个Master是”热”待命模式工作，它们都侦听ZooKeeper上的Master节点。Tablet/Region数目10-100010-1000两个系统都推荐每个Regionserver分配相同数目的region。当然这决定于很多因素，由于两个系统都使用普通电脑，出于负载考虑，它们推荐相同的数目Tablet/Region大小100-200MB256MB在两个系统中，单个Region大小是可配置的，在HBase中，默认大小为256MBRoot位置1stMETA/Chubby-ROOT-/ZooKeeperHBase会使用一个只有单个Region的自身表来存储Root表。二者启动时都会把Rootregion所在机器的地址放到ZooKeeper或者Chubby中。客户端Region信息缓存支持不支持二者客户端都支持Region位置信息缓存并且有相应的机制去除过时的缓存和更新缓存Meta预读支持不支持（？）BigTable的一个设计就是会预读超过1个MetaRegion信息并将之放入客户端缓存。Region事件记录支持支持Region相关事件（切分，分配，再分配）都会记录在Meta表中存储位置分组（LocalityGroups）支持不支持这不是很确定，但是看起来BigTable中的任何东西都有个位置分组的属相。如果多个列族的位置分组相同，那么它们将被存放在一起，并且拥有相同的配置参数。单个列族就可能是一个拥有一个成员的位置分组。HBase不支持这种选项，并将不同的列族分开存储。完全内存ColumnFamily存储支持支持这是为需要高速存取小表准备的KeyValue缓存支持不支持缓存热点Cell数据数据块缓存支持支持数据块从存储文件读入到在可配置的缓存中布隆过滤器(BloomFilters)支持支持这些过滤器会消耗一些内存，但是可以快速检查一个指定的cell是否在一个RegionServer上存在Write-AheadLog(WAL)支持支持每个RegionServer都会记录被它管理的所有Region上的数据改动SecondaryLog支持不支持出于性能考虑，一旦WAL性能下降，BigTable还有别的log可以使用忽略Write-AheadLog？支持在大量数据导入时，HBase的客户端可以选择忽略WAL快速Region切分支持支持切分region是快速的，因为切分出来的子region暂时还会去读取原存储文件直到一个compaction将数据写入region的自有的存储文件BigTable新特性OSDI’06BigTable论文发表已有几年，BigTable当然也有改进。杰夫.迪恩—一个在Google的家伙在近来的一些演讲和演示中提到了BigTable的新特性。我们就来瞧瞧部分新特性吧。特性BigTableHBase说明客户端隔离支持不支持BigTable可以内在地被用来服务很多单独的客户端，并且使它们的数据隔离不互相影响协同处理（Coprocessors）支持暂不支持BigTable在region中运行的代码可以随着region的被切分，代码也被会切分到新的region上运行。数据错误安全支持不支持BigTable使用CRC校验码确认数据是否被安全写入。HBase没有这个特性，问题是：Hadoop是否会包含这个特性？数据中心间数据复制支持暂不支持HBase的一个issue：HBASE-1295就是关于这个特性的。变化和差异上面讨论的一些特性比较可以看出有些特性差异并不是可以简单归结为”是或否”类的问题，对这类问题我将在下面单独探讨。锁服务下面的来自BigTable论文BigTable用Chubby来完成一些不同的任务：保证在任何时候只有一个活动的Master；存储BigTable引导区地址；发现tabletserver以及在tableserver死亡时做善后工作；存储BigTable的schema信息（每个表的列族信息）；存储访问控制列表。如果Chubby在一段较长的时候变得不可用，那么BigTable系统就会变得不可用。BigTable如何使用Chubby跟HBase如何使用ZooKeeper有很多异曲同工之处。但有一个区别就是：HBase并不把Schema信息存储在ZooKeeper中。它们都非常依赖锁服务的正常运作。根据我自身的经验以及我阅读HBase邮件列表所得到的，我们经常低估当ZooKeeper无法取得足够的资源去作出实时回应时的后果。宁可让ZooKeeper集群运行在相对较老旧的但是什么别的事都不干的机器上，而不是运行在已被Hadoop或者HBase进程搞得不堪重负的机器上。一旦你的ZooKeeper没有足够的资源提供服务，就会引发多米诺骨式的效应，HBase将会挂掉—包括master节点。更新：在跟ZooKeeper开发小组讨论后，我想指出的是这并不真正意义上是ZooKeeper的一个问题。因为如果运行ZooKeeper的机器负荷很重，那么存取ZooKeeper上的资源很可能会超时。在这种情形下，HBase的RegionServer甚至Master可能会认为协调服务已经坏了，它们就会让自己停工关闭。帕特里克.亨特已经通过邮件和发帖对此作出回应。你可以读他的邮件或者帖子，然后检查自己的ZooKeeper是否有能力处理负荷。我个人建议是将ZooKeeper集群跟HBase集群分开。你可以把ZooKeeper集群运行在一组空闲的稍微有点过时但是性能还相当不错的机器上。这样你可以单独监控ZooKeeper集群和HBase集群中的机器，而不必有以下的烦恼：当一个机器的CPU负荷100%的时候，你搞不清楚这个负荷究竟来自哪个进程或者有什么后果。另外一个重要区别是：ZooKeeper并不是一个像Chubby一样的锁服务系统，但是目前为止，这并不是HBase所关心的。ZooKeeer提供一个分布式的协调服务，让HBase可以选举出Master节点。它也可以提供用以表示状态或者某个动作需要的信号量。当Chubby生成一个锁文件来表示一个tablet活动的，与此相对应的一个Regionserver会在ZooKeeper中生成一个节点来表示自己的存在。这个节点创建以后，只要ZooKeeper不挂，它会一直存在。在BigTable中，当一个tabletserver的锁文件被删除时就表示与这个tabletserver的租约失效。在HBase中，因为ZooKeeper相对少点限制的架构，这种行为会被处理得有所不同。它们只是语义上有所差别，并不意味着谁优谁劣，仅仅有所不同而已。在Chubby中，第一层级的文件包含着根tablet的位置