版权声明：

写本文由leftnoteasy发布于http://leftnoteasy.cnblogs.com 本文可以被全部或者部分的使用，但请注明出处，如果有问题，可以联系wheeleast (at) gmail.com, 也可以加作者的新浪微博：http://weibo.com/leftnoteasy

前言：

很久没有写写博客了，之前主要是换工作，耽误了很多的时间，让人也变得懒散，不想花大时间来写东西。另外就是也确实没有什么自己都觉得有意思的东西拿来写 写，对一般的知识什么的，我比较倾向于往evernote上面记笔记。不过最近对于Hadoop看得比较多，对它的发展也比较关心，最近了解得越多，也就 越相信Hadoop的未来，这里写一篇文章与大家分享分享，为什么我相信Hadoop一定是分布式计算的未来。

写在前面的话：

今天听同事分享了一篇很有意思的讲座，叫做"Why Map-Reduce Is Not The Solution To Your Big-Data Problem"(为什么Map-Reduce不是你的“大数据”问题的解决方案)。同事很牛，也分享了很多非常有价值的观点，不过他预言Map- Reduce将会在5年之内消失（而且还呼吁有做存储方面的牛人来预言一下，Hdfs将在5年之内消失），这个话题如果成立的话，让我这个目前在 Hadoop工程师，感到无比的压力。这里不为了争个你死我活，只是谈谈自己的一些想法。另外由于这位同事的分享是内部进行的，这里就不透露分享中具体的 内容了，只谈谈自己的观点。

（本文需要对Hadoop有一定的基础方可理解）

Hadoop为何物？

虽说Hadoop的名声很大，但是总还是有同学不太了解的，这里一笔带过一下。

  Google分布式计算三驾马车：

Hadoop的创始源头在于当年Google发布的3篇文章，被称为Google的分布式计算三驾马车（Google还有很多很牛的文章，但是在分布式计算方面，应该这三篇的影响力最大了）：http://blog.sina.com.cn/s/blog_4ed630e801000bi3.html，链接的文章比我介绍得更清晰，当然最好还是看看原文了，这是做分布式系统、分布式计算的工程师必修课。

Google File System用来解决数据存储的问题，采用N多台廉价的电脑，使用冗余（也就是一份文件保存多份在不同的电脑之上）的方式，来取得读写速度与数据安全并存的结果。

Map-Reduce说穿了就是函数式编程，把所有的操作都分成两类，map与reduce，map用来将数据分成多份，分开处理，reduce将处理后的结果进行归并，得到最终的结果。但是在其中解决了容错性的问题。

BigTable是在分布式系统上存储结构化数据的一个解决方案，解决了巨大的Table的管理、负载均衡的问题。

Google就靠着这几样技术，在搜索引擎和广告方面取得了举世瞩目的成就。不过Google不是傻的，这三篇文章虽然都是干货，但是不是直接就可以用 的。话说Google发表了这三篇文章后，在学术界引起了轩然大波，大家对这三样东西提起了浓厚的兴趣，都想着是不是可以实现一下，以为己用。

  Doug Cutting：

Doug Cutting之前是一个非常有名的开源社区的人，创造了nutch与lucene（现在都是在Apache基金会下面的），nutch之前就实现了一个 分布式的爬虫抓取系统。等Google的三驾马车发布后，Doug Cutting一看，挖靠这么厉害的技术，于是就实现了一个DFS(distributed file system)与Map-Reduce（大牛风范啊），集成进了Nutch，作为Nutch的一个子项目存在。那时，是2004年左右。

在互联网这个领域一直有这样的说法：

“如果老二无法战胜老大，那么就把老大赖以生存的东西开源吧”

当年与Google还是处在强烈竞争关系的Yahoo!于是招了Doug兄进来，把老大赖以生存的DFS与Map-Reduce开源了。开始了Hadoop的童年时期。差不多在2008年的时候，Hadoop才算逐渐成熟。

  现在的Hadoop:

现在的Hadoop不仅是当年的老二Yahoo的专用产品了，从Hadoop长长的用户名单中，可以看到Facebook,可以看到Linkedin，可 以看到Amazon，可以看到EMC, eBay，Tweeter，IBM, Microsoft, Apple, HP...(后面的一些未必是完全使用)。国内的公司有淘宝、百度等等。

  我来定义一下Hadoop：

Hadoop是一套开源的、基础是Java的、目前能够让数千台普通、廉价的服务器组成一个稳定的、强大的集群，使其能够对pb级别的大数据进行存储、计 算。已经具有了强大稳定的生态系统，也具有很多使用的延伸产品。比如做查询的Pig, 做分布式命名服务的ZooKeeper, 做数据库的Hive等等。

为什么世界上只有一个Hadoop？

