Facebook 数据专家：处理大数据，仅有 Hadoop 是不够的

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