数据分析不使用Hadoop的五大理由

buhao

　　作为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的真正成本就会变得很明显。”
　　4：“对于大数据流水线和汇总非常有效，但对应用于特定的分析来说是非常可怕的。”——“Hadoop擅长于大量数据的分析和汇总，或把原始数据转 化成对另一个应用程序（如搜索或文本挖掘）更有效的东西‘流水线’-  这是它存在的意义。不过，如果你不知道要分析的问题，或如果你想探索数据的模式，Hadoop的很快变得不可收拾。“这再次回到了业务本身，框架是为业务 服务的，即便是大数据的分析和汇总，也难以脱离其数据的业务特性。所以对于特定的分析，仍然不得不在编程和执行MapReduce代码上花很多时间才能达 到目的。
　　5：“性能除了‘不好’的时候都很好。”——“当你需要分析大量的数据时，Hadoop允许你通过数千个节点并行计算，这一点上其潜力很大。但是， 并非所有的分析工作可以很容易地进行并行处理，尤其是需要当用户交互驱动的分析。”  所以要想性能很好，你仍然需要专门为自己要解决的问题而设计和优化相应的Hadoop程序，否则会很慢。“因为每个Map/Reduce  任务都要等到之前的工作完成。”所以就像关键路径一样，Hadoop执行性能的快慢会取决于其最慢的MapReduce任务。
　　Joe最后认为：“Hadoop是一个用来做一些非常复杂的数据分析的杰出工具。但是具有讽刺意味的​​是，它也是需要大量的编程工作才能得到这些 问题的答案。”  这一点不止在数据分析应用方面，它其实反映了目前使用开源框架时候不得不面对的选型平衡问题。当你在选型开源框架或代码的时候，既要考虑清楚它能够帮到你 多少，节省多少时间和成本，提高多少效率。也要知道由此而产生多少新增的成本，比如工程师的学习成本、开发和维护成本，以及未来的扩展性，包括如果使用的 框架升级了，你和你的团队是否要做相应的升级；甚至还要有安全性方面的考虑，毕竟开源框架的漏洞也是众所周知的。