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