《Hadoop开发者》第二期.pdf

1、 Hadoop 开发者第二期 2010 年 3 月 30 日发布 欢迎投稿 出品 Hadoop 技术论坛 总编辑 易剑 (一见 ) 副总编辑 Barry(beyi) 代志远 (国宝 ) 本期执行主编 Barry(beyi) 编辑 皮冰锋 (若冰 ) 易剑 (一见 ) 贺湘辉 (小米 ) Barry(beyi) 代志远 (国宝 ) 柏传杰 (飞鸿雪泥 ) 何忠育 (Spork) 秘中凯 陈炬 排版 /美工 /封面设计 Barry(beyi) 网址 http:/ 投稿信箱 刊首语 Hadoop 开发者的又一期与大家见面了。 万事开头难，在主编一见成功地推出创刊号后，短短的几天内下载量过千，发布在

2、我个人博客的 hadoop 开发者就有上百人下载，可见， Hadoop 如此受到大家的钟爱，也给予了我们继续下去的动力。Hadoop 开 发者的第二期继续延续着分享、自由、开放这一开源社区的精神传统， 分享 给大家 Hadoop 学 习和 应 用的心得与体会。 Hadoop 应用一直是大家关注而又热衷的话题，这一期里原本打算推出 Hadoop 与搜索引擎这一 主 题，但遗憾的是收到的相关稿件较少， 难以成刊，只好作罢。从稿件质量看来， Hadoop 开发者需要一些更高水 平的稿件，而不能仅仅局限于 Getting Started，更需要Deeply Involved。 办好 Hadoop 开发

3、者 ， 任重而道远， 需要 Hadoop的爱好者的 广泛 参与， 我们在期待大师级文章的 出现 。 Hadoop 开发者第二期 成刊 过程中，我认识了国内某 知 名猎头公司的 “人才猎手 ”Syvia，得知到业界的很多著名 IT 公司 近几年 都在物色 Hadoop 相关的 优秀 技术人才 ， Hadoop 正在或已经引起业界的广泛关注 。有理由可以期待， Hadoop 的未来和应用前景光明。 Hadoop 开发 者 编辑组 本期执行主编： Barry 2010-3 4 目录 1、 Hadoop 业界资讯 . - 1 - 2、 Nutch + Hadoop 构建商用分布式搜索引擎的问题探究 .

4、 - 5 - 3、 支持自定义爬虫的 Nutch segment 文件存储接口改写 . - 11 - 4、 Nutch 中 mapreduce 应用的几个特殊点 . - 14 - 5、 Java RMI + Lucene 构建分布式检索应用初探 . - 17 - 6、 一对多的表关联在 mapreduce 中的应用 (续 ) . - 26 - 7、 InputSplit 文件格式分析 . - 32 - 8、 短评： HDFS、 MapReduce 和 HBase 三者相辅相成、各有长处 . - 34 - 9、 HDFS 在 web 开发中的应用 . - 35 - 10、 Mapreduce 中

5、 value 集合的二次排序 . - 38 - 11、 Hive 手册翻译 . - 47 - 12、 Mahout Kmeans 简介 . - 57 - Hadoop 资讯 Hadoop 开发者 - 1 - Hadoop 业界 资讯 1.InfoWorld 授予 Apache Hadoop 年度技术创新奖章 今年 1 月， InfoWorld 授予 Apache Hadoop 年度技术创新奖章，获奖理由就是 Apache Hadoop 公司创造了使用商用硬件上数千兆数据来运行大规模分析计算功能的可能性。有了Hadoop 和开源 NoSQL 数据库来大幅度减少数据处理时间， 我们就有机会带来游戏

6、行业的变革，因为游戏程序的改动需要进行高度专业的分析。另外，昂贵的硬件和软件资源也可以供更多的专业人才使用。 有可能很多数据的处理过程都将在云上完成，云服务将提供给那些不需要全天候运行大规模计算处理的企业用户。事实上，云本身会有两种方式和开源对接。其一，多用户租赁开源软件成为缺省的软件即服务产品，其二，由谷歌，亚马逊等提供商提供的开放式应用编程接口也会 被很多用户用在开源代码的研发上。虽然这还有一段 适应的过程，但行业中的很多用户看似都能接受这种重新定义。 2.网友观点： SQL 和关系型数据库 -它们并不适合云计算 我参加了在加利福尼亚州圣克拉拉市举行的 2010 年 Cloud Conne