我的前公司是国内某一个著名互联网公司的子公司，专注做云计算，我也在这个公司最兴盛的时候进入，当时宣传的口号是“做最好的云计算”，就是希望自己开发 一套存储计算系统（就是类似于前面提到过的dfs与map-reduce），并且克服一些Hadoop的缺点（比如说用c++去实现，克服Java的一些 性能问题）。后来结局可能大家也猜到了，投入了很多钱，招了不少牛人，确实也做出了还算不错的云计算（至少在国内是数一数二的）。但是最终不管从稳定性还 是效率上还是scalable来说，都远远被Hadoop甩在了后面。虽然我前公司这个云计算项目是否会成功，这里没办法预测，但是前途终究还是比较黯淡 的。

最近一年还听说国内不少的互联网巨头都成立了云计算部门，做“自己的”云计算，有些小得像创业时期一样的公司，都宁愿自己写一套map-reduce框 架，不愿意直接使用Hadoop。可能这个跟国人的想法，武功秘笈一定要自己藏着，不让别人学，传男不传女。对别人白给你的东西，非常不放心，觉得大家都 能学到的东西，肯定竞争力是不够的。

除开心态问题不谈，但从技术实力上来说，一般国内公司的核心开发团队的能力和当年的Yahoo!比，还是有非常大的差距的，至少像是Doug兄这样的大牛是很罕见的，从开发者的实力来说，就差了不止一个档次。

其次从积累来说，Hadoop从初创到现在也经过了至少7年的积累的，碰到过很多刁钻客户的问题都慢慢克服了（比如Facebook的超大数据存储），带 给用户的经验教训是很充足的，比如说性能调优这一块，就有非常多的文章去介绍。而自己开发一个，什么都需要从头再来。

最后也是最重要的是，Hadoop形成了一个强大稳定的生态系统，里面有生产者（共享改进的代码、fix bug），也有消费者（使用项目并且反馈经验），Hadoop的用户也可以获得较大的经济利益（不花钱买软件，还可以增加效率）。对于一个开源社区来说， 构建出一个完整的生态系统是非常非常的困难，一旦构造出来了，项目就会很稳定的往前去进步。

Hadoop的优势

之前分析了一些“虚”的东西，比如生态系统什么的，这里说说一些实际的东西。

  Benchmark:

Hadoop现在保持了很多漂亮的记录：

存储：现在世界上最大的Hadoop集群目前在Facebook，可以存储30PB的数据

计算：Hadoop是目前Terasort记录的保持者（参见：http://sortbenchmark.org/)，Terasort是给出1TB的随机数据，看谁能够在最短的时间内完成排序，Hadoop使用了1400多个节点，在2分钟内完成1T的数据排序。

这里顺便说一下，之前给出网站里面有很多的benchmark，可以看到Hadoop的集群是最大的，使用的机器最多的，像是TritonSort这样的 集群，使用了区区50多个节点，最终的结果并不比Hadoop差太多，但是这里得注意一下。TritonSort是专门用来做排序的，里面加入了相当多的 优化，但是Hadoop是一个通用的集群，并没有为了一种任务进行如此多的优化。从用户的角度上来说，愿意花钱去买一个只会排序的电脑是意义不那么大的。

注：左右两边属于两种不同的terasort，hadoop是其中一种的记录保持者

  能做什么？

前面说的基本的存储和计算Hadoop是一定能胜任的，下面谈谈一些“高级”的功能。

常见的数据库操作，比如orderby、select这样的操作都可以的，Hive就是支持这样的Sql模型，能够将Sql语句最终转化到Map-Reduce程序中去。其性能和可用性已经得到了证明，Facebook就用它做了不少的数据分析的工作

常见的机器学习、矩阵分析算法，目前Mahout作为一个发展迅速的项目，在逐渐填补Hadoop在机器学习领域的空白，现在常见的分类、聚类、推荐、主 成分分析算法（比如SVD）都已经有相应的Map-Reduce实现了。虽然目前从用户群和效率上来说是不够的，但是从它的发展来说应该会很快的达到工业 界的标准

Hadoop的劣势

现在Hadoop依然有很多的问题没有解决，这让有些人非常的怀疑Hadoop的未来，这里谈谈Hadoop的一些重要的劣势

  HA(High Availability)高可用性:

这一点是Hadoop非常弱的一个缺点，不管是Hdfs还是Map-reduce，都是采用单master的方式，集群中的其他机器都是与一台中心机器进 行通信，如果这个中心机器挂了，集群就只有不工作了（不一定数据会丢失，但是至少需要重启等等工作)，让可用性变得更低。这个一般叫做单点失败 (single point of failure,SPOF)。

虽然现在有些公司已经给出了解决方案，比如EMC就有用Vmware搭建虚拟集群，对master节点进行镜像备份，如果master挂掉，那么立刻换上镜像备份的机器，使其可用性变高，不过这个终究不是一个内置的解决方案，而且Vmware这一套东西也并不便宜。

不过之后这个问题将会得到非常好的解决，我在Hadoop的未来这一章将说以说。

  Hadoop目前解决得不那么好的一些算法：

  Join等:

Map-Reduce还有一个问题是，对于Join这个最常见的数据库操作，支持力度还是不够，特别是针对那种上TB的数据，Join将会很不给力，现在已经有了一些解决方案，比如说SIGMOD'2010的这篇文章：

