Hypertable 项目领导者谈 Hadoop 和分布式数据库

数据库领域近来吸引了不少眼球。IBM不久前投资于 EnerpriseDB ；EnerpriseDB 有一个运行在 Amazon EC2 上的云版本。Amazon 去年末发布了他们自己的云数据库。而 Google 的 BigTable 尽管并不开源，也得到了社区的广泛研究。同样是在这个领域，两个开源项目—— HBase 和 Hypertable 利用开源 Map/Reduce 平台 Hadoop 提供了类似于 BigTable 的可伸缩数据库实现。InfoQ 与 Zvents, Inc 的理论研究架构师以及 Hypertable 项目的创立者 Doug Judd 一起讨论其实现。

1、你如何向第一次听说 Hypertable 的人形容这个数据库？

Hypertable 是一个开源、高性能、可伸缩的数据库，它采用与 Google 的 Bigtable 相似的模型。在过去数年中，Google 为在 PC 集群上运行的可伸缩计算基础设施设计建造了三个关键部分。第一个关键的基础设施是 Google File System（GFS），这是一个高可用的文件系统，提供了一个全局的命名空间。它通过跨机器（和跨机架）的文件数据复制来达到高可用性，并因此免受传统文件存储系统无法避免的许多失败的影响，比如电源、内存和网络端口等失败。第二个基础设施是名为 Map-Reduce 的计算框架，它与 GFS 紧密协作，帮助处理收集到的海量数据。第三个基础设施是 Bigtable，它是传统数据库的替代。Bigtable 让你可以通过一些主键来组织海量数据，并实现高效的查询。Hypertable 是 Bigtable 的一个开源实现，并且根据我们的想法进行了一些改进。

如果你运行一个高流量的网站，那么就应该关心可伸缩的计算基础设施。网站服务器的日志包含了与用户行为相关的有价值的信息。你可以分析这些日志数据，并根据分析的结果提供更好的服务。它让你可以回答这样一些问题：“如果客户购买产品 X，他们还可能购买什么？”，“如果用户到达页面 Y，那么在他们关闭会话之前平均会进行多少次点击？”

2、为什么 Hypertable 团队要开始这样一个项目？

Zvents 的工程团队启动这个项目是因为我们认识到数据以及数据驱动工程的价值。我们认识到在高伸缩的条件下，传统的存储和信息处理工具力不从心。在我们启动项目的时候，还不存在 Bigtable 的开源实现，于是我们决定自己来建造那么一个数据库。我们选择开源的理由是我们觉得注定会出现一个 Bigtable 的开源实现。通过领导这方面的开发工作，我们可以在知识、专业技能和可靠性等方面促进竞争。

3、为什么 Hypertable 需要 Hadoop 才能运行？

不，Hypertable 并不一定要 Hadoop 才能运行。Hypertable 被设计成可以运行在现有的文件系统之上，比如 Hadoop 和 HDFS。面向底层文件系统的接口已经通过一种代理（broker）机制进行了抽象。Hypertable 通过标准的协议与一个 DFS 代理交谈，从而实现与底层文件系统的通信。我们使用的主要 DSF 代理是针对 HDFS 的代理，但我们也有针对 KFS（Kosmos File System）的代理。还有一个“本地代理（local brocker）”只读写本地挂接的文件系统。“本地代理”是我们用来测试的，但同样可以用来在任何可通过 FUSE 挂接的分布式文件系统上运行 Hypertable。至于 Hadoop 的其余部分，我们打算写一个 InputFormat 类，让 Hypertable 中的表可被用作 map-reduce 任务的输入。

4、Hypertable 相比 HBase 有何差异？为什么不直接贡献到 HBase 而要另起炉灶呢？

Hypertable 与 HBase 的差别是，Hypertable 是 Bigtable 的一个更高性能的实现（InfoQ 同样采访了HBase 的团队）。我开始的时候跟Jim Kellerman 以及Hadoop 团队的一些成员一起为HBase 工作。但我们对HBase 应该变成什么样子有不同意见，对实现语言的选择也有不同意见。他们坚持用Java，而我力推C++。于是我就分出来，开始了Hypertable 项目。下面的文档名为《为何选择C++ 而不选择Java》，里面解释了选用C++ 的技术原因。

