大数据的辩论:HBase 将主导 NoSQL 吗? 已翻译 100%

oschina 投递于 2013/08/07 07:41 (共 11 段, 翻译完成于 08-10)
阅读 9784
收藏 64
4
加载中

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

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

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

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

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

赵亮-碧海情天
翻译于 2013/08/08 15:35
2

正方

 Michael Hausenblas
Michael Hausenblas
EMEA,MapR技术公司的首席数据工程师
与Hadoop整合将推动被接受



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

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

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

赵亮-碧海情天
翻译于 2013/08/08 15:59
1

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

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

lwei
翻译于 2013/08/07 11:36
1

在发展历史上,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。

lwei
翻译于 2013/08/07 14:53
2

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

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

lwei
翻译于 2013/08/07 15:37
2

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

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

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

lwei
翻译于 2013/08/07 16:08
1

反方

 Jonathan Ellis
Jonathan Ellis
联合创始人 & CTO,
DataStax
HBase 受到太多缺点的困扰


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

lwei
翻译于 2013/08/07 17:25
1

工程问题

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

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

bigtiger02
翻译于 2013/08/09 09:52
2

-- 用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年左右

lwei
翻译于 2013/08/09 14:56
1

架构上的缺陷

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

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

几点人
翻译于 2013/08/10 11:57
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(25)

n
newlife867
Michael Hausenblas 我听过此人的讲演,也和他聊过一聊,感觉他有水分。
站在MapR的立场上,他当然是狂定HBase的,
因为定制Hadoop 就是MapR的主营业务。

Hadoop,HBase的使用和维护,那是众所周知的麻烦。
所以才有MapR这类的公司存在。

不过嘛,开源的,大量被使用的,比较通用的大数据处理工具目前也基本只有 hadoop
萌龙
萌龙

引用来自“BreakJoa”的评论

引用来自“萌龙”的评论

引用来自“BreakJoa”的评论

引用来自“唐阳”的评论

引用来自“viney”的评论

riak无疑是我的最爱,其次是redis。

一个都不会

redis貌似只能单机器吧?

你确定你了解redis吗

不是很了解,只是知道这个东西,我这样理解不知道对不对,多机的主从机制,好像真正运行的只是一台redis的机器,如果要并发处理,貌似要自己写hash算法……是个人理解误区。

redis确实没有提供像hbase那么完善的分布式存储,但是你要知道,安装、维护hbase有多么的麻烦,一旦出现问题,就是运维人员的噩梦。redis就是设计成轻量级的,目前本身支持复制。再使用redis的连接池,读写分离,分布式存储什么的也都不是问题,关键是轻量级,维护起来方便的多。
梦远寄从无
梦远寄从无

引用来自“萌龙”的评论

引用来自“BreakJoa”的评论

引用来自“唐阳”的评论

引用来自“viney”的评论

riak无疑是我的最爱,其次是redis。

一个都不会

redis貌似只能单机器吧?

你确定你了解redis吗

不是很了解,只是知道这个东西,我这样理解不知道对不对,多机的主从机制,好像真正运行的只是一台redis的机器,如果要并发处理,貌似要自己写hash算法……是个人理解误区。
萌龙
萌龙

引用来自“BreakJoa”的评论

引用来自“唐阳”的评论

引用来自“viney”的评论

riak无疑是我的最爱,其次是redis。

一个都不会

redis貌似只能单机器吧?

你确定你了解redis吗
bewdx3
bewdx3
2013年8月了还有人为cassandra招魂的,面对互联网线上吞吐量级别的半结构化数据,hbase还就是唯一解了,虽然这个解不完美.
捧cassandra的赶紧部署上,我等着看下一篇xx为什么逃离cassandra.
Hansoul
Hansoul
架构缺陷是硬伤,hadoop同样如此。
jackerx
jackerx
工程复杂 确实是个问题 好想各个大公司搞HBase的都是华人 呵呵
架构上的缺陷 目前也正是HBase社区改进的方向
Hadoop 会专门对HBase作优化
外国用的不少 血统纯正 搭Hadoop的顺风车
梦远寄从无
梦远寄从无

引用来自“唐阳”的评论

引用来自“viney”的评论

riak无疑是我的最爱,其次是redis。

一个都不会

redis貌似只能单机器吧?
FeiFan
FeiFan
不看好
技术揣摩
技术揣摩
HBASE大数据处理听说很强,但复杂业务对待事务的支持一直都是NOSQL的硬伤,如果Hadoop十分流行的话,对于标配来说流行是应该的吧
返回顶部
顶部