Apache HBase 英文原文：why-were-using-hbase-part-1/

我们的团队所构建的基础设施是为整个Adobe内大量的客户端提供服务的。我们所提供的服务囊括了从添加评注和标签到结构化数据的存储与处理。 我们需要确保数据是安全并且始终可用的；无论数据量有多大，服务的运行速度都必需很快才行。

本文介绍了我们是如何开始使用HBase的以及现在我们的情况如何。更多探讨其中缘由的细节可参见本文的第二部分

侥幸成功

如果在几天前有人问我，我们为什么选择了HBase以及我们是怎样做出这个选择的，我可能会顺嘴答到，这都是因为可靠性、性能、成本等等原因（不断“正确”以及“客观”地回答问题后感觉有点被洗脑了）。然而，随着这个话题（译者注：指的是NoSQL）最近越来越受到大家的关注¹，我们对“怎样”和“为什么”这两个问题进行了更深一步的反思。

其实事实是这样的。刚开始，我们对使用非常前沿的技术很有兴趣并且感觉也很好玩。激励我们往前走的正是我们渴望到达成功的彼岸。我们都知道Google文件系统、Bigtable、GMail以及它们之所以能够成功背后的故事。我觉得我们需要其中的某个部分，因此，采用Hadoop和HBase自然就成为了要达到此目的的第一步要做的事情。

开始的时候我们甚至连一个集群都没有。别的团队有一些利用率不太高的测试机，我通过给他们一些其它好处求他们把这些机器借给我们使用。我们使用这些机器的方式同SETI@Home类似。我们有了7台机器后，就搭起了一个运行 Hadoop和HBase栈(HStack³)的集群²。除了我们自己的笔记本，我们还继续翻新了一些旧的坏机器用作测试代理（test agent）。

对于以技术为导向的决策来说，如果从商业角度对它们进行评估，其成立的理由往往不太充分。我从来都不考虑成本、数据丢失等因素。我们总是假定不会出现那些方面的问题。如果有人能够成功运行这套系统，我们为什么会做不到呢？我们知道，这种体系结构具有可扩充性，但我们并没有对这个实施方案是否能够真正的运行起来提出任何质疑。

可扩充性和较好的性能把我们“引诱”了进来。但是，实际上，实施方案才是成本、一致性、可用性和性能的决定性因素。 比较好的和具有可扩展性的架构只是一个长期的约定，只有辅之以切实的实施过程才有可能实现。在下文中你会看到，在我们这个案子中我们所选的架构的确达到了预期的效果。

通过早期的各种实验，我们认清HBase所具有的潜力后，就对HBase进行了全面的分析。想得到一个客观的评价就要花一些时间，最终经过所有的各种测试，我们真的确信我们所做的一切很有意义。

以40M为标志

我们以前就对MySQL进行过可扩充性处理，因此，反规范化（denormalization）、数据分区和副本（data partitioning and replication）对我们来说不算是太新的概念。在2008年中期，我们有个客户要求我们提供一个服务，这个服务要能处理40M条记录，并提供实时的访问能力，而且还要在这些记录之上进行各种统计之类的分析操作。我们认为我们已经有了解决方案。这是我们迈向“大数据”处理的第一步。

那时还没有相关的基准测试报告⁴，也没有“NoSQL”这个称呼，所以那时也没有什么天花乱坠的宣传:)。我们不得不自己进行客观的评估。要进行评估的清单（非常幸运）不算长：HBase、Hypertable和Cassandra名列其中。MySQL列为备选，在别的方案都失败的情况下使用。

我们对实现细节进行了抽象处理，先编写了一个stub（客户端拿到它就可用开始进行开发了）。我们开始对每个技术栈（technology stack）进行测试。

首先出局的是Cassandra。那时它刚开发出来，只是勉强可用，缺乏像样的参考资料和有效的邮件列表，而且一个实例只能保存一张表。这些情况现在已经有了很大的改变，但当时我们有最后的期限不能等它。

很有意思的是，HBase是第二个出局的 :)。

当我们开始推入4千万条记录时，HBase⁵就不行了。插入20M条记录后，HBase就会彻底失败，要么失去响应，要么重启，数据也完全弄乱了，每次都得从头再来。 它的表现真糟糕，而且数据还丢了。

实际上有一个礼拜我都梦想着试图用日志找到其中的问题所在。貌似我们就要舍弃HBase了，但我坚持建议，即使我们先用着Hypertable，随后我们也应该能够换回HBase。虽然HyperTable能够非常好的处理好40M的数据，与之相比，HBase还不像是个可行的选择，但队友们还是同意了我的建议。

结果证明，HBase社团非常棒，它们跳出来对我们施以援手，对HBase进行了版本升级，修复了我们所碰到的问题。Hypertable⁶与之相比，表现更好一些。

故障预案

在对故障切换（failover）情况做测试时，HBase开始赶上来了，它能够非常优雅地处理故障节点并能保持一致性。Hypertable在节点出现故障后，要找回数据还有一些问题，而且需要手工干预。我们再次只有一个可选项使用了。

但是很有更多需要回答的问题，在我们使用MySQL从来不需要关心的问题也成了问题：

如何保证我们所保存的每一个字节的数据，无论发生什么情况，我们都能够将它们以完全相同的形式再次取回来？

我们需要能够探测出数据损坏的情况并对它们进行修复。我们的团队中有加密专家(它写了个水印攻击（watermarking attack）译者注：这个链接打不开，不知道这个家伙写的是文章还是ppt还是书啊程序神马的), 他设计了一个模型，可以用来在处理数据的同时使用CRC校验和对数据的一致性进行检查并支持版本化处理。精简序列化后的数据又进行了一层的封装，其中包含了内部数据的类型和HBase的位置（行、族和修饰符）。 （他有时有点偏执狂，但这种处理方式在不幸来临时非常好用 :)。其做法同Avro非常相似。

我们需要考虑的还有另外一种情况，就是HBase所依赖的Hadoop分布式文件系统(HDFS)完全失败后怎么办。

我们采用了一个过时的HBase导出工具来保证数据备份中和数据备份后的数据一致性。我们在3个地方保存3个备份：本地、HDFS和另外一个分布式文件系统。我们还将数据准备成了MySQL的格式，这是为了在出现灾难时，我们还可以切换到MySQL集群。我们编写了脚本，可以将最新的备份拿过来启动另外一个备选的存储集群（）HBase集群或者MySQL集群）。

这一切进行的都很顺利。我们创建了MapReduce作业，用以对我们所存储的数据计算出适当的建议。作为灾难恢复机制，我们制定了自动化的备份方案。

2008年10月份我们的系统按时上线了。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务