A Comparison of Join Algorithms for Log Processing in MapReduce

不过在现在的情况下，只有尽量的避免大数据库的Join操作

  需要进行很多轮迭代、循环的算法：

对于循环，Map-Reduce稍好，比如矩阵计算，高斯消元法这样的，循环的次数的确定的算法，实现起来还是不难，只是有点慢。但是迭代就更麻烦了，因为现在的Map-Reduce的mapper和reducer是不太方便去弄这样的终止条件。

还有就是迭代次数超多的算法（比如说矩阵的SVD分解），在超大矩阵的情况下，迭代次数可能会上亿次。而Map-Reduce在每次迭代的时候都会把数据往文件里面读写一遍，这样的浪费的时间是巨大的。

其实Map-Reduce不是绝对没有办法去解决这些问题，而只是现在这个还不是最重要的日程，Hadoop还有很多很多的东西可以优化，比如说前面提到 的HA，这些东西只有往后放放，我将在之后的Hadoop的未来部分，谈谈未来版的Hadoop怎么去解决这些问题。

  编程复杂，学习曲线陡峭：

对于一般的map-reduce框架，hello world程序就变成了word count，就是给出一堆的文本文件，最终统计出里面每一个不同的单词出现的次数，这样一个简单的任务（可能在linux shell下一行就写出来了），在Map-reduce中需要几十行，一般新人从理解word count到写出自己的word count，到跑通，一个星期是肯定需要的。这样陡峭的学习曲线让许多人难以深入。

另外还有一点Hadoop被人所诟病的是，代码丑陋，虽然Hadoop是用高级语言Java写成的，但是里面对每一个步骤都要分成mapper和reducer，这个被戏称为新时代的汇编语言。

一般来说，做数据分析的人程序都写得不咋地（强哥这样的达人除外），能写写matlab，R，或者spss就差不多了，如果要让他们去写map- reduce，那就等于叫他们别干活了。而大数据的重要的作用就是用来做数据分析，Hadoop的未来发展必须得抓住这群数据分析师的心。

其实现在已经有一些实验中的产品，让用户可以用高级语言编程，不会再看到丑丑的map-reduce了。我在前公司的时候就与团队一起做了还不错的尝试， 至少，数据分析师可以用Python来编程了。map-reduce变成了一个底层的东西，现在不是某些人在分析性能的时候就贴上汇编代码吗，之后可能会 变成在前段的程序效率不行的时候，就贴上后端Java的map-reduce程序。

所以对这个难题之后肯定会解决掉，底层分布式程序开发与用户将被清楚的分开，之后想要写word-count一定会像hello world一样简单。

Hadoop的未来怎么样？

http://www.slideshare.net/hortonworks/apache-hadoop-023 (hadoop 0.23)

给出这样的一个官方文档，谈谈之后的hadoop的发展。目前的hadoop的稳定版是0.20.x，这个0.23是个未来版，估计将在今年的Q4进行beta的发布（目前看起来，至少代码是写了很多了） 。

  HDFS Federation

首先是一个叫做HDFS Federation的东西，它将hdfs的命名空间进行了扩展，目前的HDFS的所有文件的meta信息都保存在一台机器的内存中，使得HDFS支持的 文件数目是有限的，现在进行了这样改动后，将hdfs的命名空间做成了分布式的，对之后方便对不同的用户文件夹进行管理，还有从HDFS的实现上来说，都 会更为简单。

  下一代的Map-Reduce：

节点数：从目前的4000增加到6000-10000台

并发的任务数:从目前的40000增加到100000

更高级的硬件支持，目前支持的硬件主要是8core, 16G ram, 4T disk, 之后将会支持16+core, 48/96G ram, 24/48T disk

架构的改变，对现在的JobTracker-TaskTracker的结构做了很大的改进，现在会用ZooKeeper去保存master的状态，避免了之前提到的SPOF

更多的编程模式的支持（这个很重要）

比如MPI，迭代程序的处理，并且在Hadoop中运行这些类型的编程模式，并且这些程序将会被Hadoop统一管理

总结：

之前谈了Hadoop的优势、劣势等等，综合来说就是，优势是很明显的（比如这么多牛公司在用，并且也贡献了很多的代码），远远超出了其他的分布式系统， 劣势虽然不小，但是改进这些不足的地方是在计划中，已经在实施了。而且Hadoop不仅在学术界或者是工业界，都有很高的地位，综合了这些天时地利人和， 那前途还是非常光明的

您可能也喜欢：
Hadoop以及hadoop应用	Hadoop在Linux下面进行分布式计算	KDD Cup 2012：社交计算和计算广告学	RoBa’s Blog：相似度计算(2)	不得不收藏与分享–云计算术语大全
无觅

相关文章

• Hadoop在Linux下面进行分布式计算 (0)
• Hadoop以及hadoop应用 (2)

您可能已经想到，Hadoop 运行在 Linux 生产平台上是非常理想的，因为它带有用 Java™ 语言编写的框架。Hadoop 上的应用程序也可以使用其他语言编写，比如 C++。