7、ct 大会，这是今年最早举行的云计算重大会议之一。到目前为止，会议一个较大的议题是 “不使用关系型数据库来保持数据的持久性 ”。这被称为 “NoSQL”运动，其宗旨是使用其他形式的数据库，更有效地处理大规模的数据。而关于围绕云计算出现的 “大规模数据 ”，我已经写过一些文章，但是这一运动更为重要，它将推动数据回归到以更简单、但却可能更有效的模型进行物理存储的方式。 NoSQL 系统在运行时一般会把数据存放在内存中，或者是并行地从许多磁盘上读取数据。Hadoop 技术交流论坛 - 2 - 其中就有一个问题， “传统 ”的关系数据库不提供这种模式，因此也没法提供同样的性能。在过去那种数据库中，如

8、果只有几个 GB 数据，这一问题还不是很明显，但是许多云计算的数据库已经超过了 1TB，还会有更多的大规模数据库会被用来支撑不断发展的云计算系统。在关系型数据库上对大规模数据进行操作是兵家大忌，因为在处理数据时 SQL 请求 会占用大量的 CPU周期，并且会导致大量的磁盘读写。 如果你觉得以前好像在哪里听过这种说法，那么我告诉你其实你是对的。早在上世纪 90年代，对象数据库和 XML 数据库就取得过一些进展，尽管那时许多非关系型数据库确实能提供更好的性能，但很多企业却守住了关系型数据库的江山，如 Oracle、 Sybase 和 Informix。然而，由于从关系型数据库上迁移出去的花费和风险

9、太高，而且数据的规模也相对较小，使得关系型数据库几乎一统天下。 不过，云计算改变了一切。在云计算中需要对大量的数据进行处理，这一需求导致新的数据库处理方法 运用在了旧模型上。 MapReduce 是 Hadoop 处理数据的基本方法，它是基于几年前的 “无共享 ”(share-nothing)数据库处理模型，但现在我们有了实现它的处理能力、磁盘空间以及带宽。 我估计云计算的发展将会减少对关系型数据库的使用。这并非新鲜事物，但这回我们却实实在在需要改变了。 3. Twitter：用 Cassandra 取代 MySQL？ 甲骨文收购 Sun 之后， MySQL 的发展前景一直受到各方的密切关注。

10、最近，一些 MySQL长期用户向其他系统迁移的做法，为 MySQL 的未来增加了悲观的预期。 前段时间， Twitter 宣布，将淘汰既有的 MySQL 系统，改用 Cassandra 管理信息。 Cassandra是一个由 Apache 基金资助的分布式开源数据库，主要用于将海量数据分布到大量廉价服务器，进而拼凑出一个无单点故障的信息管理集群。而在 Twitter 之前， Facebook、 Digg 已经开始使Hadoop 资讯 Hadoop 开发者 - 3 - 用 Cassandra，思科的 WebEx 也已使用 Cassandra 来收集用户反馈。 曾几何时， MySQL 作为互联网的

11、宠儿和开源软件旗手，备受各类互联网应用的青睐。但是，随着 Sun 收购 MySQL，它曾经耀眼的光芒慢慢褪 去。对许多用户而言， MySQL 已成为商业性盈利产品，其未来发展存在很大不确定性。另外，随着 Web 2.0 应用的不断扩展，很多企业发现，使用 MySQL 的成本将伴随数据量的膨胀呈指数级增长，集中式数据存储越来越难于达到效率与效益的有机平衡。 除此之外，近期兴起的 No-SQL运动也给 IT行业带来了新的选择。除 Cassandra 外， No- SQL运动的代表还包括 Hadoop、 Google 的 Big Table、 MemCacheDB、 Voldemort、 Couch

