Hadoop本就是为批处理环境而设计的。但是奇怪的是，大部分人都把Hadoop视为一个探索性的环境，数据科学家们（比如：典型的电力用户）用它挖掘海量数据，并发现有价值的洞察。许多公司都开始招聘数据科学家，因为大量网页日志和社交信息消耗了数据科学家们的精力，他们收集这些信息是为了更好地理解客户购买行为、情绪以及其它信息。

　　现如今的事实是，Hadoop要支持迭代分析速度有点太慢了。它不只要以批量方式运行，但它甚至不是一个十分高效的批处理环境。至少，Hadoop 1.0版本没有连接的概念，所以程序员们必须把数以百计的MapReduce任务连接起来，来执行相对简单的查询。由于存在许多较小的负载管理，所以单个查询将消耗掉单个集群或分区上的所有资源。（Hadoop 2.0版本解决了这类问题）。

　　因此，现在的大部分公司都把Hadoop用作一个巨大的ETL引擎，用来捕获、存储和处理准结构化的数据，并把结果推送到基于SQL的环境中，业务用户可以用熟悉的基于SQL的工具查询和分析这些数据。有趣的是，很少有公司把Hadoop用作其它面向批量处理分析工作负载，比如，定时执行报表统计和数据挖掘。目前对Hadoop的追捧几乎完全在强调探索和发现功能。

　　实时还是失败！

　　因此，Hadoop分析的神秘性掩盖了这些事实。这是导致Hadoop供应商纷纷赶在今年推出运行于Hadoop内部的实时查询引擎的主要原因。Cloudera公司推出了Impala，EMC Greenplum发布了Hawq，而Hortonworks将赌注压在了Hive上。上面这三款产品宣称不仅可以把Hadoop转入真正的迭代分析环境，还支持SQL或类SQL的接口，使得数据科学家以外的人员也可以访问Hadoop数据。当然，这些环境都是全新的，相对而言未经过实践考研。

　　另一种替代方法是把数据导入到基于SQL的分析引擎，比如Teradata或者IBM的Netezza，这些产品就是针对TB量级为运行复杂查询和分析功能而设计的。现在每家数据库供应商都提供连接器，支持把数据从Hadoop导入到专用环境中。但是这些系统都有着惊人的售价，而且需要IT管理员跨狭窄数据通道迁移大量数。如果我们讨论的真的是“大数据”的话，这种数据迁移并不是明智之举。

　　因此，喜欢尝鲜的Hadoop使用者们在要求供应商提供实时查询引擎。如果Hadoop真的支持实时查询，它可以重新定义整个分析愿景，并让那些Hadoop初创公司一夜暴富。但是不要马上就给你的代理人打电话：要到达实时的程度，Hadoop比关系数据库管理系统（RDBMS）还有更长的路要走，关系数据库在这条路上走了已经超过三十年了。

　　有些人认为，Hadoop社区现在正努力在开源平台上重塑RDBMS。这可能需要一段时间。但是，也许这只是个过程，而不是真正重要的目的地。通过检查和研究这种新的数据处理平台替代品，我们已经自己学到了很多。Hadoop反映出基于SQL世界的优缺点，并把优势劣势都凸显了出来。所以，我欢迎Hadoop，并且相信它将在大多数BI环境中日益扮演更加关键的角色。