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

  • 晁晓娟

2012 年 4 月 30 日

话题:大数据架构文化 & 方法AI

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

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

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

1:“Hadoop 是一个框架,不是一个解决方案”——他认为在解决大数据分析的问题上人们误认为 Hadoop 可以立即有效工作,而实际上“对于简单的查询,它是可以的。但对于难一些的分析问题,Hadoop 会迅速败下阵来,因为需要你直接开发 Map/Reduce 代码。出于这个原因,Hadoop 更像是 J2EE 编程环境而不是商业分析解决方案。” 所谓框架意味着你一定要在之上做个性化和业务相关的开发和实现,而这些都需要成本。

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

大数据架构文化 & 方法AI