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 受到太多缺点的困扰
工程问题
--操作复杂，且容易发生故障。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项目。
英文原文：
阅读(621) | 评论(0) | 转发(0) |
