HBase既提供了可伸缩性，又提供了共享与Hadoop相同的基础设施的经济性,但它的缺陷是否把后腿扯下来了呢? NoSQL专家摆好了辩论架式。

HBase是仿照谷歌BigTable的，是世界上最受欢迎的大数据处理平台Apache Hadoop的一部分。但这一血统能否担保HBase在充满竞争和快速发展的NoSQL数据库市场中定会担当一个主导的角色呢?

MapR公司的Michael Hausenblas 认为Hadoop的受欢迎程度与HBase的可伸缩性和一致性可确保成功。日益增长的HBase社区将超过其他开源运动,并会克服一些还需进一步研究的技术问题。

在开源项目Cassandra的幕后支持供应商DataStax工作的Jonathan Ellis认为HBase需要克服的缺陷太多，而且内含于Hadoop的HDFS架构。他说这些缺陷将永远限制HBase适用于高速工作负载的项目。

请阅读我们的两个NoSQL专家不同的意见,然后在下面评论部分用你的意见参加辩论。

正方

Michael Hausenblas

EMEA,MapR技术公司的首席数据工程师

与Hadoop整合将推动被接受

 

这个问题的答案是一个清澈的“是的,但是…”

为了领会这个回答,我们需要退后一步,从语境上理解问题。Martin Fowler在2011年和Mike Stonebraker在2005年都拿着“通晓多种语言的持久化”认为“一种尺寸不能适用于一切”。

因此,我要解释问题中的“主导”不是在过去十年里应用于关系数据库的市场份额措施意义上的,而是沿着“Apache HBase是否会被使用在更广泛的情况中和有一个比其他NoSQL数据库更大的社区的支持?”的主线来讨论(有点狡辩的意味)。

考虑到现在有超过 100 个不同的NoSQL方案可供选择，包括MongoDB, Riak, Couchbase, Cassandra 和许多许多其它方案，上面的观点可以说是一个大胆的推断。但是在大数据时代，潮流正从专业的信息存储转向大规模的异构数据处理，所以即使像MongoDB这样的流行方案也会被HBase赶超。

为什么? MongoDB有着显而易见的可扩展性方面的问题，随着Hadoop使用率的快速增长，能直接和Hadoop整合的NoSQL方案将会在规模和流行度上有明显的优势。HBase拥有一个庞大而多样的社区，它连接着各个方面: 用户，开发者，多个商业销售商，云端可用性等等，比如最后一点是通过 Amazon Web Services (AWS)实现的。

在发展历史上，HBase和Cassandra有许多相似之处。HBase 由Powerset公司创建于2007年(该公司不久被Microsoft收购)，一开始它是Hadoop的一部分随后成为一个顶级项目。Cassandra最早由Facebook在2007年发起，是开源的，随后成为Apache的孵化项目，目前已经成为一个顶级项目。HBase和Cassandra都是多列的key-value数据存储库，擅长于接受和提供大数据集，同时具有横向可扩展性，鲁棒性和灵活性。

它们的架构在设计哲学上是有差异的: Cassandra从Amazon’s DynamoDB系统中借用了许多设计元素，有一个最终一致性的模型并且优化了写操作，而HBase是Google BigTable的克隆版， 优化了读操作并且有强一致性。关于HBase优越性的一个有趣的证据论点是， 作为Cassandra创建者的Facebook，已经在其内部使用HBase替代了Cassandra。

从一个应用开发者的角度来看，HBase更好，因为它提供了强一致性，让生活变得更容易。关于最终一致性的一个错误理解是它提高了写入速度: 假如有一个持续的写操作的阻塞，影响了等待时间，而最后的结果是交了”最终一致性税”却没有得到它的好处。

几乎所有的NoSQL方案都有一些技术上的限制，比如压缩对低延时性的影响，无法自动碎片化，可靠性问题，以及节点宕机时的长恢复周期等。在MapR这里，我们已经创建了一个”未来版”企业级HBase，它包括瞬时恢复，无缝碎片化和高可用性，并且它摒弃了压缩。2013年5月我们把它纳入到了标记为M7的GA版本中，同时通过AWS Elastic MapReduce，它也在云端可用。

最后同样重要的是，HBase拥有 — 通过作为Hadoop的贡献项目而得到的遗产 — 一个强大而可靠的整合进整个Hadoop生态系统的方式，包括Apache Hive和Apache Pig。