Hadoop 有许多元素构成。最底部是 Hadoop Distributed File System（HDFS），它存储 Hadoop 集群中所有存储节点上的文件。HDFS（对于本文）的上一层是 MapReduce 引擎，该引擎由 JobTrackers 和 TaskTrackers 组成。

对外部客户机而言，HDFS 就像一个传统的分级文件系统。可以创建、删除、移动或重命名文件，等等。但是 HDFS 的架构是基于一组特定的节点构建的（参见图 1），这是由它自身的特点决定的。这些节点包括 NameNode（仅一个），它在 HDFS 内部提供元数据服务；DataNode，它为 HDFS 提供存储块。由于仅存在一个 NameNode，因此这是 HDFS 的一个缺点（单点失败）。
图 1. Hadoop 集群的简化视图

存储在 HDFS 中的文件被分成块，然后将这些块复制到多个计算机中（DataNode）。这与传统的 RAID 架构大不相同。块的大小（通常为 64MB）和复制的块数量在创建文件时由客户机决定。NameNode 可以控制所有文件操作。HDFS 内部的所有通信都基于标准的 TCP/IP 协议。

NameNode

NameNode 是一个通常在 HDFS 实例中的单独机器上运行的软件。它负责管理文件系统名称空间和控制外部客户机的访问。NameNode 决定是否将文件映射到 DataNode 上的复制块上。对于最常见的 3 个复制块，第一个复制块存储在同一机架的不同节点上，最后一个复制块存储在不同机架的某个节点上。注意，这里需要您了解集群架构。

实际的 I/O 事务并没有经过 NameNode，只有表示 DataNode 和块的文件映射的元数据经过 NameNode。当外部客户机发送请求要求创建文件时，NameNode 会以块标识和该块的第一个副本的 DataNode IP 地址作为响应。这个 NameNode 还会通知其他将要接收该块的副本的 DataNode。

NameNode 在一个称为 FsImage 的文件中存储所有关于文件系统名称空间的信息。这个文件和一个包含所有事务的记录文件（这里是 EditLog）将存储在 NameNode 的本地文件系统上。FsImage 和 EditLog 文件也需要复制副本，以防文件损坏或 NameNode 系统丢失。

DataNode

NameNode 也是一个通常在 HDFS 实例中的单独机器上运行的软件。Hadoop 集群包含一个 NameNode 和大量 DataNode。DataNode 通常以机架的形式组织，机架通过一个交换机将所有系统连接起来。Hadoop 的一个假设是：机架内部节点之间的传输速度快于机架间节点的传输速度。

DataNode 响应来自 HDFS 客户机的读写请求。它们还响应创建、删除和复制来自 NameNode 的块的命令。NameNode 依赖来自每个 DataNode 的定期心跳（heartbeat）消息。每条消息都包含一个块报告，NameNode 可以根据这个报告验证块映射和其他文件系统元数据。如果 DataNode 不能发送心跳消息，NameNode 将采取修复措施，重新复制在该节点上丢失的块。

文件操作

可见，HDFS 并不是一个万能的文件系统。它的主要目的是支持以流的形式访问写入的大型文件。如果客户机想将文件写到 HDFS 上，首先需要将该文件缓存到本地的临时存储。如果缓存的数据大于所需的 HDFS 块大小，创建文件的请求将发送给 NameNode。NameNode 将以 DataNode 标识和目标块响应客户机。同时也通知将要保存文件块副本的 DataNode。当客户机开始将临时文件发送给第一个 DataNode 时，将立即通过管道方式将块内容转发给副本 DataNode。客户机也负责创建保存在相同 HDFS 名称空间中的校验和（checksum）文件。在最后的文件块发送之后，NameNode 将文件创建提交到它的持久化元数据存储（在 EditLog 和 FsImage 文件）。

Linux 集群

Hadoop 框架可在单一的 Linux 平台上使用（开发和调试时），但是使用存放在机架上的商业服务器才能发挥它的力量。这些机架组成一个 Hadoop 集群。它通过集群拓扑知识决定如何在整个集群中分配作业和文件。Hadoop 假定节点可能失败，因此采用本机方法处理单个计算机甚至所有机架的失败。

Hadoop 的最常见用法之一是 Web 搜索。虽然它不是惟一的软件框架应用程序，但作为一个并行数据处理引擎，它的表现非常突出。Hadoop 最有趣的方面之一是 Map and Reduce 流程，它受到 Google 开发的启发。这个流程称为创建索引，它将 Web 爬行器检索到的文本 Web 页面作为输入，并且将这些页面上的单词的频率报告作为结果。然后可以在整个 Web 搜索过程中使用这个结果从已定义的搜索参数中识别内容。

MapReduce

最简单的 MapReduce 应用程序至少包含 3 个部分：一个 Map 函数、一个 Reduce 函数和一个 main 函数。main 函数将作业控制和文件输入/输出结合起来。在这点上，Hadoop 提供了大量的接口和抽象类，从而为 Hadoop 应用程序开发人员提供许多工具，可用于调试和性能度量等。

