分布式系统, 转载

HBase的领导人探讨Hadoop、BigTable和分布式数据库(zz)

2010年1月4日 阅读(361)

http://www.programbbs.com/doc/3325.htm
Google最近关于Google Application Engin的介绍再一次引起了大家对备选数据库技术的兴趣。几星期前InfoQ访谈Hypertable项目的创始人之一Doug Judd,该项目受到了Google的BigTable数据库的启发。本周InfoQ很乐意给大家奉献对HBase领导人——im Kellerman、Michael Stack和Bryan Duxbury的专访。HBase是一个开源的、分布式的、仿效BigTable的面向列存储系统。

1. 对于第一次听说HBase的人,你准备怎么描述它?

HBase是一个开源的、分布式的、面向列的存储系统,该技术来源于Chang et al所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。就像Bigtable利用了Googl文件系统(File System)所提供的分布式数据存储一样,HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop 项目的子项目。

HBase项目是为那些Oracle年许可费够得上一个小国家的国民生产总值(GNP)或由于其库表中有一些BLOB列且行数达到了数百万级因而导致MySQL濒临崩溃的用户提供的。任何拥有大量的结构化或半结构化数据、而且正受限于关系数据库管理系统(RDBMS)的用户都可以看看HBase。参与到该项目中就更好了。我们不是要达到自己卑微的目的——将大量版本表元、数十亿行乘数百万列的数据放置于“商业(commodity)”服务器集群之上——没有广大的用户、支持者和捐助者的支持,我们的项目是不长久的。

2. 为什么要启动该项目?

Jim和Stack工作的地方Powerset,需要一个类似Bigtable的数据存储系统来保存他们的Web表格 (webtable),一个存放Web文档及其以URL作为关键字的属性的宽泛的表。 当需要一个类似Bigtable的数据存储系统来存放大量的profile以及其他类型的数据时,Bryan的老板Rapleaf也加入到了这个项目中。

3. 它与Hypertable相比如何?

无疑,这两个项目的出发点都是解答同一问题的——开源的Bigtable。Hypertable是C++语言编写的,而HBase是用Java语言编写的。HBase参与开放开发的时间更长、提交者及外部捐助者的数量更多。

与Hypertable比较起来,选择Java使我们可以和Hadoop集成得更加紧密——当我们使用了HDFS,就不需要另启动一个进程担任Java和C++之间的代理了,也不需要跨过JNI“分水岭(great divide)”。而且,因为我们使用Java,我们就有了后援,因为相当一部分核心类型和功能已经由Hadoop核心项目的“Smart Folks”社区编写和测试过了。

Hypertable项目非常关注“性能”而且强烈感觉只有C++能解决这一问题。有趣的是,据我所知,Hadoop开发的大部分工作是由Yahoo的一个团队做的,他们过去由于与Hypertable所说一样的原因而使用C++,据说现在已经回到了Java MapReduce框架。很明显,Hadoop团队已经克服了这一问题;在Java存在性能问题的地方,他们采取了适当校正,而性能上并无大碍的部分,继续以前的方式。例如,Hadoop/HBase使用本地类库来进行压缩,因为Java在这方面性能非常差。

围绕性能问题HBase确实需要做大量工作——上面提到的核心类型及RPC传输都需要彻底改造以更适合HBase使用模式 ——但是现在我们把精力放在别处。我们将追随Hadoop项目所采取的路线,首先把精力集中在健壮性、扩展性、正确性以及社区建立上。之后,我们再提高速 度。当时机成熟时,我们将会在速度方面把HBase和Hypertable进行全方位比较。

和体育比赛不同, Hypertable的伙计们是我们的同伴。我们在公平规则基础上进行对话并互相帮助。

4. 对于Google App Engine公布BigTable,你们怎么想?

看到Google在这方面步亚马逊之后尘很有意思,由其是Google的系统是Hadoop和Amazon正在从事的所有概念的“参考”实现。然而,正如App Engine宣布以来许多人已经注意到的,拥有自己的基础架构与租用它这两种方式有很大的不同。在规模很小的时候,这可能是非常好的一件事情,但是一旦达到了下限阈值,你最好自己来搭建一个基础架构。

但是禁闭(lock-in)问题又来了:一旦你的应用变得流行起来,当你试图将你的应用从App Engine上迁移出来的时候,即便拥有自己的硬件颇具经济意义,你也无法拥有平台(你的系统构建于其上)的所有软件。从很多方面来讲,这看起来是LAMP优点的退步。

这就是说,就算出现了不利于HBase以及用于解析GQL等等一个Google App Engine DataStore API的实现,我们也不能对这一产品说不。

5. M/R范式对于批处理数据应用得很好。在更多的基于事务/单一请求的范式下,Hadoop应用得如何?

MapReduce(不论是Google的还是Hadoop的)是用于处理不适合传统数据库的海量数据的理想技术。但它又不适合事务/单一请求处理。而HBase使用了来自Hadoop核心的HDFS,在其常用操作中并没有使用MapReduce。

但是,HBase支持高效随机存取,因此它可以被用于你的业务的一些事务性元素。你获取一行的性能可能会低于其他方式(比如说MySQL),但是当你的事务吞吐量增加时你得到了很好的伸缩性。但是你也可以吃到自己的蛋糕,因为HBase获得了来自IBM研究院院一群人的一些非常好的捐赠,可以很容易将HBase作为MapReduce的源及目的来使用,因此,你基于数据的HBase也可以分享MapReduce的批处理操作。

6. 使用Hadoop,你们所发现的最好的东西是什么?

作为Hadoop的一个子项目,就像是装上了双引擎。最大的推动力是我们可以借用Hadoop的核心开发者。而且,作为 Hadoop社区的一部分,已经把用户吸引到了HBase上来了。我们利用了Hadoop中已经完成的大量工作——HBase的许多代码是重用 Hadoop的代码。我们也被公布于Hadoop社区,从中获取反馈,这对我们来说是好处是巨大的。

第二个推动力是,我们是Apache的一部分。Apache界有许多已经开发好的程序和基础架构,我们可以直接使用而无需自己开发。

7. 最坏的东西又是什么?

我们只往好处看(笑)。如果非要说点什么……

在许多方面,Hadoop的HDFS和MapReduce开发完全是一回事,因此有时很难让核心开发者理解我们使用HDFS的区别;比如,MapReduce通常不能随即读取,而HBase必须能够做到这一点。

而且在HDFS中缺少append操作(参见HADOOP-1700)。没有这个操作,HBase可能会在服务器崩溃时丢失数据。看起来我们很可能在Hadoop 0.18.0中获得这一特性。

8. 哪些公司正在使用HBase?

Powerset和Rapleaf首当其冲。我们所知的积极使用HBase承载大量数据集的公司包括WorldLingo和Wikia,许多其他的公司正初步涉足HBase。如果还有其他公司对使用HBase感兴趣,就告诉我们吧!

9. HBase未来是如何规划的?

在不久的将来,我们将稳定我们的0.1分支。大约在下周,我们将发布0.1.2。我们知道稳定的供应是发展用户基础和捐助者的关键方法。另外,在5月份我们的下一个重大发布——0.2中,你将看到对健壮性、大量更好的集群自管理特性如区域再平衡、及客户端API方面有很大的改进。

查看英文原文:HBase Leads Discuss Hadoop, BigTable and Distributed Databases

You Might Also Like