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

***的领导人探讨Hadoop、BigTable和分布式数据库

Google最近关于Google Application Engin的介绍再一次引起了大家对备选数据库技术的兴趣。几星期前InfoQ访谈Hypertable项目的创始人之一Doug Judd，该项目受到了Google的BigTable数据库的启发。本周InfoQ很乐意给大家奉献对***领导人——im Kellerman、Michael Stack和Bryan Duxbury的专访。***是一个开源的、分布式的、仿效BigTable的面向列存储系统。 1. 对于第一次听说***的人，你准备怎么描述它？***是一个开源的、分布式的、面向列的存储系统，该技术来源于Chang et al所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Googl文件系统（File System）所提供的分布式数据存储一样，***在Hadoop之上提供了类似于Bigtable的能力。***是Apache的Hadoop项目的子项目。***项目是为那些***年许可费够得上一个小国家的国民生产总值（GNP）或由于其库表中有一些BLOB列且 行数达到了数百万级因而导致MySQL濒临崩溃的用户提供的。任何拥有大量的结构化或半结构化数据、而且正受限于关系数据库管理系统（RDBMS）的用户 都可以看看***。参与到该项目中就更好了。我们不是要达到自己卑微的目的——将大量版本表元、数十亿行乘数百万列的数据放置于“商业 （commodity）”服务器集群之上——没有广大的用户、支持者和捐助者的支持，我们的项目是不长久的。2. 为什么要启动该项目？Jim和Stack工作的地方Powerset，需要一个类似Bigtable的数据存储系统来保存他们的Web表格 （webtable），一个存放Web文档及其以URL作为关键字的属性的宽泛的表。 当需要一个类似Bigtable的数据存储系统来存放大量的profile以及其他类型的数据时，Bryan的老板Rapleaf也加入到了这个项目中。3. 它与Hypertable相比如何？无疑，这两个项目的出发点都是解答同一问题的——开源的Bigtable。Hypertable是C++语言编写的，而***是用Java语言编写的。***参与开放开发的时间更长、提交者及外部捐助者的数量更多。与Hypertable比较起来，选择Java使我们可以和Hadoop集成得更加紧密——当我们使用了HDFS，就不需 要另启动一个进程担任Java和C++之间的代理了，也不需要跨过JNI“分水岭（great divide）”。而且，因为我们使用Java，我们就有了后援，因为相当一部分核心类型和功能已经由Hadoop核心项目的“Smart Folks”社区编写和测试过了。Hypertable项目非常关注“性能”而且强烈感觉只有C++能解决这一问题。有趣的是，据我所知，Hadoop开发 的大部分工作是由Yahoo的一个团队做的，他们过去由于与Hypertable所说一样的原因而使用C++，据说现在已经回到了Java MapReduce框架。很明显，Hadoop团队已经克服了这一问题；在Java存在性能问题的地方，他们采取了适当校正，而性能上并无大碍的部分，继 续以前的方式。例如，Hadoop/***使用本地类库来进行压缩，因为Java在这方面性能非常差。围绕性能问题***确实需要做大量工作——上面提到的核心类型及RPC传输都需要彻底改造以更适合***使用模式 ——但是现在我们把精力放在别处。我们将追随Hadoop项目所采取的路线，首先把精力集中在健壮性、扩展性、正确性以及社区建立上。之后，我们再提高速 度。当时机成熟时，我们将会在速度方面把***和Hypertable进行全方位比较。和体育比赛不同， Hypertable的伙计们是我们的同伴。我们在公平规则基础上进行对话并互相帮助。4. 对于Google App Engine公布BigTable，你们怎么想？看到Google在这方面步亚马逊之后尘很有意思，由其是Google的系统是Hadoop和Amazon正在从事的所有 概念的“参考”实现。然而，正如App Engine宣布以来许多人已经注意到的，拥有自己的基础架构与租用它这两种方式有很大的不同。在规模很小的时候，这可能是非常好的一件事情，但是一旦达 到了下限阈值，你最好自己来搭建一个基础架构。但是禁闭（lock-in）问题又来了：一旦你的应用变得流行起来，当你试图将你的应用从App Engine上迁移出来的时候，即便拥有自己的硬件颇具经济意义，你也无法拥有平台（你的系统构建于其上）的所有软件。从很多方面来讲，这看起来是LAMP优点的退步。这就是说，就算出现了不利于***以及用于解析GQL等等一个Google App Engine DataStore API的实现，我们也不能对这一产品说不。5. M/R范式对于批处理数据应用得很好。在更多的基于事务/单一请求的范式下，Hadoop应用得如何？MapReduce（不论是Google的还是Hadoop的）是用于处理不适合传统数据库的海量数据的理想技术。但它又不适合事务/单一请求处理。而***使用了来自Hadoop核心的HDFS，在其常用操作中并没有使用MapReduce。但是，***支持高效随机存取，因此它可以被用于你的业务的一些事务性元素。你获取一行的性能可能会低于其他方式（比 如说MySQL），但是当你的事务吞吐量增加时你得到了很好的伸缩性。但是你也可以吃到自己的蛋糕，因为***获得了来自IBM研究院院一群人的一些 非常好的捐赠，可以很容易将***作为MapReduce的源及目的来使用，因此，你基于数据的***也可以分享MapReduce的批处理操 作。6. 使用Hadoop，你们所发现的最好的东西是什么？作为Hadoop的一个子项目，就像是装上了双引擎。最大的推动力是我们可以借用Hadoop的核心开发者。而且，作为 Hadoop社区的一部分，已经把用户吸引到了***上来了。我们利用了Hadoop中已经完成的大量工作——***的许多代码是重用 Hadoop的代码。我们也被公布于Hadoop社区，从中获取反馈，这对我们来说是好处是巨大的。第二个推动力是，我们是Apache的一部分。Apache界有许多已经开发好的程序和基础架构，我们可以直接使用而无需自己开发。7. 最坏的东西又是什么？我们只往好处看（笑）。如果非要说点什么……在许多方面，Hadoop的HDFS和MapReduce开发完全是一回事，因此有时很难让核心开发者理解我们使用HDFS的区别；比如，MapReduce通常不能随即读取，而***必须能够做到这一点。而且在HDFS中缺少append操作（参见HADOOP-1700）。没有这个操作，***可能会在服务器崩溃时丢失数据。看起来我们很可能在Hadoop 0.18.0中获得这一特性。8. 哪些公司正在使用***？Powerset和Rapleaf首当其冲。我们所知的积极使用***承载大量数据集的公司包括WorldLingo和Wikia，许多其他的公司正初步涉足***。如果还有其他公司对使用***感兴趣，就告诉我们吧！9. ***未来是如何规划的？在不久的将来，我们将稳定我们的0.1分支。大约在下周，我们将发布0.1.2。我们知道稳定的供应是发展用户基础和捐助 者的关键方法。另外，在5月份我们的下一个重大发布——0.2中，你将看到对健壮性、大量更好的集群自管理特性如区域再平衡、及客户端API方面有很大的 改进。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。