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

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