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

一、数据结构
　　hbase，mongodb，redis都属于nosql型存储方案。在实际的项目实践上看，他们的系统存储及处理的数量由大到小。
　　HBase基于列存储，提供<key, family:qualifier, timestamp>三项坐标方式定位数据，由于其qualifier的动态可扩展型（无需schema设计，可存储任意多的qualifier），特别适合存储稀疏表结构的数据（比如互联网网页类）。HBase不支持二级索引，读取数据方面只支持通过key或者key范围读取，或者全表扫描。
　　MongoDb在类SQL语句操作方面目前比HBase具备更多一些优势，有二级索引，支持相比于HBase更复杂的集合查找等。BSON的数据结构使得处理文档型数据更为直接。MongoDb也支持mapreduce，但由于HBase跟Hadoop的结合更为紧密，Mongo在数据分片等mapreduce必须的属性上不如HBase这么直接，需要额外处理。
　　HBase与Mongodb的读写性能正好相反，HBase写优于随机读，MongoDB似乎写性能不如读性能。
　　Redis为内存型KV系统，处理的数据量要小于HBase与MongoDB
二、经验分析
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