专栏首页CSDN技术头条Hadoop、Spark、HBase与Redis的适用性讨论

Hadoop、Spark、HBase与Redis的适用性讨论

最近在网上又看到有关于Hadoop适用性的讨论[1]。想想今年大数据技术开始由互联网巨头走向中小互联网和传统行业,估计不少人都在考虑各种“纷繁复杂”的大数据技术的适用性的问题。这儿我就结合我这几年在Hadoop等大数据方向的工作经验,与大家讨论一下Hadoop、Spark、HBase及Redis等几个主流大数据技术的使用场景(首先声明一点,本文中所指的Hadoop,是很“狭义”的Hadoop,即在HDFS上直接跑MapReduce的技术,下同)。

我这几年实际研究和使用过大数据(包含NoSQL)技术包括Hadoop、Spark、HBase、Redis和MongoDB等,这些技术的共同特点是不适合用于支撑事务型应用,特别是与“钱”相关的应用,如“订购关系”、“超市交易”等,这些场合到目前为止还是Oracle等传统关系型数据库的天下。

1. Hadoop Vs. Spark

Hadoop/MapReduce和Spark最适合的都是做离线型的数据分析,但Hadoop特别适合是单次分析的数据量“很大”的情景,而Spark则适用于数据量不是很大的情景。这儿所说的“很大”,是相对于整个集群中的内存容量而言的,因为Spark是需要将数据HOLD在内存中的。一般的,1TB以下的数据量都不能算很大,而10TB以上的数据量都是算“很大”的。比如说,20个节点的一个集群(这样的集群规模在大数据领域算是很小的了),每个节点64GB内存(不算很小,但也不能算大),共计1.28TB。让这样规模的一个集群把500GB左右的数据HOLD在内存中还是很轻松的。这时候,用Spark的执行速度都会比Hadoop快,毕竟在MapReduce过程中,诸如spill等这些操作都是需要写磁盘的。

这儿有2点需要提一下:1)一般情况下,对于中小互联网和企业级的大数据应用而言,单次分析的数量都不会“很大”,因此可以优先考虑使用Spark,特别是当Spark成熟了以后(Hadoop已经出到2.5了,而Spark才刚出1.0呢)。比如说,中国移动的一个省公司(在企业级,移动公司的数据量还是算相当大的),他们单次分析的数量一般也就几百GB,连1TB都很少超过,更不用说超过10TB了,所以完全可以考虑用Spark逐步替代Hadoop。2)业务通常认为Spark更适用于机器学习之类的“迭代式”应用,但这仅仅是“更”。一般地,对于中等规模的数据量,即便是不属于“更适合”范畴的应用,Spark也能快2~5倍左右。我自己做过一个对比测试,80GB的压缩数据(解压后超过200GB),10个节点的集群规模,跑类似“sum+group-by”的应用,MapReduce花了5分钟,而spark只需要2分钟。

2. HBase

对于HBase,经常听到的一个说法是:HBase只适合于支撑离线分析型应用,特别是做为MapReduce任务的后台数据源。持这个观点不少,甚至在国内一个响当当的电信设备提供商中,HBase也是被归入数据分析产品线的,并明确不建议将HBase用于在线应用。可实际情况真是这样吗?让我们先看看它的几大案例:Facebook的消息类应用,包括Messages、Chats、Emails和SMS系统,用的都是HBase;淘宝的WEB版阿里旺旺,后台是HBase;小米的米聊用的也是HBase;移动某省公司的手机详单查询系统,去年也由原先的Oracle改成了一个32节点的HBase集群——兄弟们,这些可都是知名大公司的关键应用啊,够能说明问题了吧。

实际上从HBase的技术特点上看,它特别适用于简单数据写入(如“消息类”应用)和海量、结构简单数据的查询(如“详单类”应用)。在上面提到的4个HBase的应用中,Facebook消息、WEB版阿里旺旺、米聊等均属于以数据写入为主的消息类应用,而移动公司的手机详单查询系统则属于以数据查询为主的详单类应用。

HBase的另一个用途是作为MapReduce的后台数据源,以支撑离线分析型应用。这个固然可以,但其性能如何则是值得商榷的。比如说,superlxw1234同学通过实验对比了“Hive over HBase”和“Hive over HDFS”后惊奇的发现[2],除了在使用rowkey过滤时,基于HBase的性能上略好于直接基于HDFS外,在使用全表扫描和根据value过滤时,直接基于HDFS方案的性能均比HBase好的多——这真是一个谬论啊!不过对于这个问题,我个人感觉从原理上看,当使用rowkey过滤时,过滤程度越高,基于HBase方案的性能必然越好;而直接基于HDFS方案的性能则跟过滤程度没有关系。

3. HBase Vs. Redis

HBase和Redis在功能上比较类似,比如它们都属于NoSQL级别的数据库,都支持数据分片等,关键的不同点实际上只有一个:对HBase而言,一旦数据被成功写入,从原理上看是不会丢的,因为它有Writa-ahead Log(功能上类似于Oracle REDO);而对于Redis而言,即便是配置了主从复制功能,在Failover时完全存在发生数据丢失的可能(如果不配置主从复制,那么丢失的数据会更多),因为它第一没有类似REDO的重做日志,第二采用了异步复制的方式。