MapReduce 本身就是用于并行处理大数据集的软件框架。MapReduce 的根源是函数性编程中的 map 和 reduce 函数。它由两个可能包含有许多实例（许多 Map 和 Reduce）的操作组成。Map 函数接受一组数据并将其转换为一个键/值对列表，输入域中的每个元素对应一个键/值对。Reduce 函数接受 Map 函数生成的列表，然后根据它们的键（为每个键生成一个键/值对）缩小键/值对列表。

这里提供一个示例，帮助您理解它。假设输入域是 one small step for man, one giant leap for mankind。在这个域上运行 Map 函数将得出以下的键/值对列表：

	(one, 1)  (small, 1)  (step, 1)  (for, 1)  (man, 1)
	(one, 1)  (giant, 1)  (leap, 1)  (for, 1)  (mankind, 1)

如果对这个键/值对列表应用 Reduce 函数，将得到以下一组键/值对：

	(one, 2)    (small, 1)  (step, 1)     (for, 2)  (man, 1)
	(giant, 1)  (leap, 1)   (mankind, 1)

结果是对输入域中的单词进行计数，这无疑对处理索引十分有用。但是，现在假设有两个输入域，第一个是 one small step for man，第二个是 one giant leap for mankind。您可以在每个域上执行 Map 函数和 Reduce 函数，然后将这两个键/值对列表应用到另一个 Reduce 函数，这时得到与前面一样的结果。换句话说，可以在输入域并行使用相同的操作，得到的结果是一样的，但速度更快。这便是 MapReduce 的威力；它的并行功能可在任意数量的系统上使用。图 2 以区段和迭代的形式演示这种思想。
图 2. MapReduce 流程的概念流

现在回到 Hadoop 上，它是如何实现这个功能的？一个代表客户机在单个主系统上启动的 MapReduce 应用程序称为 JobTracker。类似于 NameNode，它是 Hadoop 集群中惟一负责控制 MapReduce 应用程序的系统。在应用程序提交之后，将提供包含在 HDFS 中的输入和输出目录。JobTracker 使用文件块信息（物理量和位置）确定如何创建其他 TaskTracker 从属任务。MapReduce 应用程序被复制到每个出现输入文件块的节点。将为特定节点上的每个文件块创建一个惟一的从属任务。每个 TaskTracker 将状态和完成信息报告给 JobTracker。图 3 显示一个示例集群中的工作分布。
图 3. 显示处理和存储的物理分布的 Hadoop 集群

Hadoop 的这个特点非常重要，因为它并没有将存储移动到某个位置以供处理，而是将处理移动到存储。这通过根据集群中的节点数调节处理，因此支持高效的数据处理。

Hadoop 是一个用于开发分布式应用程序的多功能框架；从不同的角度看待问题是充分利用 Hadoop 的好方法。回顾一下 图 2，那个流程以阶梯函数的形式出现，其中一个组件使用另一个组件的结果。当然，它不是万能的开发工具，但如果碰到的问题属于这种情况，那么可以选择使用 Hadoop。

Hadoop 一直帮助解决各种问题，包括超大型数据集的排序和大文件的搜索。它还是各种搜索引擎的核心，比如 Amazon 的 A9 和用于查找酒信息的 Able Grape 垂直搜索引擎。Hadoop Wiki 提供了一个包含大量应用程序和公司的列表，这些应用程序和公司通过各种方式使用 Hadoop（参见 参考资料）。

当前，Yahoo! 拥有最大的 Hadoop Linux 生产架构，共由 10,000 多个内核组成，有超过 5PB 字节的储存分布到各个 DataNode。在它们的 Web 索引内部差不多有一万亿个链接。不过您可能不需要那么大型的系统，如果是这样的话，您可以使用 Amazon Elastic Compute Cloud (EC2) 构建一个包含 20 个节点的虚拟集群。事实上，纽约时报 使用 Hadoop 和 EC2 在 36 个小时内将 4TB 的 TIFF 图像 — 包括 405K 大 TIFF 图像，3.3M SGML 文章和 405K XML 文件 — 转换为 800K 适合在 Web 上使用的 PNG 图像。这种处理称为云计算，它是一种展示 Hadoop 的威力的独特方式。

