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