12、DB 和MongoDB。在这样的背景下，不仅大型互联网企 业开始放弃包括 MySQL 在内的关系型数据库，即便是一些企业的内部应用，考虑到多媒体、电子邮件、空间和地理信息的增多，也开始采用非关系型数据库方案。 Twitter 官方对 Cassandra 的一些评论似乎更能说明问题。 Twitter 称： Cassandra 不存在单点故障；出身于 Facebook，天生为海量数据设计；适用于大量分布式写操作；依托于一个健康的支持社区。 对于那些建立在关系型数据库之上的系统而言， Cassandra 还提供从其他关系型数据库加载数据的手段，这意味着那些潜在用户可以考虑尝试将其 系统用于 Cass

13、andra，而 Twitter 也正在这么做的。 Twitter 计划让两套系统先并行一段时间，待确定新系统稳定运行后再将 MySQL 淘汰掉。 今天的 MySQL 不得不面临许多问题，它在大型应用领域的采用率较低，同时面临PostgreSQL 的强有力竞争者。另外， MySQL 的草根版本正在茁壮成长，相对于官方的企业版和社区版， MySQL 的分支产品似乎得到了更多的社区支持。不仅如此，收购案并没有真正尘埃落定。尽管目前甲骨文对 Sun 的收购已经获得了美国和欧盟的认可，但能否通过我国和俄罗斯反垄断部门的审查仍需时 日。 4. 互联网两 巨头 PK“云计算 ” Hadoop 技术交流论坛

14、 - 4 - 3 月 28 日消息，由深圳市政府与数字中国联合会共同主办的 2010 中国 (深圳 )IT 领袖峰会今日在深圳五洲宾馆举行，百度 CEO 李彦宏和阿里巴巴主席董事局主席马云就云计算展开了交锋。 李彦宏认为，云计算的理念已经产生了很多年，是新瓶装旧酒，没有新东西。早期的时候，15 年前大家讲客户端跟服务器这个关系，再往后大家讲基于互联网 web 界面的服务，现在讲云计算，实际上本身都是一样，主要活都是在服务器这端来做，客户端所需要做的事情越来越简单。 对于传统软件产业向云计划靠拢，李彦宏表 示担忧，他认为这会存在左手打右手的问题。你说你是微软的 office，你想弄成所有东西都在

15、云端来做，在客户端什么都不要了，这个多多少少有点左手打右手，吃力不讨好的一个情形。 马云不认同李彦宏的观点，他认为云计算最后会是一种分享，数据的处理、存储然后跟分享的机制。他警告说不能小瞧这种机制，云计算可能蕴藏颠覆性力量。我最怕的是老酒装新瓶的东西，你看不清他在玩什么，突然爆发出来最可怕。假如从来没有听说的，这个不可怕。雅虎当年做搜索引擎，然后 Google 出来了，雅虎很多人认为跟我们也差不多，后来几乎把他们搞死。 马云 表示，阿里巴巴对云计算充满了信心，能够为社会创造出更大的价值。我们不是觉得这又找到一个新的矿产，我们阿里巴巴拥有大量消费数据、支付宝交易数据，我们觉得这些数据对我们有用，

16、但是可能对社会更有用，比如我们从小企业的信息掌握到整个中国经济、世界经济的问题，从消费者数据给制造业数据，让他们生产出更好产品卖给消费者。 马云同时暗示，云计算是大势所趋，是阿里巴巴必须要实施的战略。如果能够把这个数据分享给社会，是一个很有用的。如果有一天我们不做这个，百度、腾讯就会把我们赶出电子商务门口。所以这是客户需要，如果我们不做，将 来会死掉。 （声明：以上文章均来自互联网，由 Barry 编辑） 支持自定义爬虫的 Nutch Segment 文件存储读写 Hadoop 开发者 - 5 - Nutch + Hadoop 构建商用分布式搜索引擎的问题探究 （作者： Barry） 1. 题

17、记 众所周知， Nutch 和 hadoop 本是一家，从 0.X 版本开始， Hadoop 从 Nutch 中剥离出来成为一个开源子项目， Hadoop 的初衷是为解决 Nutch的海量数据爬取和存储的需要。相信 Hadoop的 fans 都很清楚， Hadoop 其实并非一个单纯用于存储的分布式文件系统，而是一个被设计用来在由普通硬件设备组成的大型集群上执行分布式应用的框架（ Framework）。 Hadoop 包含两个部分：一个分布式文件系统 HDFS (Hadoop Distributed File System)，和一个 MapReduce 实现。因此， Hadoop 的目标是为开

