Hadoop、Spark、HBase与Redis的适用性讨论（二）：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方案的性能则跟过滤程度没有关系。【待续】

1. hadoop虽然强大，但不是万能的。Http://database.51cto.com/art/201402/429789.htm

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