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

作为 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 是一个用来做一些非常复杂的数据分析的杰出工具。但是具有讽刺意味的​​是，它也是需要大量的编程工作才能得到这些问题的答案。” 这一点不止在数据分析应用方面，它其实反映了目前使用开源框架时候不得不面对的选型平衡问题。当你在选型开源框架或代码的时候，既要考虑清楚它能够帮到你多少，节省多少时间和成本，提高多少效率。也要知道由此而产生多少新增的成本，比如工程师的学习成本、开发和维护成本，以及未来的扩展性，包括如果使用的框架升级了，你和你的团队是否要做相应的升级；甚至还要有安全性方面的考虑，毕竟开源框架的漏洞也是众所周知的。