概括起来讲，在那些需要进行快速的小规模的更新和大规模的查询的用例场景中，HBase 将会成为统治性的NoSQL平台。最近的改进也给HBase带来了架构上的优势，包括消除了压缩并且提供了真正的分散协作。

Michael Hausenblas 是MapR Technologies公司EMEA大区的首席数据工程师。他的工作背景是大规模数据集成的研究和开发，倡导和标准化。

反方

Jonathan Ellis

联合创始人 & CTO,

DataStax

HBase 受到太多缺点的困扰

NoSQL包括了几个特性，比如图形数据库和文档存储，这些都是HBase不具备的，而且即使在它所属的分区行存储这一类型中，HBase也落后于领跑者。技术上的缺陷可以把HBase的失败使用案例分为两个主要类型: 一是工程问题，如果时间和人力充足，该问题可以处理，二是架构上的缺陷，这是设计层面固有的问题所以无法修复。

工程问题

–操作复杂，且容易发生故障。HBase的部署需要配置的文件包括：最小Zookeeper集群，一级HMaster,二级 HMaster,RegionServers，活动NameNode，备用NameNode，HDFS管理，还有DataNodes。尽管HBase可以被自动安装，但是要是没有帮助就想成功安装太难了，比如说RegionServers出现故障或者一个低级别NameNode出现故障了怎么 办?HBase使用需要足够多的专业知识甚至需要知道要监视什么。只用上帝才能帮助你进行定期备份吧。

–RegionServer故障转移需要花费10到15分钟的时间，HBase将分区形成区域，每个区域由RegionServer来进行管理。 RegionServer对于其管理的区域来说只允许单次故障。当它发生故障时，就必须选择一个新的区域服务器，而且在新服务器工作之前还得必须重新写入之前服务器的日志。

— 用HBase进行开发很痛苦。HBase的 API很笨拙而且是以Java为中心的。非Java客户端被降级到第二级别的Thrift或REST入口。与此相对的是Cassandra 查询语言，它提供给开发者一个在所有语言中都熟悉的、富有成效开发体验。

— HBase社区是一盘散沙。Apache的主线不稳定是广为人知的。Cloudera, Hortonworks,和高级用户们都在顶层维护着他们自己的补丁树。领导权被拆分开了而且没有清晰的发展路线图。相反的，开源的Cassandra社区的贡献者来自包括DataStax、Netflix、Spotify、Blue Mountain Capital和其他组织，并且没有派系或分支。

总体上，自从我关注NoSQL生态圈以来，HBase和其它NoSQL平台在工程上的差距已经变大了。在我第一次评估他们的时候，我就已经认定HBase在工程进度上落后于Cassandra6个月，但是今天这种落后已经扩大到2年左右。

架构上的缺陷

–面向Master的设计使得HBase的操作很不灵活。通过RegionServer master来路由所有的读和写意味着HBase不可能在多个数据中心之间进行主动/主动结构的异步复制，还意味着你不能把工作负载分给一个集群上的各个复制者。相比之下，Cassandra的P2P复制允许在没有ETL的情况下无缝地集成Hadoop,Solar和Cassandra，而且在你需要极少出现的线性一致性的情况下还允许你进行 轻量级事务处理。

–故障转移意味着停机。许多应用无法接受甚至一分钟的停机时间，然而这是HBase设计固有的问题;每一个RegionServer都是一个单节点故障。而完全分布式设计意味着一个复制者停机，不需要任何特殊的动作就可以恢复;系统仍然与其他复制者一起正常的运转，而且在以后可以把停机的复制者纳入进来。

— HDFS是主要为了以流的形式访问大文件而设计的。HBase建立在为批量分析而优化的分布式文件系统之上。这是HBase 低性能的直接原因，尤其对于读取，而且 在固态硬盘上读取更是如此。就像关系型数据库不能优化30年前为准大数据工作负载而设计的B树引擎一样，HDFS也不能在主要目的和缩小关键功能上的差距之间不做权衡：

–在一个集群里混合一般硬盘和固态硬盘，并把表固定在适合工作负载的介质上。

–快照、增量备份和时间点恢复。

–压缩流量以避免应用响应时间的峰值。

–动态地路由请求到性能最佳的复制者上。

让HBase的基础HDFS更适合于批量分析那样的设计将确保HBase仍天然地不适合于高速、随机访问的工作负载，而这些正是NoSQL市场所独有的。

Jonathan Ellis是DataStax的CTO和联合创始人，在DataStax他固定了技术方向并以项目领导人的身份领导着Apache Cassandra项目。