彩票走势图

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

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

1. Vs.

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只适合于支撑离线分析型应用，特别是做为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”后惊奇的发现，除了在使用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微妙左右;而HBase的单机读写性能一般不会超过1,000ops/s，时延则在1～5毫秒之间。忽略其中的硬件因素，100倍的读写性能差异已经足够说明问题了。顺便提一下的是，Redis在Tuning上还是比较讲究的，比如说，当使用numactl(或taskset)将Redis进程绑定到同一个CPU的不同CORE上时，它的性能一般可以提升30%左右，在一些特别的场景下甚至可以有近一倍的提升。

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

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

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

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