我们正处于一场关于大数据和分布式计算的炒作中，该是让大数据泡沫破裂的时候了。
是的，穿过一个炒作周期来使技术跨越鸿沟，从早期的采用者到更广泛的大众群体。而且，至少它暗示了一个超越学术对话和试点项目的技术进步。但是更广泛的观众采用此项技术可能只是随波逐流，一直就缺少一些重要的警示观点。
跟随潮流
在一个炒作周期内，通常有一个跟随潮流的供应商群，他们仓促实施一个时髦的技术，试图要保持与其相关而且不会在混乱中迷失方向。但是这些公司的产品可能会使市场混淆，因为最终这些技术会被不恰当地使用。
使用这些产品的项目将面临失败的风险 ，即使客户已经付出了大量的资源和精力，也有可能产出几乎没有投资回报率，然后客户可能会开始质疑被热炒的技术。现在Hadoop堆栈正在面临这种局面。
打破大数据泡沫以鉴别有关其产品和模式的某些细微的差别开始。以下是一些重要因素，分为三个重点领域，这些应该在你考虑一个hadoop分布式基础架构的相关技术之前弄明白。
Hadoop不是RDBBMS的杀手
Hadoop分布式系统在商品硬件和存储上运行，使它比传统的关系数据库管理系统(RDBMS)便宜很多，但它并不是一个数据库替代品。Hadoop分布式架构的建立是为了利用对较大数据块的顺序数据访问（一次写入多次读取）而不是单独的记录中。正因为如此，Hadoop分布式系统针对分析工作负载进行了优化，而不是关系型数据库管理系统的交易处理工作。
坦白的说，低延迟的读和写不在Hadoop的分布式文件系统(HDFS)中并不奏效。仅仅是协调的写入和读取单个字节的数据，就要求多个终端控制协议/网端协议连接到Hadoop的分布式系统，这给交易操作带来了非常高的延迟。
然而，在一个优化好的Hadoop集群中，读取和写入大块数据的吞吐量是非常高的。
Hive文件和非Hive文件
Hive文件允许开发人员查询Hadoop分布式系统内的数据并使用一个类似结构化查询语言(SQL)的语言。越来越多的人知道结构化查询语言可以编写的Hadoop分布式系统并行编程技术的本地代码，这使得使用Hive文件能有一个有吸引力的和更便宜的办法来招聘新的人才，或者让开发人员学习Java程序设计语言和编程技术代码编程模式。
然而，在作出关于Hive文件作为你的大数据解决方案的任何决定之前，有一些非常重要的权衡需要注意：
?HiveQL(Hive文件结构化查询语言的方言)只允许您查询结构化数据。
?Hive文件本身并没有一个Extract/Transform/Load(ETL)工具。所以尽管你可以节省钱使用Hadoop分布式系统和Hive文件作为您的数据库，内部开发人员也可以运行结构化查询语言的技能组合，但是维护定制加载脚本和随需求变化准备数据支付费用。
?Hive底层使用HDFS和Hadoop MapReduce计算方法。看来这意味着，其原因就像已经讨论过的那样，从传统的关系数据库管理系统到习惯于正常的结构化查询语言响应时间的最终用户，可能要对Hive文件使用的有点笨拙的批处理方法来“查询”而感到失望了。
这是实时的Hadoop分布式系统吗? 并非真的如此。
让我们来探索一些使Hadoop分布式系统不适用于实时应用的技术因素。Hadoop分布式系统的MapReduce计算方法沿用了一个Map预处理步骤和一个Reduce数据聚合/提炼的步骤。虽然有可能对实时流数据应用这种Map操作，但是Reduce就不能了。
这是因为Reduce步骤要求所有输入的数据首先要为每一个独特的数据键进行映射和整理。然而对这个涉及到缓冲区的过程有一个攻击，甚至黑客都无法进行实时操作，因此缓冲区只能持有少量的数据。
某些NoSQL产品也使用MapReduce来分析工作负载。因此当这些数据存储库可以执行接近实时的数据查询时，它们也不是用于实时分析的工具。
尽管还有其它的一些大数据的谣言需要粉碎，Hadoop分布式系统也无法作为关系数据库管理系统的更换。Hive文件的各种缺点和编程工具对实时流数据的应用的不适应性是目前在我们的观察中存在的最大的障碍。
最后，要实现关于对大数据的承诺，需要透过表象去了解合适的应用。信息技术（IT）组织必须冲破大数据泡沫，并将自己对Hadoop分布式系统的努力集中到提供真正的、不同的价值的领域。
(责任编辑：蒙遗善)