毫无疑问，Hadoop 正在变得越来越强大。从使用它的应用程序看，它的前途是光明的。您可以从 参考资料 小节更多地了解 Hadoop 及其应用程序，包括设置您自己的 Hadoop 集群的建议。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
• Hadoop core Web 站点是学习 Hadoop 的最好资源。在这里可以找到最新的文档、快速入门指南、教程和设置集群配置的详细信息等。您还可以找到关于在 Hadoop 框架上进行开发的详细应用程序编程接口（API）文档。
• Hadoop DFS User Guide 介绍了 HDFS 及其相关组件。
• Yahoo! 在 2008 年年初为其搜索引擎启动了公认的 最大 Hadoop 集群。这个 Hadoop 集群由 10,000 多个内核组成，提供超过 5PB（相当于 5000,000 千兆字节）的原始磁盘存储。
• “Hadoop: Funny Name, Powerful Software”（LinuxInsider，2008 年 11 月）是一篇关于 Hadoop 的优秀文章，其中包含采访 Doug Cutting 的内容，他是 Hadoop 的创始人。本文还讨论了纽约时报 结合使用 Hadoop 和 Amazon 的 EC2 进行大量图像转换。
• Hadoop 非常适合在云计算环境中使用。要了解关于云计算的更多信息，请查看 “Linux 上的云计算”（developerWorks，2008 年 9 月）。
• 通过 Hadoop Wiki PoweredBy 页面可以看到 使用 Hadoop 的应用程序 的完整列表。除了搜索引擎之外，Hadoop 还能解决许多其他问题。
• “Running Hadoop on Ubuntu Linux (Multi-Node Cluster)” 是一份由 Michael Noll 撰写的教程，它教您设置 Hadoop 集群。本教程还提到了另一本更早的关于如何设置单个节点的教程。
• In the developerWorks Linux 专区 中可以找到为 Linux 开发人员准备的更多参考资料（包括为 Linux 新手准备的 Linux 新手入门），还可以查阅 最受欢迎的文章和教程。
• 在 developerWorks 上查阅所有 Linux 技巧 和 Linux 教程。
• 随时关注 developerWorks 技术活动和网络广播。

http://www.ibm.com/developerworks/cn/linux/l-hadoop/?ca=drs-tp4608

您可能也喜欢：
Hadoop与分布式计算	Hadoop以及hadoop应用	KDD Cup 2012：社交计算和计算广告学	不得不收藏与分享–云计算术语大全	RoBa’s Blog：相似度计算(2)
无觅

相关文章

• Hadoop与分布式计算 (0)
• Hadoop以及hadoop应用 (2)
• 记录两篇Revolutions上的关于R分析Big Data的文章 (1)
• 微软的图数据库系统-Trinity (2)
• 2011 年 IT 行业十大热门技术领域 (0)
• Chrome OS，靠不靠谱？ (7)
• Google更快速更及时搜索 (8)
• 天河一号A：堪称世界第一 (4)
• 不得不收藏与分享–云计算术语大全 (23)
• [新] 互联网潮流与焦点 (6)

Hadoop 由 Apache Software Foundation 公司于 2005 年秋天作为 Lucene 的子项目 Nutch 的一部分正式引入。它受到最先由 Google Lab 开发的 MapReduce 和 Google File System 的启发。2006 年 3 月份，MapReduce 和 Nutch Distributed File System (NDFS) 分别被纳入称为 Hadoop 的项目中。

Hadoop 是最受欢迎的在 Internet 上对搜索关键字进行内容分类的工具，但它也可以解决许多要求极大伸缩性的问题。例如，如果您要 grep 一个 10TB 的巨型文件，会出现什么情况？在传统的系统上，这将需要很长的时间。但是 Hadoop 在设计时就考虑到这些问题，因此能大大提高效率。

搜索技术界，也许有人不熟悉Doug Cutting，但很少有人不知道Lucene这个著名的全文检索引擎。事实上，Lucene应该是Doug Cutting的成名作，它被广泛地应用在各种规模的网站和系统中，甚至Eclipse中的搜索功能也是Lucene来实现的。

但Doug Cutting并没有满足Lucene取得的成绩。2002年，他发起了一个基于Lucene的开源项目Nutch，其目标是构建出一个包括网络蜘蛛、文件存储等模块的网页搜索系统。经过2年的努力，Nutch虽然可以用4台机器支持1亿网页的抓取和检索，但系统的扩展性开始遇到瓶颈。恰在此时，Google发表了GFS、MapReduce的论文，这两个创新性的思路点燃了Nutch 2名开发人员的斗志，他们又花了2年的业余时间实现了DFS（分布式文件系统）和MapReduce机制，这次改造使Nutch可以在20台机器上支持几亿的数据规模，其编程和运维的简易性也得到了大幅提升，但系统的吞吐能力与一个真正的网页搜索系统仍有不小的差距。

2006年，开源社区如火如荼，当美国雅虎在思索构建一个高度利用硬件资源、维护和开发都非常简易的软件架构时，Doug Cutting和他的Nutch进入了他们的视野。一方具有超强的技术前瞻性和实战经验，另一方能提供世界上数一数二的数据、硬件和人力资源，双方一拍即合，同年1月Doug Cutting正式加入雅虎，2月Hadoop从Nutch中分离出来，正式成为Apache组织中一个专注于DFS和MapReduce的开源项目。

2008年2月，又是两年，雅虎宣布搭建出一个世界上最大的基于Hadoop的生产集群系统—Yahoo! Search Webmap（简单地讲，就是雅虎网页搜索抓取的所有站点和网页及其关系的数据库），下面一组数据可以让我们对该系统的规模有个初步的认识：
Ø
页面之间的链接数超过1000亿；
Ø
Webmap输出的压缩数据超过300TB（Terabyte）；
Ø
有单一的MapReduce任务同时在1万多个CPU的核（core）上运行；
Ø
生产集群硬盘空间占用超过5PB（Petabyte）；
Ø
与原来没用Hadoop的方案相比节约了30%的时间。

