作为Hadoop 曾经的超级粉丝，Joe Brightly承认自己在很多方面非常热爱Hadoop，比如“可以处理PB级别的数据;可以扩展到数千个处理大量计算工作的节点；可以用非常灵活的方式存储和加载数据……”但当他部署Hadoop用于分析的时候，他才意识到它并不是无所不能。

在Quantivo，Joe及其同事已经“探索了许多方法来部署Hadoop用于回答分析型查询”，直到最后，“它变得好像是用一个锤子来建造一个房屋的运动”，这并不是不可能，但是带来了“不必要的痛苦和可笑的低效成本”。

Joe 从五个方面分析了为什么数据分析不使用Hadoop的理由：

1：“Hadoop是一个框架，不是一个解决方案”

他认为在解决大数据分析的问题上人们误认为Hadoop可以立即有效工作，而实际上“对于简单的查询，它是可以的。但对于难一些的分析问题，Hadoop会迅速败下阵来，因为需要你直接开发Map/Reduce代码。出于这个原因，Hadoop更像是J2EE编程环境而不是商业分析解决方案。”

所谓框架意味着你一定要在之上做个性化和业务相关的开发和实现，而这些都需要成本。

2：“Hadoop的子项目Hive和Pig 都不错，但不能逾越其架构的限制。”

Joe提出“Hive 和Pig 都是帮助非专业工程师快速有效使用Hadoop的完善工具，用于把分析查询转换为常用的SQL或Java Map/Reduce

任务，这些任务可以部署在Hadoop环境中。”其中Hive是基于Hadoop的一个数据仓库工具，它可以帮助实现数据汇总、即时查询以及分析存储在Hadoop兼容的文件系统的大型数据集等。而Pig是并行计算的高级数据流语言和执行框架。但作者认为“Hadoop的Map/Reduce框架的一些限制，会导致效率低下，尤其是在节点间通信的情况(这种场合需要排序和连接)。”

3：“部署是很方便，快捷而且免费，但在后期维护和开发方面成本很高 ”

Joe不否认“工程师可以在一个小时内下载、安装并发布一个简单的查询，因此Hadoop是非常受欢迎的。而且作为没有软件成本的开源项目使得它是替代甲骨文和Teradata的一个非常有吸引力的选择。但是就像很多通用开源框架一样，它并不会完全适配你的业务，因此，要想把开源框架业务化，你就不得不投入开发和维护。”Joe

也认为“一旦当你进入维护和开发阶段，Hadoop的真正成本就会变得很明显。”

在此我向大家推荐一个大数据开发交流圈：658558542    （☛点击即可加入群聊）里面整理了一大份学习资料，全都是些干货，包括大数据技术入门，大数据离线处理、数据实时处理、Hadoop 、Spark、Flink、推荐系统算法以及源码解析等，送给每一位大数据小伙伴，让自学更轻松。这里不止是小白聚集地，还有大牛在线解答！欢迎初学和进阶中的小伙伴一起进群学习交流，共同进步！

4：“对于大数据流水线和汇总非常有效，但对应用于特定的分析来说是非常可怕的。”

“Hadoop擅长于大量数据的分析和汇总，或把原始数据转化成对另一个应用程序(如搜索或文本挖掘)更有效的东西‘流水线’-

这是它存在的意义。不过，如果你不知道要分析的问题，或如果你想探索数据的模式，Hadoop的很快变得不可收拾。“这再次回到了业务本身，框架是为业务服务的，即便是大数据的分析和汇总，也难以脱离其数据的业务特性。所以对于特定的分析，仍然不得不在编程和执行MapReduce代码上花很多时间才能达到目的。

5：“性能除了‘不好’的时候都很好。”

“当你需要分析大量的数据时，Hadoop允许你通过数千个节点并行计算，这一点上其潜力很大。但是，并非所有的分析工作可以很容易地进行并行处理，尤其是需要当用户交互驱动的分析。”

所以要想性能很好，你仍然需要专门为自己要解决的问题而设计和优化相应的Hadoop程序，否则会很慢。“因为每个Map/Reduce

任务都要等到之前的工作完成。”所以就像关键路径一样，Hadoop执行性能的快慢会取决于其最慢的MapReduce任务。

Joe最后认为：“Hadoop是一个用来做一些非常复杂的数据分析的杰出工具。但是具有讽刺意味的??是，它也是需要大量的编程工作才能得到这些问题的答案。”

这一点不止在数据分析应用方面，它其实反映了目前使用开源框架时候不得不面对的选型平衡问题。当你在选型开源框架或代码的时候，既要考虑清楚它能够帮到你多少，节省多少时间和成本，提高多少效率。也要知道由此而产生多少新增的成本，比如工程师的学习成本、开发和维护成本，以及未来的扩展性，包括如果使用的框架升级了，你和你的团队是否要做相应的升级;甚至还要有安全性方面的考虑，毕竟开源框架的漏洞也是众所周知的。

感谢您的观看，如有不足之处，欢迎批评指正。最后祝福所有遇到瓶颈的大数据程序员们突破自己，祝福大家在往后的工作与面试中一切顺利。