http://code.google.com/p/hypertable/wiki/WhyWeChoseCppOverJava

虽然我们很早就与 HBase 项目分开，但两个团队仍然是很好的朋友。实际上我们上星期就一起出去吃午饭，同时还分享了很多实现中的情况和想法。

5、按照我对 Hadoop 的粗浅理解，M/R 范型很适合用来完成数据的批处理。那么 Hadoop 用在比较突出事务 / 单次请求的范型中又如何呢？

Map-Reduce 绝对是一个离线批处理系统。它很适合离线执行海量信息（如日志）的排序及筛选。这种大规模的离线计算经常会产生大量的信息供服务参考，以提供更好的用户体验。信息可能包括对每个用户的描述数据，又或者对每次请求的统计信息。这就是 Hypertable 发挥作用的地方，它提供了一种可伸缩的解决方案来存储经过主键索引的数据，并且可以在线查询。

6、你在使用 Hadoop 的过程中觉得哪一方面是最好的？

简而言之 Hadoop 运作得很好。我们在 Zvents 已经成功应用了 Hadoop，还有很多公司在离线作业中使用 Hadoop。Hadoop 团队也在下面的新闻稿中描述了他们的成就：

http://developer.yahoo.com/blogs/hadoop/2008/02/yahoo-worlds-largest-production-hadoop.html

7、最坏的方面呢？

我觉得 Hadoop 最坏的方面是这个项目已经存在了几年都还没有一个稳定的 1.0 版。有时候很难找到一个稳定的版本。不过最近 Hadoop 项目已经稳定了很多。Hadoop 还有一个问题，在它的分布式文件系统中缺乏对“sync”操作的支持，因此不适合用来保存提交日志。他们已经在积极解决这个问题，在我们发布 Hypertable 1.0 版的时候应该就会实现了。

8、1.0 版预计在什么时候发布？

我们会在一两个月之内发布一个 Beta 版，紧接着就是 1.0 版。如果想随时了解 Beta 版和 1.0 版的情况，请加入 Hypertable 的公告邮件列表： http://groups.google.com/group/hypertable-announce

9、有什么公司在用 Hypertable？

因为 Hypertable 还处在 alpha 阶段，所以还没有公司用 Hypertable 来构建服务。不过很多人都对 Hypertable 感兴趣，我们已经有超过 3000 次下载。很多人也通过邮件列表给了我们很好的建议。比如 Omaha, Nebraska 一家企业有个人向我们报告了一个回归错误。经过邮件列表上的一番往来，他干脆把机器放到公司防火墙的外面，然后给了我一个 VNC 帐号去调试这个问题。我最后终于找到了问题，程序在 PST 之外的时区运行时会发生时间戳的转换错误。还有一个来自纽约的 Stony Brook 大学的博士生，他用 Hypertable 重新完成了 Google 的 Bigtable 基准测试，而且得到了很好的结果。像这样的社区回馈给了项目极大的帮助。上周我们给 Facebook 的 30 来位工程师做了 Hypertable 的演讲。他们感觉确实需要在后端工具链中加入这种类型的基础设施，并决定在 Hypertable 接近完成的时候试用一两个月。我们很期待看到 Hypertable 发布 1.0 版的时候能出现一些真正的应用。

10、Hypertable 有何未来目标？

短期来说，我们把精力放在高可用性上，尤其是服务器恢复。完成之后经过测试，项目就会进入到 Beta 阶段，紧接着就是 1.0 版。我们希望 Hypertable 能在很多 Web Service 应用中取代 MySQL。我们希望把 LAMP 这个缩写变成 LAHP，显然 H 指的是 Hypertable。这需要坚如磐石的可靠性和持续不断的性能提升才能达到。这个目标应该能让团队忙好一阵子了。

查看英文原文： Hypertable Lead Discusses Hadoop and Distributed Databases