这时候，可以说Doug Cutting想构建一个Web-scale级别系统的心愿也终于实现了！

Hadoop的系统架构简单地讲，Hadoop是一个可以更容易开发和并行处理大规模数据的分布式计算平台。它的主要特点是：扩容能力（Scalable）、成本低（Economical）、高效率（Efficient）、可靠性（Reliable）。另外，Hadoop是一款完全用Java开发的开源软件，因此它可以运行在多种操作系统和商用硬件上。

Hadoop主要由两部分构成：Hadoop分布式文件系统（HDFS）和MapReduce的实现。
HDFS和MapReduce的关系如下图所示：

MapReduce是依赖于HDFS实现的。通常MapReduce会将被计算的数据分为很多小块，HDFS会将每个块复制若干份以确保系统的可靠性，同时它按照一定的规则将数据块放置在集群中的不同机器上，以便MapReduce在数据宿主机器上进行最便捷的计算。

下面我们再深入一些看看HDFS和MapReduce的实现细节：

HDFS

HDFS设计时基于如下的前提和目标：
1.
硬件错误是常态而不是异常：HDFS可能由成百上千的服务器所构成，每个服务器上存储着文件系统的部分数据。任一组件都有可能失效，这意味着总是有一部分HDFS的组件是不工作的。因此错误检测和快速、自动的恢复是HDFS最核心的架构目标。
2.
流式数据访问：HDFS的设计中更多的考虑到了数据批处理，而不是用户交互处理。比之数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。
3.
大规模数据集：HDFS上的一个典型文件大小一般都在G字节至T字节。因此，HDFS被调节以支持大文件存储，并能提供整体上高的数据传输带宽，能在一个集群里扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。
4.
简单的一致性模型：HDFS应用需要一个“一次写入多次读取“的文件访问模型。文件经过创建、写入和关闭之后就不需要改变。这一假设简化了数据一致性问题，并且使高吞吐量的数据访问成为可能。MapReduce应用或者网络爬虫应用都非常适合这个模型。
5.
移动计算比移动数据更划算：一个应用请求的计算，离它操作的数据越近就越高效，在数据达到海量级别的时候更是如此。因为这样就能降低网络阻塞的影响，提高系统数据的吞吐量。HDFS为应用提供了将计算移动到数据附近的接口。
6.
异构软硬件平台间的可移植性：这种特性方便了HDFS作为大规模数据应用平台的推广。

HDFS的系统架构如下图所示：

HDFS采用Master/Slave架构，一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器，负责管理文件系统的名字空间（Namespace）以及客户端对文件的访问。集群中的Datanode一般是一个节点一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。

从内部看，一个文件其实被分成一个或多个数据块（Block），这些块存储在一组Datanode上。Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录，它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求，在Namenode的统一调度下进行数据块的创建、删除和复制。

单一节点的Namenode大大简化了系统的架构。Namenode负责保管和管理所有的HDFS元数据（Metadata），因而用户数据就不需要通过Namenode（也就是说文件数据的读写是直接在Datanode上）。
从内部看，一个文件其实被分成一个或多个数据块（Block），这些块存储在一组Datanode上。Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录，它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求，在Namenode的统一调度下进行数据块的创建、删除和复制。

单一节点的Namenode大大简化了系统的架构。Namenode负责保管和管理所有的HDFS元数据（Metadata），因而用户数据就不需要通过Namenode（也就是说文件数据的读写是直接在Datanode上）。

MapReduce

MapReduce是一种高效的分布式编程模型，同时是一种用于处理和生成大规模数据集的实现方式。其实，现实世界中很多计算任务都可以用这个模型来表达，熟悉Unix Shell的同学一定写过类似这样的命令行：
~> cat input | grep xxx | sort | uniq -c | cat > output

上面每个管道符中间正好对应了一个典型MapReduce的几个阶段：
Input | Map | Shuffle & Sort | Reduce | Output

下图表明了这几个阶段的工作流及结构关系：