18、发分布式应用提供一个框架，而不是像 OpenAFS, Coda 那样为存储提供一个分布式文件系统。搜索引擎就是一种典型的分布式程序，而 Nutch 正是基于 Hadoop 开 发的一个应用， Nutch 发展到目前的 1.0 版，确实成熟了不少，这里请允许笔者下一疏浅的定论， Nutch 离商用的海量分布式搜索引擎应用尚有一定的距离。 本文就作者在工作中如何改造 Nutch 以实现支持海量数据检索的分布式应用所遇到的问题一一分享给各位，一些思考或许会贻笑大方，但也无妨，毕竟作者的一些粗浅理解，也是日常工作的一些实践总结，期盼对后来者有所启发。 2. Nutch 工作原理解释 在这里，很容易明确

19、， Nutch 的架构如下图所示。 基于 Nutch 的分布式搜索引擎，其构架可以分割为：分布式爬虫器（ Crawler），分布式文件存储系统（ HDFS）、检索服务系统（ Searcher）四个部分，下面对其进行简要概述，不明白的同仁可详细借鉴 Hadoop 或 Nutch 的 Wiki（在 Hadoop 技术交流群里，我一直提到刚刚接触Hadoop 技术交流论坛 - 6 - hadoop 的新手们，应该先把这两个 wiki 全部读一遍，这里我是这么读过来的，并无他意）。 （ 1）分布式爬虫器的工作流程为： 首先 Crawler 根据 WebDB 生成一个待抓取网页的 URL 集合叫做 F

20、etchlist，接着下载线程Fetcher 开始根据 Fetchlist 将网页抓取回来，如果下载线程 有很多个，那么就生成很多个 Fetchlist，也就是一个 Fetcher 对应一个 Fetchlist。然后 Crawler 根据抓取回来的网页 WebDB 进行更新，根据更新后的 WebDB 生成新的 Fetchlist，里面是未抓取的或者新发现的 URLs，然后下一轮抓取循环重新开始。这个循环过程可以叫做 “产生 /抓取 /更新 ”循环 1。 （ 1 http:/ 在 Nutch 中， Crawler 操作的实现是通过一系列子操作的实现来完成的。这些子操作 Nutch都提供了子命令行

21、可以单独进行调用。下面就是这些子操作的功能描述以及命令行，命令行在括号中。 1) 创建一个新的 WebDb (admin db -create). 2) 将抓取起始 URLs 写入 WebDB 中 (inject). 3) 根据 WebDB 生成 fetchlist 并写入相应的 segment(generate). 4) 根据 fetchlist 中的 URL 抓取网页 (fetch). 5) 根据抓取网页更新 WebDb (updatedb). 6) 循环进行 3 5 步直至预先设定的抓取深度。 7) 根据 WebDB 得到的网页评分和 links 更新 segments (updates

22、egs). 8) 对所抓取的网页进行索引 (index). 9) 在索引中丢弃有重复内容的网页和重复的 URLs (dedup). 10) 将 segments 中的索引进行合并生成用于检索的最终 index(merge). （ 2）分布式文件系统 Nutch 爬取的文件按按块存放在你搭建好的 HDFS 上，其文件目录及其结构如下。 crawldb 目录下面存放下载 的 URL,以及下载的日期，用来页面更新检查时间。 linkdb 目录存放 URL 的关联关系，是下载完成后分析时创建的，通过这个关联关系可以实现类似 google 的 pagerank 功能。 segments 目录存储抓取的页面，下面子目录的个数与获取页面的层数有关系。 Lucene 中的 segment 和 Nutch 中的不同， Lucene 中的 segment 是索引 index 的一部分，但是Nutch 中的 segment 只是 WebDB 中 各个部分网页的内容和索引，最后通过其生成的index 跟这些 segment 已经毫无关系了。 内含有 6 个子目录 ： content：下载页面的内容 crawl_fetch：下载 URL 的状态内容 crawl_generate：待下载的 URL 的集合，在 generate 任务生成时和下载过程中持续分析出来