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。这需要坚如磐石的可靠性和持续不断的性能提升才能达到。这个目标应该能让团队忙好一阵子了。