1.
Input：一个Hadoop MapReduce应用通常需要提供一对通过实现合适的接口或抽象类提供的Map和Reduce函数，还应该指明输入/输出的位置（路径）和其他一些运行参数。此外，此阶段还会把输入目录下的大数据文件切分为若干独立的数据块。
2.
Map：MapReduce框架把应用作业的输入看为是一组<key, value> 键值对，在Map这个阶段，框架会调用用户自定义的Map函数处理每一个<key, value> 键值对，生成一批新的中间<key, value> 键值对，这两组键值对的类型可能不同。
3.
Shuffle & Sort：为了保证Reduce的输入是Map排好序的输出。在Shuffle阶段，框架通过HTTP为每个Reduce获得所有Map输出中与之相关的<key, value> 键值对；而在Sort阶段，框架将按照key的值对Reduce的输入进行分组（因为不同map的输出中可能会有相同的key）。通常Shuffle和Sort两个阶段是同时进行的，Reduce的输入也是一边被取回，一边被合并的。
4.
Reduce：此阶段会遍历中间数据，对每一个唯一key，执行用户自定义的Reduce函数（输入参数是<key, (list of values)>），输出是新的<key, value> 键值对。
Output：此阶段会把Reduce输出的结果写入输出目录的文件中。这样，一个典型的MapReduce过程就结束了。
这里需要强调两点：
1.
整个过程中，Hadoop框架负责任务的调度和监控，以及重新执行已经失败的任务。
2.
虽然Hadoop框架是用Java实现的，但MapReduce应用程序则不一定要用 Java来写。比如：Hadoop Streaming是一种运行作业的实用工具，它允许用户创建和运行任何可执行程序（例如：Shell工具）来做为Map和Reduc操作。另外，Hadoop Pipes是一个与SWIG兼容的C++ API（没有基于JNI技术），它也可用于实现Map和Reduc操作。
基于Hadoop的其他开源项目Pig - http://incubator.apache.org/pig/
Pig是Yahoo!捐献给Apache的一个项目，目前还在Apache孵化器（incubator）阶段，目前版本是V0.1.0，但基本功能已经可用了。Pig是一个基于Hadoop的大规模数据分析平台，它提供的SQL-like语言叫Pig Latin，该语言的编译器会把类SQL的数据分析请求转换为一系列经过优化处理的MapReduce运算。Pig为复杂的海量数据并行计算提供了一个简易的操作和编程接口。

ZooKeeper - http://hadoop.apache.org/zookeeper/
ZooKeeper是Hadoop的正式子项目，它是一个针对大型分布式系统的可靠协调系统，提供的功能包括：配置维护、名字服务、分布式同步、组（Group）服务等。ZooKeeper的目标就是封装好这些复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。ZooKeeper的一些思想与Google的Chubby lock service很相似。

HBase - http://hadoop.apache.org/hbase/
HBase也是Hadoop的正式子项目，它是一个面向列的分布式数据库，其思想源于Google的BigTable论文。目前该项目的主要开发人员来自刚被Microsoft收购的Powerset公司。

Mahout - http://lucene.apache.org/mahout/
Mahout是一个利用Map/Reduce的机器学习算法库，其思想源于斯坦福大学的几个学者在06年的nips会议上发表的一篇文章“Map-Reduce for Machine Learning on Multicore”。

Hive - http://mirror.facebook.com/facebook/hive/
Hive是Facebook 08年8月刚开源的一个数据仓库框架，其系统目标与Pig有相似之处，但它有一些Pig目前还不支持的机制，比如：更丰富的类型系统、更类似SQL的查询语言、Table/Partition元数据的持久化。目前，Facebook已经提交了申请，希望Hive成为Hadoop的一个贡献项目（contrib project）。
有谁在用Hadoop？在Yahoo!，Hadoop目前除了被用于网页搜索中的Webmap中，还广泛地被用到Yahoo！的日志分析、广告计算、科研实验中。另外，2007年年底Yahoo!和卡耐基-梅隆大学发起的Open Academic Clusters–M45，至今已经发展为500多台的集群，并完成了多个颇具学术价值的项目。

Amazon的搜索门户A9.com中的商品搜索的索引生成就是基于Hadoop完成的。另外，Amazon最近发布的GrepTheWeb Web Service，内部使用了基于EC2（Elastic Compute Cloud）的Hadoop集群，承担其中的并行计算工作。

著名SNS网站Facebook用Hadoop构建了整个网站的数据仓库，它目前有320多台机器进行网站的日志分析和数据挖掘。此外，在IBM 2007年年底的蓝云计算集群中也采用了Hadoop进行并行计算。
展望必须承认，在Hadoop及其相关的开源项目中，可以看到Google系统架构中核心要素GFS、MapReduce、BigTable、Sawzall、Chubby的身影。因此，从某个角度来说，Hadoop目前还是一个模仿者、跟随者。当大家看到这篇文章时，Hadoop应该已经发布0.18了，从版本号来看，无疑Hadoop还是一只幼年的小飞象，但就是这只看似笨拙的小飞象，却承载着Doug Cutting及其伙伴坚持不懈的努力和造福开源社区的决心。因此，我们有理由相信，在“云计算”时代即将来临之际，Hadoop所营造的一个软件生态系统，必将成为一个最符合“自由、平等和分享”的互联网精神的云计算实践平台。
参考链接1.
Hadoop项目主页：http://hadoop.apache.org/
2.
更多的Hadoop应用案例：http://wiki.apache.org/hadoop/PoweredBy
3.
Yahoo！Hadoop研发团队的Blog：http://developer.yahoo.com/blogs/hadoop

==========================================

 http://blog.csdn.net/zlf0727/archive/2009/03/03/3954068.aspx

您可能也喜欢：
Hadoop与分布式计算	Hadoop在Linux下面进行分布式计算	KDD Cup 2012：社交计算和计算广告学	RoBa’s Blog：相似度计算(2)	Roba's Blog：相似度计算(1)
无觅

相关文章

• Hadoop与分布式计算 (0)
• Hadoop在Linux下面进行分布式计算 (0)