大数据的辩论:HBase 将主导 NoSQL 吗?

日期: 2013-08-12 作者:Doug Henschen翻译:oschina 来源:TechTarget中国 英文

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项目。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

翻译

oschina
oschina

相关推荐