关键还在于性能。通常,Redis的读写性能在100,000 ops/s左右,时延一般为10~70微妙左右[4][5];而HBase的单机读写性能一般不会超过1,000ops/s,时延则在1~5毫秒之间[3]。忽略其中的硬件因素,100倍的读写性能差异已经足够说明问题了。顺便提一下的是,Redis在Tuning上还是比较讲究的,比如说,当使用numactl(或taskset)将Redis进程绑定到同一个CPU的不同CORE上时,它的性能一般可以提升30%左右[6],在一些特别的场景下甚至可以有近一倍的提升。

从上述的功能和性能比较上,我们就很容易的总结出HBase和Redis各自的适用范畴:

1)当用来支撑简单“消息类”应用时,如果数据失败是不能容忍的,那就用只能用HBase;如果需要一个高性能的环境,而且能够容忍一定的数据丢失,那完全可以考虑使用Redis。

2)Redis很适合用来做缓存,但除此之外,它实际上还可以在一些“读写分离”的场景下作为“读库”来用,特别是用来存放Hadoop或Spark的分析结果。

有不少人认为Redis只适合用作“缓存”,根据我的理解,这主要是基于以下2个原因:第一,Redis在设计上存在数据丢失的可能性;第二,当无法将数据全部HOLD在内存中时,其读写性能会急剧下降到每秒几百ops[6],这一现象类似于Google开源的Leveldb[7],Facebook的RocksDB团队的通过Performance Benchmark也证实了这一现象的存在[8]。但是,当用作“读库”或用于支撑允许数据丢失的“消息类”应用时,这两个问题实际上都没有关系。

[1] Hadoop虽然强大,但不是万能的。http://database.51cto.com/art/201402/429789.htm

[2] Hiveover HBase和Hive over HDFS性能比较分析。http://superlxw1234.iteye.com/blog/2008274

[3] Hbase性能测试。http://www.cnblogs.com/colorfulkoala/archive/2013/05/13/3076139.html

[4] 互联网利器 Redis内存数据库性能评测。http://tech.it168.com/a2012/1011/1406/000001406978_all.shtml

[5] Howfast is Redis?http://redis.io/topics/benchmarks

[6] Redis千万级的数据量的性能测试。http://www.cnblogs.com/lovecindywang/archive/2011/03/03/1969633.html

[7] Leveldb.https://code.google.com/p/leveldb/

[8] RocksDBbenchmark results. https://github.com/facebook/rocksdb/wiki/Performance-Benchmarks

本文分享自微信公众号 - CSDN技术头条(CSDN_Tech)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2014-08-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 浅谈Apache Spark的6个发光点

    【编者按】Spark是一个基于内存计算的开源集群计算系统,目的是更快速的进行数据分析。Spark由加州伯克利大学AMP实验室Matei为主的小团队使用Scala...

    CSDN技术头条
  • 谁说hadoop才是王道?来看看spark的五大优势吧

    大数据时代的推进依赖着相关技术的进步与发展,而随着Hadoop逐步成为大数据处理领域的主导性解决思路,原本存在的诸多争议也开始尘埃落定,hadoop以绝对优势成...

    CSDN技术头条
  • Apache Spark 不过时的六大理由

    在极短的时间内,Apache Spark 迅速成长为大数据分析的技术核心。这就使得保守派担心在这个技术更新如此之快的年代它是否会同样快的被淘汰呢。我反而却坚信,...

    CSDN技术头条
  • Hadoop、Spark、HBase与Redis的适用性讨论

    最近在网上又看到有关于Hadoop适用性的讨论[1]。想想今年大数据技术开始由互联网巨头走向中小互联网和传统行业,估计不少人都在考虑各种“纷繁复杂”的大数据技术...

    小莹莹
  • va_start va_arg va_end 的原理与实例

    func( Type para1, Type para2, Type para3, ... ) {       /****** Step 1 ******...

    阳光岛主
  • 浅谈 LinkMap 检查每个类占用大小

    LinkMap 文件是 Xcode 产生可执行文件的同时生成的链接信息,用来描述可执行文件的构造成分,包括代码段 __TEXT 和数据段 __DATA 的分布情...

    s_在路上
  • 企业安全管理:整合漏洞管理到开发过程

    软件开发人员也是人,这就是说,高级的应用程序代码也可能包含错误和漏洞。因此,每个软件开发过程都应该对新应用程序代码进行漏洞扫描。但并不是所有开发人员都采取相同的...

    安恒信息
  • 大会 | CVPR 18录用论文:利用量化提升医疗影像分割的准确度

    AI 科技评论按:本文作者为圣母大学(University of Notre Dame)博士后徐小维,他为 AI 科技评论撰写了基于 CVPR 录用论文《Qua...

    AI科技评论
  • 使用Kubespray安装k8s集群

    本文撰写时,Kubespray的master分支不稳定,请使用release版本来安装,具体来说就是切换到最新的tag上。

    颇忒脱
  • webpack-dev-middleware 源码解读

    ? 这是第 42 篇不掺水的原创,想要了解更多,请戳上方蓝色字体:政采云前端团队 关注我们吧~

    政采云前端团队

扫码关注云+社区

领取腾讯云代金券