在云计算世界中，有一个概念最被认可，但却很少有人理解。当被问及Apache Hadoop时，绝大部分企业都会将其看做是首屈一指的云计算数据模型。但是，大部分人都不知道Hadoop是什么，应当如何使用它或者它是否对他们有帮助。

Apache Hadoop是MapReduce计算模型的一个开源实施。MapReduce是由谷歌公司推广开的，用于构建公司的互联网索引。在其最初形式中，MapReduce被当做一种系统集群分布式工作的方法，开发出来。在这样一个集群中，有一个把题（计算任务）分解成小片的“主”节点，而每一小片工作任务都被发送至一个“工作”节点以进行下一步处理。这种分割——分发的模式就是名称中“map”部分的由来。当所有的“工作”节点都完成了分配到的任务时，将返回计算结果并组合或“reduce”以生成最后的结果。

但是，MapReduce和Hadoop引人注目的地方在于把MapReduce的概念应用于大数据应用中，而不只是计算网格中的分布式处理任务。虽然MapReduce的最初目的和“网格计算”极为相似，不过这个概念也被应用于对跨多个系统的数据库的访问。人们将它看做是大数据典型模式，原因有二：出于便利性的考虑，大多数大数据都是在特定环境中被搜集和存储的；通常来说，大数据都是过于庞大而无法集中在一个单一系统中。

Hadoop的核心组成部分是Hadoop分布式文件系统（HDFS），这是一个专门为跨潜在巨大量分布式服务器进行虚拟化而设计的文件系统。实际上，Hadoop使用JobTrackers和TaskTrackers来完成映射和降维任务；使用合适的软件组件，Hadoop就能够在结构化数据和非结构化数据上正常运行，并且使用几乎所有的编程语言作为其开发框架。它适用于绝大多数的计算平台，只要能够正确地组织好版本和工具，你就可以毫不麻烦地在Hadoop中安装混合平台。

因为Hadoop是围绕着两个HDFS、一个分布式数据模型、JobTrackers / TaskTrackers以及一个分布式编程模式而构建的，所以它可以说用于构建云计算应用程序的完美框架。事实上，你可以将Hadoop看做是唯一真实、广泛可用的云计算应用程序框架，因为它是特别为数据所在的分布式处理而设计的，它并不会把数据移回至完成处理数据的位置。在云计算中，这是一个关键要求，因为大规模数据迁移的成本令人难以置信的高昂，对计算资源的要求也是性能超密集型的。可以预见，随着时间的推移，真正云计算应用程序的开发一定将从Hadoop发展而来。

Hadoop“完美”框架的另一面

当然，Hadoop也有着其挑战性。任何掩盖复杂性数据的处理架构都会由于滥用而产生开发低效的风险。

Hadoop最大的挑战是数据组织。因为数据是分离的，所以在数据的分布式组件中可能构建需要相关性的请求。例如，设想有一个电子表格式的结构，其中一半容量在一个系统上，而另一半容量在另一个系统上。如果有一个请求要求测试不同系统上的两组数据，实际上必须把整个数据库进行迁移，以执行这个请求的任务，从而使分布式数据和分布式处理的原理失去了作用。对于结构化数据来说，设计应用程序以避免这种类型的低效是相对容易的，但是对于非结构化数据或商业智能（BI）请求高度多样化的应用来说，就可能会产生严重的性能问题。

由于这一风险，企业应用程序中大数据的实际应用程序经常会综合使用Hadoop和传统工具。有些最大型的Hadoop应用程序为Hadoop打造了“前端”以便于处理标准DBMS和数据采集应用程序至HDFS的信息。他们还在查询数据库中汇总Hadoop结果。在汇总数据中运行BI应用程序总是比在原始详细大数据中运行相同的应用程序更为高效，而预处理可确保数据分布是最优的。

Hadoop的另一个问题是，它往往是集中采用大规模计算资源的方法而不是通过使用高效处理的方法来解决大数据问题。尤其是结构化数据，有更好的基于DBMS机制可用于分发数据和请求处理；复杂任务可能会占用大量资源，因此作业调度是防止BI请求过度使用资源的关键，从而也就确保更多的实时任务能够按计划完成。在同一集群中混合BI和实时应用程序的大多数Hadoop用户要么会调度作业以避免资源使用发生冲突，要么在集群中采用一种分配计算时间的方法以避免大型BI任务私下占用所有的资源。
Hadoop是一个范式变换，因此由训练有素的专业团队通过一系列精心设计的试运行步骤来进行具体实施是绝对至关重要的。有人认为单独实施Hadoop将会把断开的离散云计算数据资源连接成为一个统一的数据库，这种观点是极其错误和危险的。除非在提交生产以前就对替代品（尤其是数据分布的替代品）完成了大量周密的测试，否则即便是经验丰富的Hadoop开发人员也很难识别其中的陷阱。