Apache HBase
英文原文：
Why we’re using HBase: Part 2
本文的第一部分讲述了我们成功地应用了我们所选的技术方案。下面将给出更多的依据（并不是所有依据 :P），表明为什么我们认为HBase才是最适合我们团队的方案。我们试图对我们的整个思路进行详细解释，这样的话，别人在选择技术方案时，至少也可以 问 出我们所问过的同样的问题，即使他们最终选择的技术方案和我们的并不相同。
我们的工作方式
一般我们是在主干代码（trunk code）(包括Hadoop和HBase)的基础上进行开发，开发中使用的是Apache Git代码库的一个镜像。我们使用的代码并不仅仅局限于发布版，因为我们要实现修补（fixes），总会有一些新的特性我们需要或者想要对其进行评估。我们会在大量各种不同的情况下进行测试从而会发现各种各样的问题，发现的问题包括从HBase或者HDFS出状况到数据丢失等等情况。通常我们会将问题汇报到这里并对问题进行修复，然后接着再使用系统。最近令我们颇为头疼的问题就是由于使用非发布版的HDFS-909造成的，该版本会造成NameNode的“edits”文件损毁，该文件丢失了一个字节的数据。我们对系统了熟于胸，为了让集群迅速恢复上线，便在十六进制编辑器中手动修复了该“edits”二进制文件，随后才通过分析代码定位到造成此问题的根本原因所做。这本书不是个那么严重情况，但这种“训练”和对代码深刻的熟悉程度使得我们可以在一定程度上相信，我们具有处理现实中各种情况的能力。
然而，现如今要找到比较关键的bug变得越来越难了，能意识到这一点非常好。我们仍在不到虐待我们的集群，在涉及数据完整性方面我们会采取所有可能的预防措施1。
对分布式系统进行测试是很困难的。现成的工具和资源并不多。多亏Yahoo!，他们说是要弄些性能和可扩展性方面的基准测试工具（我们也在等待YCSB工具的开源），但现在我们不得不自己动手，目前尚需一些时日才能完成。分布式系统还没有清晰的测试方案，也没有故障切换基准测试工具，更没有可靠性、、可用性或数据一致性方面的测试工具。
无论你自己认为你作的测试是多么的全面，系统总会出现某些故障。即使户外阳光普照，你正在举办一个盛大的聚会（特别是这种时刻），系统也会出问题。Google、Twitter、Amazon —— 统统都经历过故障停机时间。 大家都会偶尔出点故障，这只是个时间问题。用户往往会认为短时间的宕机和性能下降还是可以忍受的。但是，用户绝不能容忍的是数据的丢失2。我们在防止数据丢失方面，是绝对的偏执狂。如果说造成性能下降或者甚至是短时间的宕机的故障情况是可以忍受的话，丢失数据可不是。
我们尽力用心学习我们的系统，从而能够即使在系统还在运行的同时就可以快速修复发现的问题。经过了一年多的运营，我们在为我们的客户保存数据方面做的还不错3，但我们仍然没有掉以轻心，还在做着各种测试。
真正全面地对我们使用的所有解决方案进行测试收效颇丰。测试涉及的工作量很大，因为我们不得不构建测试框架（scaffolding），但是，反反复复随着变化而变化并且提交修复的确是深入了解该系统的一条必经之路。
解密HBase的数据完整性、可用性（Availability）和性能
能够了解到一个系统有什么长处是非常好的，但更重要的是要能够意识到并理解系统还有什么局限。我们大量地编写了这两方面的测试套件。性能测试非常简单易行，而对数据完整性进行测试才是最难的，我们绝大部分的时间花在了这方面。
数据完整性
完整性意味着在对客户端的请求进行确认之前，数据必须达到“安全的状态”，无论此后可能会发生什么样的硬件故障。
HBase在预写日志（write-ahead log）抵达3个4内存中的（in-memory）HDFS副本（replica）5后才会对写请求进行有效性确认。从统计学意义上讲，同时失去3台机器的概率非常之小6（除非你的所有背板接的是同一个电源线、电源开关、PDU或者UPS上）。HDFS是具有背板意识的系统，它会将你的副本安排到不同的背板之上。如果你将机器放置到合适的位置，接驳适当的电源，多数情况下这么做是安全的。如果我们的客户在某些特定的关键应用中要求的更加严格，我们会给出更严格的保证。（例如，可以确保在所有的3个副本中都将刷新到磁盘中——今天不在这里讨论此问题）。
即使你真的将数据更新到磁盘，仍然还会有许多问题。在所有电源都掉了的情况下，即使你将数据刷新到了磁盘，你还需要考虑OS的缓存、文件系统日志（file system journaling）、RAID缓存甚至还有磁盘缓存。所以说，即使将数据刷新到磁盘，也很难说数据就安全了。我们采用了有后备电池的写缓存RAID卡，其中禁止了磁盘缓存。然而，我们更愿意确保背板接驳的电源是正确的，也不愿意依赖磁盘刷新。
我们开发方面的经历绝大多数放到了保证数据完整性方面。我们设立了绝对苛刻的故障切换预案。在让我们的客户写入任何一个字节的数据之前，我们都要努力保证每个字节的数据都要在各种故障面前是安全的，我们致力于在HBase或HDFS中修复任何可能造成数据损坏或丢失的bug。
可用性（Availability）
我们对可用性具有同样的感觉。当一台机器不幸遇难后，由该机器负责的数据会在一个较短的时间窗内7处于不可用状态。这是目前状态下的一个系统局限，我们知道在丢失一两台机器的情况下，如何确保系统100%可用，但这只是先将我们的精力投入到哪个方面的问题，我们只是故意还没这个问题上投入精力而已。现实情况是，我们可以忍受某些数据分区具有较短的8 宕机时间 —— 只要我们不会搞丢数据就行。我们也会预期，机器故障发生的频率不要太高。
所以，对我们来讲，在数据一致性、可用性和分区容错方面玩各种花样同确保数据安全方面相比，并没有那么重要。
随机读取
HBase9的性能对我们来讲可以说够好了。换言之，目前它所提供的性能远比我们需要的还好很多。如果无法确保数据的安全，你会铆足劲将读取操作的性能从10毫秒提高到5毫秒，或者将一个服务器宕机后的几分钟的不可用时间缩短到最多1秒吗？我们不会。这正象你在刷卡时偶尔刷不成功一次，但你任何时候都绝不会接受发生把账户刷丢了的情况。因此，我们选择了将我们的资源花在了确保数据完整性方面。
在当前架构下，对于少量的记录，接近7ms的评价磁盘响应时间10,是可能实现的。一如既往，魔鬼出在实现细节方面。整体架构可以保证线性的可扩充性，但是，实现细节才能保证系统的可靠性。而且，我们都知道，在最糟糕的情况下，数据访问并不呈均匀随机分布。目前对于内存中数据，读取时间大约是1ms左右，读取操作的性能和吞吐量可以通过添加缓存得到10倍的提高（请参见此文)。
我们在性能方面的测试结果比YCSB测试报告中所说的情况要好得多。但这需要令文详述。
可用性和随机读取性能可能是我们现在可以接受的两个“局限”（对目前来讲）；然而，在数以亿计记录的随机写入（random write）和顺序读取方面的性能，我们相当的满意11。
写入操作
尽管在读取操作方面可以通过添加缓存提高性能，要在写入操作方面提供相当的可扩充性就比较难了。写入操作和顺序读取这两方面的比较好的性能使得两种比较重要的用法成为现实：大批量数据的一次性写入12和高效的分布式数据处理。
HBase 具有非常好的随机写入性能。在我们使用的 HBase 0.21 中，每次 RegionServer 的 put 调用后都会同步预写日志，从而保证数据在至少 3 个节点的写缓冲区中。比如在一个关系数据库管理系统（RDBMS）中，可以通过复制数据来提高读性能，但是却无法同比例的扩大写性能和总数据量，除非做数据划分。而数据划分会丢失一些原有的特性，如事务性和一致性等，还会让你的运营成本飞涨。
当系统成熟后，良好的写入性能不会是只有 HBase 才具有的优势，我们希望别的存储系统也达到这样的性能，就像我们希望 HBase 能够达到良好的随机读性能一样。
但是，如果无法处理大规模的数据的话，把它们存下来又能有什么用呢？
顺序读取(扫描)
此外，我们测试使用MapReduce时发现它的性能非常好。HBase构建于Bigtable架构之上，而Bigtable是设想用于MapReduce的，这个解决方案完全适用于OLAP。数据的存储位置具有确定性，一行行数据都是按顺序存储到磁盘中的。在这种数据中不存在碎片，所以，HBase中一个单个的数据读取请求就能够读取表中256M的数据（可以对此大小进行配置）。因此，只要有足够高的数据处理能力，你尽可以在每次磁盘读取操作时都开足马力读取足够的数据。
完全一致性
HBase本来就属于具有一致性的系统。在你写入数据后，所做的修改马上就能得到反映。你读到的数据绝不会是陈旧的数据，关于这一点你可以思考一下仲裁式读取操作（quorum read）的原理。有几个层面的原因让我们认为，一致性是一个非常好的特性：如果是基于具有一致性的系统之上编写应用程序，那么应用程序的逻辑就要简单多了。编程时完全无需考虑陈旧数据的问题，就像是进行单线程编程：你可以放心去读取你早先写入的数据14。还有，一致性是建立更加复杂的数据操作原语（primitive）的坚实基础：事务和索引、增量式运算、先检测后设置的语义结构（test-and-set semantics）等等。
本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。
2KB翻译工作遵照
CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
