你好,游客 登录
背景:
阅读新闻

Facebook专家:Hadoop不足以处理大数据

[日期:2013-12-13] 来源:IT168  作者: [字体: ]

  随着大数据在各个业务领域的发展和应用,相关的技术和工具也层出不穷,其中Hadoop框架受到更多的关注和应用。Facebook分析主管Ken Rudin最近在纽约举行的一个Strata+hadoop世界大会发表主题演讲时表示,不要小看关系型数据库技术的价值。他认为,Hadoop编程框架可能是“大数据”运动的代名词,但它并不是企业从大规模存储的非结构化信息中得到价值的唯一工具。

  有很多很普及的大数据的观念需要被质疑,首先一点就是人们普遍认为你可以简单地利用Hadoop,并且Hadoop易于使用。问题是,Hadoop是一项技术,而大数据和技术无关。大数据是和业务需求有关的。事实上,大数据应该包括Hadoop和关系型数据库以及任何其它适合于我们手头任务的技术。

  Rudin说,Facebook的业务模式依赖于其对于超过10亿社交媒体用户的用户资料和活动数据的处理,从而提供有针对性的广告。然而,对于我们需要做的事情而言,Hadoop并不总是最好的工具。

  例如,在Hadoop中对一个数据集做广泛并且探索性的分析是很有意义的,但关系型存储对于那些尚未发现的东西进行运行分析则更好。Hadoop对于在一个数据集中寻找最低水平的细节也很好用,但关系型数据库对于数据的存储转换和汇总则更有意义。因此底线是,对于你的任何需求,要使用正确的技术。

  他表示,还有另一个假设,认为大数据单纯的行为分析提供了宝贵的价值:“问题是这分析给那些无人问津的问题得出了更加聪明的答案。要弄清楚什么是正确的问题依然是一门艺术”。Facebook一直专注于雇佣合适的员工来运行他们的分析操作,那些人不仅要在统计学专业获得博士学位,并且还要精通业务。

  当你面试员工时,不要只关注于“我们怎么计算这个指标”,相反,你应该给他们一个商业案例来研究,并且问他们在这个案例中哪个是最重要的指标。企业也应该尝试着去培养,人人参与分析。

  据Rudin透露,Facebook运营一个内部的“数据培训营”,一个教导员工如何分析的时长两周的项目。产品经理、设计师、工程师甚至财务部门工作人员都要参加。每个人都参与其中的意义就在于,每个人可以用一个共同的数据语言,来互相讨论数据的问题和麻烦。

  Facebook还改变了统计人员和业务团队的组织方法。如果统计人员保持独立,他们往往会坐在那里等待来自业务领域的请求找上门来,再回应他们,而不是主动去做。但是如果统计人员被放置到业务部门,你会发现多个团体将会试图冗余地解决问题。

  Facebook已经采用了“嵌入式”模式,其中分析师被放在业务团队中,但他们要向一些更高级别的分析师报告,这有助于避免重复的劳动。

  对于Hadoop如何组合和处理大数据的技巧和方法,数据专家Anoop曾经在另一篇文章中提到过,一般情况下,为了得到最终的结果,数据需要加入多个数据集一起被处理和联合。Hadoop中有很多方法可以加入多个数据集。MapReduce提供了Map端和Reduce端的数据连接。这些连接是非平凡的连接,并且可能会是非常昂贵的操作。Pig和Hive也具有同等的能力来申请连接到多个数据集。Pig提供了复制连接,合并连接和倾斜连接(skewed join),并且Hive提供了map端的连接和完整外部连接来分析数据。一个重要的事实是,通过使用各种工具,比如MapReduce、Pig和Hive等,数据可以基于它们的内置功能和实际需求来使用它们。至于在Hadoop分析大量数据,Anoop指出,通常,在大数据/Hadoop的世界,一些问题可能并不复杂,并且解决方案也是直截了当的,但面临的挑战是数据量。在这种情况下需要不同的解决办法来解决问题。一些分析任务是从日志文件中统计明确的ID的数目、在特定的日期范围内改造存储的数据、以及网友排名等。所有这些任务都可以通过Hadoop中的多种工具和技术如MapReduce、Hive、Pig、Giraph和Mahout等来解决。这些工具在自定义例程的帮助下可以灵活地扩展它们的能力。

  事实上,与Rudin持相同观点的还有数据专家Joe Brightly,他也总结了Hadoop不适合数据分析的几个理由,其中包括:

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

  Hadoop的子项目Hive和Pig 都不错,但不能逾越其架构的限制。”——Joe提出“Hive 和Pig 都是帮助非专业工程师快速有效使用Hadoop的完善工具,用于把分析查询转换为常用的SQL或Java Map/Reduce 任务,这些任务可以部署在Hadoop环境中。”其中Hive是基于Hadoop的一个数据仓库工具,它可以帮助实现数据汇总、即时查询以及分析存储在Hadoop兼容的文件系统的大型数据集等。而Pig是并行计算的高级数据流语言和执行框架。但作者认为“Hadoop的Map/Reduce框架的一些限制,会导致效率低下,尤其是在节点间通信的情况(这种场合需要排序和连接)。”

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





收藏 推荐 打印 | 录入: | 阅读:
相关新闻      
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款