登入帳戶　 |　訂單查詢　 |　購物車/收銀台(0)　|　在線留言板　 |　付款方式　 |　聯絡我們　 |　運費計算　 |　幫助中心　|　 加入書簽
	全部範圍 - 圖書 - 　- 中文簡體書(大陸書) - 　- 英文書（原版） - - 音碟 - 　- 音樂 - 　- 影視 - - 雜誌 - 全文 精確	會員登入   新用戶註冊

HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類閱讀雜誌

香港／國際用戶

最新/最熱/最齊全的簡體書網

品種：超過100萬種書，正品正价，放心網購，悭钱省心

送貨：速遞 / 物流，時效：出貨後2-4日

新書推薦： 《 千万别喝南瓜汤（遵守规则绘本） 》 售價：NT$ 203.0 《 大模型启示录 》 售價：NT$ 510.0 《 东法西渐：19世纪前西方对中国法的记述与评价 》 售價：NT$ 918.0 《 养育男孩：官方升级版 》 售價：NT$ 230.0 《 小原流花道技法教程 》 售價：NT$ 500.0 《 少女映像室 唯美人像摄影从入门到实战 》 售價：NT$ 505.0 《 詹姆斯·伍德系列：不负责任的自我：论笑与小说（“美国图书评论奖”入围作品 当代重要文学批评家詹姆斯·伍德对“文学中的笑与喜剧”的精湛研究） 》 售價：NT$ 398.0 《 武当内家散手 》 售價：NT$ 230.0

建議一齊購買： + NT$ 573 《 Hadoop大数据分析与挖掘实战 》 + NT$ 573 《 Flume：构建高可用、可扩展的海量日志采集系统 》 + NT$ 490 《 Hadoop YARN权威指南（Hadoop YARN的创建和开发团队亲笔撰写，Altiscale公司CEO作序鼎力推荐，是使用Hadoop YARN建立分布式、大数据应用的权威指南） 》 + NT$ 490 《 Storm分布式实时计算模式（Apache Storm 项目核心贡献者亲笔撰写，涵盖多种分布式计算相关主题，是深入理解Storm分布式实时计算的翔实指南） 》 + NT$ 413 《 MongoDB大数据处理权威指南（第2版）（大数据应用与技术丛书） 》 編輯推薦： 新版新特色，内容更权威，更适合收藏和找Hadoop之父签名儿！ 2014年12月13日中国大数据大会，http:bdtc2014.hadooper.cn 欢迎光临新云南皇冠假日酒店，与Hadoop之父Doug Cutting不见不散！ 內容簡介： 准备好释放数据的强大潜能了吗？借助于这本《Hadoop权威指南》，你将学习如何使用Apache Hadoop构建和维护稳定性高、伸缩性强的分布式系统。本书是为程序员写的，可帮助他们分析任何大小的数据集。本书同时也是为管理员写的，帮助他们了解如何设置和运行Hadoop集群。 本书通过丰富的案例学习来解释Hadoop的幕后机理，阐述了Hadoop如何解决现实生活中的具体问题。第3版覆盖Hadoop的最新动态，包括新增的MapReduce API，以及MapReduce 2及其灵活性更强的执行模型（YARN）。 關於作者： Tom White 数学王子Hadoop专家。身为Apache Hadoop提交者八年之久，Apache软件基金会成员之一。全球知名云计算公司Cloudera的软件工程师。Tom拥有英国剑桥大学数学学士学位和利兹大学科学哲学硕士学位。 【推荐序作者介绍】 Doug Cutting 三大有全球影响力的开源项目之父，Apache软件基金会董事会成员，早年毕业于斯坦福大学。他打造的三大开源项目对企业市场具有重大而深远的影响，其中最著名的当属云计算和大数据领域的明星——Hadoop。 目錄： TOC \o "1-3" \h \z \u 第1章 初识Hadoop.. 1 1.1 数据！数据！... 1 1.2 数据的存储与分析... 3 1.3 相较于其他系统的优势... 4 1.3.1 关系型数据库管理系统... 5 1.3.2 网格计算... 7 1.3.3 志愿计算... 9 1.4 Hadoop发展简史... 10 1.5 Apache Hadoop和Hadoop生态系统.... 14 1.6 Hadoop的发行版本............................................................................................................. 15 1.6.1 本书包含的内容... 16 1.6.2 兼容性... 17 第2章 关于MapReduce.. 19 2.1 气象数据集... 19 2.2 使用Unix工具来分析数据... 21 2.3 使用Hadoop来分析数据... 23 2.3.1 map和reduce. 23 2.3.2 Java MapReduce. 24 2.4 横向扩展... 33 2.4.1 数据流... 34 2.4.2 combiner函数... 37 2.4.3 运行分布式的MapReduce作业... 39 2.5 Hadoop Streaming. 40 2.5.1 Ruby版本... 40 2.5.2 Python版本... 43 2.6 Hadoop Pipes. 44 第3章 Hadoop分布式文件系统.... 49 3.1 HDFS的设计... 49 3.2 HDFS的概念... 51 3.2.1 数据块... 51 3.2.2 namenode和datanode. 52 3.2.3 联邦HDFS. 53 3.2.4 HDFS的高可用性... 54 3.3 命令行接口... 56 3.4 Hadoop文件系统... 58 3.5 Java接口... 62 3.5.1 从Hadoop URL读取数据... 63 3.5.2 通过FileSystem API读取数据... 64 3.5.3 写入数据... 68 3.5.4 目录... 70 3.5.5 查询文件系统... 70 3.5.6 删除数据... 75 3.6 数据流... 75 3.6.1 剖析文件读取... 75 3.6.2 剖析文件写入... 78 3.6.3 一致模型... 81 3.7 通过Flume和Sqoop导入数据... 83 3.8 通过distcp并行复制... 84 3.9 Hadoop存档... 86 3.9.1 使用Hadoop存档工具... 86 3.9.2 不足... 88 第4章 Hadoop的IO操作.... 89 4.1 数据完整性... 89 4.1.1 HDFS的数据完整性... 89 4.1.2 LocalFileSystem.. 91 4.1.3 ChecksumFileSystem.. 91 4.2 压缩... 92 4.2.1 codec. 93 4.2.2 压缩和输入分片... 98 4.2.3 在MapReduce中使用压缩... 99 4.3 序列化... 102 4.3.1 Writable接口... 103 4.3.2 Writable类... 105 4.3.3 实现定制的Writable集合... 114 4.3 序列化框架... 118 4.4 Avro. 121 4.4.1 Avro数据类型和模式... 122 4.4.2 内存中的序列化和反序列化... 126 4.4.3 Avro数据文件... 129 4.4.4 互操作性... 130 4.4.5 模式的解析... 133 4.4.6 排列顺序... 135 4.4.7 关于Avro MapReduce. 137 4.4.8 使用Avro MapReduce进行排序... 141 4.4.9 其他语言的Avro MapReduce. 143 4.5 基于文件的数据结构... 143 4.5.1 关于SequenceFile. 143 4.5.2 关于MapFile. 151 第5章 MapReduce应用开发... 157 5.1 用于配置的API 157 5.1.1 资源合并... 159 5.1.2 可变的扩展... 160 5.2 配置开发环境... 160 5.2.1 管理配置... 162 5.2.2 辅助类GenericOptionsParser，Tool和ToolRunner 165 5.3 用MRUnit来写单元测试... 168 5.3.1 关于Mapper 168 5.3.2 关于Reducer 170 5.4 本地运行测试数据... 171 5.4.1 在本地作业运行器上运行作业... 171 5.4.2 测试驱动程序... 175 5.5 在集群上运行... 176 5.5.1 打包作业... 177 5.5.2 启动作业... 179 5.5.3 MapReduce的Web界面... 181 5.5.4 获取结果... 184 5.5.5 作业调试... 185 5.5.6 Hadoop日志... 190 5.5.7 远程调试... 192 5.6 作业调优... 193 5.7 MapReduce的工作流... 196 5.7.1 将问题分解成MapReduce作业... 197 5.7.2 关于JobControl 198 5.7.3 关于Apache Oozie. 199 第6章 MapReduce的工作机制... 205 6.1 剖析MapReduce作业运行机制... 205 6.1.1 经典的MapReduce MapReduce 1 206 6.1.2 YARN MapReduce 2 213 6.2 失败... 219 6.2.1 经典MapReduce中的失败... 219 6.2.2 YARN中的失败... 222 6.3 作业的调度... 224 6.3.1 公平调度器... 225 6.3.2 容量调度器... 225 6.4 shuffle和排序... 226 6.4.1 map端... 226 6.4.2 reduce端... 228 6.4.3 配置调优... 230 6.5 任务的执行... 232 6.5.1 任务执行环境... 232 6.5.2 推测执行... 233 6.5.3 关于OutputCommitters. 235 6.5.4 任务JVM重用... 237 6.5.5 跳过坏记录... 238 第7章 MapReduce的类型与格式.... 241 7.1 MapReduce的类型... 241 7.1.1 默认的MapReduce作业... 245 7.1.2 默认的Streaming作业... 249 7.2 输入格式... 252 7.2.1 输入分片与记录... 252 7.2.2 文本输入... 264 7.2.3 二进制输入... 268 7.2.4 多个输入... 269 7.2.5 数据库输入和输出 270 7.3 输出格式... 271 7.3.1 文本输出... 271 7.3.2 二进制输出... 272 7.3.3 多个输出... 272 7.3.4 延迟输出... 277 7.3.5 数据库输出... 277 第8章 MapReduce的特性.... 279 8.1 计数器... 279 8.1.1 内置计数器... 279 8.1.2 用户定义的Java计数器... 284 8.1.3 用户定义的Streaming计数器... 289 8.2 排序... 289 8.2.1 准备... 290 8.2.2 部分排序... 291 8.2.3 全排序... 295 8.2.4 辅助排序... 299 8.3 连接... 305 8.3.1 map端连接... 307 8.3.2 reduce端连接... 307 8.4 边数据分布... 311 8.4.1 利用JobConf来配置作业... 311 8.4.2 分布式缓存... 311 8.5 MapReduce库类... 318 第9章 构建Hadoop集群.... 321 9.1 集群规范... 321 9.2 集群的构建和安装... 325 9.2.1 安装Java. 326 9.2.2 创建Hadoop用户... 326 9.2.3 安装Hadoop. 326 9.2.4 测试安装... 327 9.3 SSH配置... 327 9.4 Hadoop配置... 328 9.4.1 配置管理... 329 9.4.2 环境设置... 332 9.4.3 Hadoop守护进程的关键属性... 336 9.4.4 Hadoop守护进程的地址和端口... 341 9.4.5 Hadoop的其他属性... 343 9.4.6 创建用户帐号... 346 9.5 YARN配置... 346 9.5.1 YARN守护进程的重要属性... 347 9.5.2 YARN守护进程的地址和端口... 350 9.6 安全性... 352 9.6.1 Kerberos和Hadoop. 353 9.6.2 委托令牌... 355 9.6.3 其他安全性改进... 356 9.7 利用基准评测程序测试Hadoop集群... 358 9.7.1 Hadoop基准评测程序... 358 9.7.2 用户作业... 361 9.8 云端的Hadoop. 361 第10章 管理Hadoop.. 367 10.1 HDFS. 367 10.1.1 永久性数据结构... 367 10.1.2 安全模式... 373 10.1.3 日志审计... 375 10.1.4 工具... 375 10.2 监控... 380 10.2.1 日志... 381 10.2.2 度量... 382 10.2.3 Java管理扩展JMX 385 10.3 维护... 387 10.3.1 日常管理过程... 387 10.3.2 委任和解除节点... 389 10.3.3 升级... 392 第11章 关于Pig.. 397 11.1 安装与运行Pig. 398 11.1.1 执行类型... 399 11.1.2 运行Pig程序... 400 11.1.3 Grunt 401 11.1.4 Pig Latin编辑器... 401 11.2 示例... 402 11.3 与数据库进行比较... 405 11.4 Pig Latin. 406 11.4.1 结构... 407 11.4.2 语句... 408 11.4.3 表达式... 413 11.4.4 类型... 414 11.4.5 模式... 415 11.4.6 函数... 420 11.4.7 宏... 422 11.5 用户自定义函数... 423 11.5.1 过滤UDF. 423 11.5.2 计算UDF. 427 11.5.3 加载UDF. 429 11.6 数据处理操作... 432 11.6.1 数据的加载和存储... 432 11.6.2 数据的过滤... 433 11.6.3 数据的分组与连接... 436 11.6.4 数据的排序... 441 11.6.5 数据的组合和切分... 442 11.7 Pig实战... 443 11.7.1 并行处理... 443 11.7.2 参数代换... 444 第12章 关于Hive.. 447 12.1 安装Hive. 448 12.2 示例... 450 12.3 运行Hive. 451 12.3.1 配置Hive. 452 12.3.2 Hive服务... 454 12.3.3 Metastore. 456 12.4 Hive与传统数据库相比... 458 12.4.1 读时模式vs.写时模式... 458 12.4.2 更新、事务和索引... 459 12.5 HiveQL. 460 12.5.1 数据类型... 461 12.5.2 操作与函数... 463 12.6 表... 464 12.6.1 托管表和外部表.. 465 12.6.2 分区和桶... 466 12.6.3 存储格式... 471 12.6.4 导入数据... 477 12.6.5 表的修改... 479 12.6.6 表的丢弃... 480 12.7 查询数据... 480 12.7.1 排序和聚集... 480 12.7.2 MapReduce脚本... 481 12.7.3 连接... 482 12.7.4 子查询... 486 12.7.5 视图... 486 12.8 用户定义函数... 488 12.8.1 写UDF. 489 12.8.2 写UDAF. 491 第13章 关于HBase.. 497 13.1 HBase基础... 497 13.2 概念... 498 13.3.1 数据模型的“旋风之旅” 498 13.3.2 实现... 500 13.3 安装... 503 13.4 客户端... 506 13.4.1 Java. 506 13.4.2 Avro、REST和Thrift 510 13.5 示例... 511 13.5.1 模式... 511 13.5.2 加载数据... 512 13.5.3 Web查询... 516 13.6 HBase和RDBMS的比较... 519 13.6.1 成功的服务... 520 13.6.2 HBase. 521 13.6.3 实例：HBase在Streamy.com的使用... 522 13.7 Praxis. 524 13.7.1 版本... 524 13.7.2 HDFS. 525 13.7.3 用户界面... 526 13.7.4 度量... 526 13.7.5 模式的设计... 526 13.7.6 计数器... 527 13.7.7 批量加载... 528 第14章 关于ZooKeeper. 529 14.1 安装和运行ZooKeeper 530 14.2 示例... 532 14.2.1 ZooKeeper中的组成员关系... 533 14.2.2 创建组... 534 14.2.3 加入组... 536 14.2.4 列出组成员... 537 14.2.5 删除组... 539 14.3 ZooKeeper服务... 540 14.3.1 数据模型... 540 14.3.2 操作... 543 14.3.3 实现... 548 14.3.4 一致性... 549 14.3.5 会话... 552 14.3.6 状态... 554 14.4 使用ZooKeeper来构建应用... 555 14.4.1 配置服务... 555 14.4.2 可复原的ZooKeeper应用... 559 14.4.3 锁服务... 563 14.4.4 更多分布式数据结构和协议... 565 14.5 生产环境中的ZooKeeper 567 14.5.1 可恢复性和性能... 567 14.5.2 配置... 568 第15章 关于Sqoop.. 571 15.1 获取Sqoop. 571 15.2 Sqoop连接器... 573 15.3 一个导入的例子... 573 15.4 生成代码... 577 15.5 深入了解数据库导入... 578 15.5.1 导入控制... 580 15.5.2 导入和一致性... 581 15.5.3 直接模式导入... 581 15.6 使用导入的数据... 581 15.7 导入大对象... 585 15.8 执行导出... 587 15.9 深入了解导出功能... 589 15.9.1 导出与事务... 590 15.9.2 导出和SequenceFile. 591 第16章 实例学习.... 593 16.1 Hadoop 在Last.fm的应用... 593 16.1.1 Last.fm：社会音乐史上的革命... 593 16.1.2 Hadoop在Last.fm中的应用... 593 16.1.3 用Hadoop制作图表... 594 16.1.4 Track Statistics程序... 595 16.1.5 总结... 602 16.2 Hadoop和Hive在Facebook的应用... 603 16.2.1 Hadoop在Facebook的使用... 603 16.2.2 虚构的使用样例... 606 16.2.3 Hive. 609 16.2.4 存在的问题与未来工作计划... 613 16.3 Nutch搜索引擎... 615 16.3.1 背景介绍... 615 16.3.2 数据结构... 616 16.3.3 Nutch系统利用Hadoop进行数据处理的精选实例... 619 16.3.4 总结... 630 16.4 Rackspace的日志处理... 631 16.4.1 要求问题... 631 16.4.2 简史... 632 16.4.3 选择Hadoop. 632 16.4.4 收集和存储... 632 16.4.5 对日志的MapReduce处理... 634 16.5 关于Cascading. 640 16.5.1 字段、元组和管道... 641 16.5.2 操作... 644 16.5.3 Tap、Scheme和Flow.. 645 16.5.4 Cascading实战... 646 16.5.5 灵活性... 650 16.5.6 Hadoop和Cascading在ShareThis的应用... 650 16.5.7 总结... 655 16.6 Apache Hadoop上万亿数量级排序... 655 16.7 用Pig和Wukong探索10亿数量级边的网络图... 659 16.7.1 社区判断... 661 16.7.2 每个人都在和我说话：Twitter回复关系图... 661 16.7.3 对称链接... 664 16.7.4 社区提取... 666 附录A 安装Apache Hadoop.. 669 附录B 关于CDH... 675 附录C 准备NCDC气象数据.... 677 rd hd01.doc 內容試閱： 初识Hadoop 在古时候，人们用牛来拉重物。当一头牛拉不动一根圆木时，人们从来没有考虑过要培育更强壮的牛。同理，我们也不该想方设法打造超级计算机，而应该千方百计综合利用更多计算机来解决问题。^ ——格蕾斯·霍珀Grace Hopper 1.1 数据！数据！^ 我们生活在这个数据大爆炸的时代，很难估算全球电子设备中存储的数据总共有多少。国际数据公司IDC曾经发布报告称，2006年数字世界digital universe项目统计得出全球数据总量为0.18ZB并预测在2011年将达到1.8ZB。[1]1ZB等于1021字节，等于1000EBexabytes，1000000PB petabytes，等于大家更熟悉的10亿TBterrabytes！这相当于全世界每人一个硬盘中保存的数据总量！^ 数据“洪流”有很多来源。以下面列出的为例：[2]^ l 纽约证交所每天产生的交易数据多达1 TB^ l 脸谱网Facebook存储的照片约100 亿张，存储容量约为 1 PB^ l 家谱网站Ancestry.com存储的数据约为2.5 PB^ l 互联网档案馆The Internet Archive存储的数据约为2 PB，并以每月至少20 TB的速度持续增长^ l 瑞士日内瓦附近的大型强子对撞机每年产生的数据约为15 PB^ 还有其他大量的数据。但是你可能会想它对自己又有哪些影响呢？地球人都知道，大部分数据都严密锁存在一些大型互联网公司如搜索引擎公司或科学机构与金融机构中。难道所谓的“大数据”只影响小机构和个人？^ 我个人是这样认为的。以照片为例，我妻子的爷爷是一个骨灰级的摄影爱好者。在成年之后，他一直都在拍照。他的整个相册，包括普通胶片、幻灯片、35mm胶片，在扫描成高分辨率的图片之后，大约有10GB。相比之下，在2008年，我家用数码相机拍摄的照片总共有5GB。对照爷爷的照片生成速度，我家是他老人家的35倍！并且，而且这个速度还在不断增长中，因为现在拍照片真的是越来越容易了。^ 有一种情况更普遍，个人产生的数据正在快速增长。微软研究院的MyLifeBits项目[3]http:research.microsoft.comenusprojectsmylifebits default.aspx显示，在不久的将来，个人信息档案将日益普及。MyLifeBits的一个实验是获取和保存个人的对外联系情况包括电话、邮件和文件，供日后存取。收集的数据中包括每分钟拍摄的照片等，数据量每月约为1GB。当存储成本急剧下降以至于可以存储音频和视频时，MyLifeBits项目在未来的存储的数据量将是现在的很多倍。^ 保存个人成长过程中产生的所有数据似乎逐渐成为主流，但更重要的是，计算机产生的数据可能远远超过我们个人所产生的。机器日志、RFID检测仪、传感器网络、车载GPS 和零售交易数据等——所有这些都将产生巨量的数据。^ 在网上公开发布的数据也在逐年增加。组织或企业，要想在未来取得成功，不仅需要管理好自己的数据，更需要从其他组织或企业的数据中获取有价值的信息。^ 这方面的先锋有Amazon Web Serviceshttp:aws.amazon.compublicdatasets、Infochimps.orghttp:infochimps.org和theinfo.orghttp:theinfo.org，它们所发布的共享数据集，正在促进信息共享information commons，供所有人自由下载和分析 或者只需要支付合理的价格通过AWS 平台来共享。不同来源的信息在经过混搭和处理之后，会带来意外的效果和我们今天难以想象的应用。^ 以Astrometry.nethttp:astrometry.net为例，主要查看和分析Flickr网站上星空机器人小组所拍摄的星空照片。它对每一张照片进行分析并能辨别出它来自星空或其他天体例如恒星和银河系等的哪一部分。虽然这项研究尚处于试验阶段，但也表明如果可用的数据足够多在本例中，为加有标签的图片数据，通过它们而产生的后续应用也许会超乎这些拍照片的人最初的想象 图片分析。^ 有句话说得好：“大数据胜于好算法。” 意思是说对于某些应用 譬如根据以往的偏好来推荐电影和音乐，不论算法有多牛，基于小数据的推荐效果往往都不如基于大量可用数据的一般算法的推荐效果。[4]^ 现在，我们已经有了大量数据，这是个好消息。但不幸的是，我们必须想方设法好好地存储和分析这些数据。^ 1.2 数据的存储与分析^ 我们遇到的问题很简单：在硬盘存储容量多年来不断提升的同时，访问速度硬盘数据读取速度却没有与时俱进。1990年，一个普通硬盘可以存储1370 MB数据，传输速度为4.4 MBs[5]，因此只需要5分钟就可以读完整个硬盘中的数据。20年过去了，1TB的硬盘已然成为主流，但其数据传输速度约为100 MBs，读完整个硬盘中的数据至少得花2.5个小时。^ 读完整个硬盘中的数据需要更长时间，写入数据就别提了。一个很简单的减少读取时间的办法是同时从多个硬盘上读数据。试想，如果我们有100个硬盘，每个硬盘存储1%的数据，并行读取，那么不到两分钟就可以读完所有数据。^ 仅使用硬盘容量的1%似乎很浪费。但是我们可以存储100个数据集，每个数据集1 TB，并实现共享硬盘的读取。可以想象，用户肯定很乐于通过硬盘共享来缩短数据分析时间；并且，从统计角度来看，用户的分析工作都是在不同时间点进行的，所以彼此之间的干扰并不太大。^ 虽然如此，但要对多个硬盘中的数据并行进行读写数据，还有更多问题要解决。第一个需要解决的是硬件故障问题。一旦开始使用多个硬件，其中个别硬件就很有可能发生故障。为了避免数据丢失，最常见的做法是复制replication：系统保存数据的复本replica，一旦有系统发生故障，就可以使用另外保存的复本。例如，冗余硬盘阵列RAID就是按这个原理实现的，另外，Hadoop的文件系统HDFS，Hadoop Distributed FileSystem也是一类，不过它采取的方法稍有不同，详见后文的描述。^ 第二个问题是大多数分析任务需要以某种方式结合大部分数据来共同完成分析，即从一个硬盘读取的数据可能需要与从另外99个硬盘中读取的数据结合使用。各种分布式系统允许结合不同来源的数据进行分析，但保证其正确性是一个非常大的挑战。MapReduce提出一个编程模型，该模型抽象出这些硬盘读写问题并将其转换为对一个数据集由键值对组成的计算。后文将详细讨论这个模型，这样的计算由map和reduce两部分组成，而且只有这两部分提供对外的接口。与HDFS类似，MapReduce自身也有很高的可靠性。^ 简而言之，Hadoop为我们提供了一个可靠的共享存储和分析系统。HDFS实现数据的存储，MapReduce实现数据的分析和处理。虽然Hadoop还有其他功能，但HDFS和MapReduce是它的核心价值。^ 1.3 相较于其他系统的优势^ MapReduce看似采用了一种蛮力方法。每个查询需要处理整个数据集或至少一个数据集的绝大部分。但反过来想，这也正是它的能力。MapReduce是一个批量查询处理器，能够在合理的时间范围内处理针对整个数据集的动态查询。它改变了我们对数据的传统看法，解放了以前只是保存在磁带和硬盘上的数据。它让我们有机会对数据进行创新。以前需要很长时间处理才能获得结果的问题，到现在变得顷刻之间就迎刃而解，同时还可以引发新的问题和新的见解。^ 例如，Rackspace公司的邮件部门Mailtrust就用Hadoop来处理邮件日志。他们写动态查询，想借此找出用户的地理分布。他们是这么描述的：“这些数据非常有用，我们每月运行一次MapReduce任务来帮助我们决定哪些Rackspace数据中心需要添加新的邮件服务器。” ^ 通过整合好几百GB的数据，用MapReduce来分析这些数据，Rackspace的工程师从中发现了以前从来没有注意到的数据，甚至还运用这些信息来改善了现有的服务。第16章将详细介绍Rackspace公司内部是如何使用Hadoop的。^ 1.3.1 关系型数据库管理系统^ 为什么不能用数据库来对大量硬盘上的大规模数据进行批量分析呢？我们为什么需要MapReduce？^ 这两个问题的答案来自于计算机硬盘的另一个发展趋势：寻址时间的提升远远不敌于传输速率的提升。寻址是将磁头移动到特定硬盘位置进行读写操作的过程。它是导致硬盘操作延迟的主要原因，而传输速率取决于硬盘的带宽。 如果数据访问模式中包含大量的硬盘寻址，那么读取大量数据集就必然会花更长的时间相较于流数据读取模式，流读取主要取决于传输速率。另一方面，如果数据库系统只更新一小部分记录，那么传统的B树就更有优势关系型数据库中使用的一种数据结构，受限于寻址的比例。但数据库系统如果有大量数据更新时，B树的效率就明显落后于MapReduce，因为需要使用“排序合并“sortmerge来重建数据库。^ 在许多情况下，可以将MapReduce视为关系型数据库管理系统的补充。两个系统之间的差异如表1-1所示。^ MapReduce比较适合以批处理方式处理需要分析整个数据集的问题，尤其是动态分析。RDBMS适用于点查询 point query和更新，数据集被索引之后，数据库系统能够提供低延迟的数据检索和快速的少量数据更新。MapReduce适合一次写入、多次读取数据的应用，关系型数据库则更适合持续更新的数据集。^ 表1-1. 关系型数据库和MapReduce的比较^ 传统的关系型数据库 MapReduce 数据大小 GB PB 数据存取 交互式和批处理 批处理 更新 多次读写 一次写入，多次读取 结构 静态模式 动态模式 完整性 高 低 横向扩展 非线性的 线性的 MapReduce和关系型数据库之间的另一个区别在于它们所操作的数据集的结构化程度。结构化数据structured data是具有既定格式的实体化数据，如XML文档或满足特定预定义格式的数据库表。这是RDBMS包括的内容。另一方面，半结构化数据semi-structured data比较松散，虽然可能有格式，但经常被忽略，所以它只能作为对数据结构的一般性指导。例如电子表格，它在结构上是由单元格组成的网格，但是每个单元格内可以保存任何形式的数据。非结构化数据unstructured data没有什么特别的内部结构，例如纯文本或图像数据。MapReduce对非结构化或半结构化数据非常有效，因为它是在处理数据时才对数据进行解释。换句话说，MapReduce输入的键和值并不是数据固有的属性，而是由分析数据的人来选的。^ 关系型数据往往是规范的normalized，以保持其数据的完整性且不含冗余。规范给MapReduce带来了问题，因为它使记录读取成为非本地操作，而MapReduce的核心假设之一偏偏就是可以进行高速的流读写操作。^ Web服务器日志是典型的非规范化数据记录例如，每次都需要记录客户端主机全名，这会导致同一客户端的全名可能多次出现，这也是MapReduce非常适用于分析各种日志文件的原因之一。^ MapReduce是一种线性的可伸缩编程模型。程序员要写两个函数，分别为map函数和reduce函数，每个函数定义从一个键值对集合到另一个键值对集合的映射。这些函数不必关注数据集及其所用集群的大小，可以原封不动地应用于小规模数据集或大规模的数据集。更重要的是，如果输入的数据量是原来的两倍，那么运行时间也需要两倍。但如果集群是原来的两倍，作业的运行速度却仍然与原来一样快。SQL查询一般不具备该特性。^ 但是，在不久的将来，关系型数据库系统和MapReduce系统之间的差异很可能变得模糊。关系型数据库都开始吸收MapReduce的一些思路如Aster Data的数据库和GreenPlum的数据库，另一方面，基于MapReduce的高级查询语言如Pig和Hive使传统数据库的程序员更容易接受MapReduce系统。[6]^ 1.3.2 网格计算^ 高性能计算High Performance Computing，HPC和网格计算Grid Computing组织多年以来一直在研究大规模数据处理，主要使用类似于消息传递接口Message Passing Interface，MPI的API。从广义上讲，高性能计算采用的方法是将作业分散到集群的各台机器上，这些机器访问存储区域网络SAN所组成的共享文件系统。这比较适用于计算密集型的作业，但如果节点需要访问的数据量更庞大 高达几百GB，MapReduce开始施展它的魔法，很多计算节点就会因为网络带宽的瓶颈问题不得不闲下来等数据。^ MapReduc尽量在计算节点上存储数据，以实现数据的本地快速访问。[7]数据本地化data locality特性是MapReduce的核心特征，并因此而获得良好的性能。意识到网络带宽是数据中心环境最珍贵的资源到处复制数据很容易耗尽网络带宽之后，MapReduce通过显式网络拓扑结构来保留网络带宽。注意，这种排列方式并没有降低MapReduce对计算密集型数据进行分析的能力。^ 虽然MPI赋予程序员很大的控制权，但需要程序员显式控制数据流机制，包括用C语言构造底层的功能模块例如套接字和高层的数据分析算法。而MapReduce则在更高层次上执行任务，即程序员仅从键值对函数的角度考虑任务的执行，而且数据流是隐含的。^ 在大规模分布式计算环境下，协调各个进程的执行是一个很大的挑战。最困难的是合理处理系统的部分失效问题——在不知道一个远程进程是否挂了的情况下——同时还需要继续完成整个计算。有了MapReduce，程序员不必操心系统部分失效的问题，因为它自己的系统实现能够检测到并重新执行那些失败的map或reduce任务。正因为采用的是无共享shared-nothing框架，MapReduce才能够实现失败检测，这意味着各个任务之间是彼此独立的。[8]因此，从程序员的角度来看，任务的执行顺序无关紧要。相比之下，MPI程序必须显式管理自己的检查点和恢复机制，虽然赋予程序员的控制权加大了，但编程的难度也增加了。^ MapReduce听起来似乎是一个相当严格的编程模型，而且在某种意义上看的确如此：限定用户使用有特定关联的键值对，mapper和reducer彼此间的协调非常有限每个mapper将键值对传给reducer。由此，我们自然联想到一个问题：能用这个编程模型做一些有用或实际的事情吗？^ 答案是肯定的。MapReduce由谷歌的工程师开发，用于构建搜索引擎的索引，而且，事实已经证明它能够一次又一次地解决这个问题MapReduce 的灵感来自于传统的函数式编程、分布式计算和数据库社区，但此后，该模型在其他行业还有着很多其他的应用。我们欣喜地发现，有很多算法都可以用 MapReduce来表达，从图像图形分析到各种各样基于图像分析的问题，再到机器学习算法。[9]当然，它也不是包治百病的灵丹妙药，不能解决所有问题，但它真的是一个很通用的数据处理工具。^ 我们将在第16章介绍Hadoop的一些典型应用。^ 1.3.3 志愿计算^ 人们第一次听说Hadoop和MapReduce的时候，经常会问这个问题：“它们和SETI@home有什么不同？”SETI全称为Search for Extra-Terrestrial Intelligence搜索外星智能，项目名称为SETI@homehttp:setiathome.berkeley.edu。在该项目中，志愿者把自己计算机CPU的空闲时间贡献出来分析无线天文望远镜的数据，借此寻找外星智慧生命信号。SETI@home因为拥有庞大的志愿者队伍而非常出名，其他还有“搜索大素数”Great Internet Mersenne Prime Search项目与Folding@home项目了解蛋白质构成及其与疾病之间的关系。^ 志愿计算项目将问题分成很多块，每一块称为一个工作单元work unit，发到世界各地的计算机上进行分析。例如，SETI@home的工作单元是0.35 MB无线电望远镜数据，要对这等大小的数据量进行分析，一台普通计算机需要几个小时或几天时间才能完成。完成分析后，结果发送回服务器，客户端随后再获得另一个工作单元。为防止欺骗，每个工作单元要发送到3台不同的机器上执行，而且收到的结果中至少有两个相同才会被接受。^ 从表面上看，SETI@home与MapReduce好像差不多将问题分解为独立的小块，然后并行进行计算，但事实上还是有很多明显的差异。SETI@home问题是CPU高度密集的，比较适合在全球成千上万台计算机上运行，[10]因为计算所花的时间远远超过工作单元数据的传输时间。也就是说，志愿者贡献的是CPU周期，而不是网络带宽。^ MapReduce有三大设计目标：1为只需要短短几分钟或几个小时就可以完成的作业提供服务；2运行于同一个内部有高速网络连接的数据中心内；3数据中心内的计算机都是可靠的、定制的硬件。相比之下，SETI@home则是在接入互联网的不可信的计算机上长时间运行，这些计算机的网络带宽不同，对数据本地化也没有要求。^ 1.4 Hadoop发展简史^ Hadoop是Apache Lucene创始人Doug Cutting创建的，Lucene是一个应用广泛的文本搜索系统库。Hadoop起源于开源的网络搜索引擎Apache Nutch，它本身也是Lucene项目的一部分。^ Hadoop的得名 Hadoop不是缩写，它是一个生造出来的词。Hadoop之父Doug Cutting这样解释Hadoop的来历： “这个名字是我的小孩给他的毛绒象玩具取的。我的命名标准是好拼读，含义宽泛，不会被用于其他地方。小孩子是这方面的高手。Googol就是小孩子起的名字。” Hadoop的子项目及后续模块所使用的名称也往往与其功能不相关，通常也以大象或其他动物为主题取名例如Pig。较小一些的组件，名称通常都有较好的描述性因此也更流俗。这个原则很好，意味着我们可以望文知义，例如jobtracker[11]，一看就知道它是用来跟踪MapReduce作业的。 从头打造一个网络搜索引擎是一个雄心勃勃的计划，不只是因为写爬虫程序很复杂，更因为必须有一个专职团队来实现——项目中包含许许多多需要随时修改的活动部件。同时，构建这样的系统代价非常高——据Mike Cafarella和Doug Cutting估计，一个支持10亿网页的索引系统，单是硬件上的投入就高达50万美元，另外还有每月高达3万美元的运维费用。[12]不过，他们认为这个工作仍然值得投入，因为它开创的是一个优化搜索引擎算法的平台。^ Nutch项目开始于2002年，一个可以运行的网页爬取工具和搜索引擎系统很快面试。但后来，开发者认为这一架构的灵活性不够，不足以解决数十亿网页的搜索问题。一篇发表于2003年的论文为此提供了帮助，文中描述的是谷歌产品架构，该架构称为“谷歌分布式文件系统”，简称GFS。[13]GFS或类似的架构，可以解决他们在网页爬取和索引过程中产生的超大文件的存储需求。特别关键的是，GFS能够节省系统管理如管理存储节点所花的大量时间。在2004年，他们开始着手做开源版本的实现，即Nutch分布式文件系统NDFS。^ 2004年，谷歌发表论文向全世界介绍他们的MapReduce系统。[14]2005年初，Nutch的开发人员在Nutch上实现了一个MapReduce系统，到年中，Nutch的所有主要算法均完成移植，用MapReduce和NDFS来运行。^ Nutch的NDFS和MapReduce实现不只适用于搜索领域。在2006年2月，开发人员将NDFS和MapReduce移出Nutch形成Lucene的一个子项目，命名为Hadoop。大约在同一时间，Doug Cutting加入雅虎，雅虎为此组织了专门的团队和资源，将Hadoop发展成能够处理Web数据的系统参见后面的补充材料“Hadoop在雅虎“。在2008年2月，雅虎宣布，雅虎搜索引擎使用的索引是在一个拥有1万个内核的Hadoop集群上构建的。[15]^ 2008年1月，Hadoop已成为Apache的顶级项目，证明了它的成功、多样化和生命力。到目前为止，除雅虎之外，还有很多公司在用Hadoop，例如Last.fm、Facebook和《纽约时报》等。第16章和Hadoop 维基页面英文介绍了一些案例http:wiki.apache.orghadoopPoweredBy。^ 《纽约时报》的案例广为流传，他们把1851 年到 1980 年的存档扫描之后得到4TB的文件并用亚马逊的EC2云服务将文件存为PDF格式放到网上共享。[16]整个过程一共使用了100台计算机，所花的时间不到24小时。如果没有亚马逊的按小时付费模式即允许《纽约时报》短期内访问大量机器和Hadoop好用的并发编程模型珠联璧合，这个项目不太可能这么快就启动和完成。^ 2008年4月，Hadoop打破世界纪录，成为最快的TB级数据排序系统。在一个910节点的群集，Hadoop在209 秒内不到3.5分钟完成了对1TB数据的排序，击败了前一年的297秒冠军详情参见15.5节的补充材料“Apache Hadoop的TB级数据处理”。同年11月，谷歌在报告中声称，它的MapReduce对1 TB数据排序只用了68秒。[17]2009年5月本书第1版出版的时候，有报道称雅虎有一个的团队使用 Hadoop对1 TB数据进行排序只花了62秒。^ 从那以后，Hadoop跃升为企业主流的部署系统。在工业界，Hadoop已经是公认的大数据通用存储和分析平台，这一事实主要体现在大量直接使用或者间接辅助Hadoop系统的产品如雨后春笋般大量涌现。一些大公司也发布Hadoop发行版本，包括EMC，IBM，Microsft和Oracle以及一些专注于Hadoop的公司，如Cloudera，Hortonworks[18]和MapR。^ Hadoop在雅虎^ 作者：Owen O’Melly ^ 构建互联网规模的搜索引擎离不开大量的数据，因此也离不开大量的机器来处理巨量的数据。雅虎搜索引擎Yahoo！Search有4个主要组成部分：Crawler，从网页服务器爬取网页；WebMap，构建一个已知网页的链接图；Indexer，为最佳页面构建一个反向索引；Runtime，处理用户的查询。WebMap生成的链接图非常大，大约包括一万亿1012条边每条边代表一个网页链接和一千亿1011个节点每个节点代表不同的网址。创建并分析如此大的图需要大批计算机很多天长时间运行。到2005年初，WebMap用的底层架构Dreadnaught需要重新设计以便日后扩展到更多的节点。^ Dreadnaught从20个节点成功扩展到600个，但需要完全重新设计才能进一步扩大。Dreadnaught与MapReduce在很多方面都很相似，但灵活性更强，结构也更松散。说具体点，一个Dreadnaught作业的每一个片断fragment，也称“分块”都可以输送到下一阶段的各个片段继续执行，排序则是通过库函数来完成的。但实际情形是，大多数WebMap阶段是两两一对，对应于MapReduce。因此，WebMap应用不需要做大量重构操作就可以适应MapReduce。 Eric BaldeschwielerEric14组建了一个小团队，于是我们开始设计并在GFS和MapReduce上用C++来建立一个新框架的原型，并打算用它来取代Dreadnaught。尽管我们的当务之急是需要一个新的WebMap框架，但更清楚的是，建立雅虎搜索引擎批处理平台的标准对我们更重要。使平台更通用以便支持其他用户，才能够更好地实现新平台的均衡性投资。 与此同时，我们也关注在Hadoop当时也是Nutch的一部分及其进展情况。2006年1月，雅虎聘请了Doug Cutting。一个月后，我们决定放弃原型，转而采用 Hadoop。与我们的原型和设计相比，Hadoop的优势在于它已经在20 个节点上实际应用过Nutch。这样一来，我们便能在两个月内搭建一个研究集群并能够以很快的速度帮助我们的客户使用这个新的框架。另一个显著的优点是Hadoop已经开源，比较容易尽管也不是想象的那么容易！从雅虎法务部门获得许可对该开源系统进行进一步研究。因此，我们在2006年初建立了一个200节点的研究集群并暂时搁置WebMap计划，转而为研究用户提供Hadoop支持和优化服务。 Hadoop大事记 2004年 Doug Cutting和Mike Cafarella实现了HDFS和MapReduce的初版 2005年12月 Nutch移植到新框架，Hadoop在20个节点上稳定运行 2006年1月 Doug Cutting加入雅虎 2006年2月 Apache Hadoop项目正式启动，支持MapReduce和HDFS独立发展 2006年2月 雅虎的网格计算团队采用Hadoop 2006年4月 在188个节点上每节点10 GB运行排序测试集需要47.9个小时 2006年5月 雅虎建立了一个300个节点的Hadoop研究集群 2006年5月 在500个节点上运行排序测试集需要42个小时硬件配置比4月份的更好 2006年11月 研究集群增加到600个节点 2006年12月 排序测试集在20个节点上运行1.8个小时，100个节点上运行3.3小时，500个节点上运行5.2小时，900个节点上运行7.8个小时 2007年1月 研究集群增加到900个节点 2007年4月 研究集群增加到两个集群1000个节点 2008年4月 在900个节点上运行1 TB排序测试集仅需209秒，成为全球最快 2008年10月 研究集群每天装载10 TB的数据 2009年3月 17个集群共24 000个节点 2009年4月 在每分钟排序中胜出，59秒内排序500 GB在1400个节点上和173分钟内排序100 TB数据在3400个节点上 [1] Gantz等人2008年3月发表的文章“The Diverse and Exploding Digital Universe”纷繁多样并不断膨胀的数字世界，网址为http:china.emc.comcollateral analyst-reportsexpanding-digital-idc-white-paper.pdf。^ [2] http:www.intelligententerprise.comshowArticle.jhtml?articleID=207800705；http:mashable.com 20081015facebook-10-billion-photos；http:blog.familytreemagazine.cominsider Inside+Ancestrycoms+TopSecret+Data+Center.aspx；http:www.archive.orgaboutfaqs.php； http:www.interactions.orgcms?pid=1027032。^ [3] 编注：更多详细介绍可以参见阮一峰的博客文章“微软的MyLifeBits项目”，网址为http:www.ruanyifeng.comblog200712mylifebits.html。^ [4] 引自Anand Rajaraman发表的文章“Netflix Challenge”Negfix挑战大赛，网址为 http:anand.typepad.comdatawocky200803more-data-usual.html。在这个挑战大赛中，Netflix公司公开自己的用户评分数据，让研究者根据这些数据对用户没有看过的电影预测评分，谁最先比现有系统好10%，谁就能赢得100万美元的奖金。Alon Halevy，Peter Norvig谷歌研究主管和Fernando Pereira在他们的一篇文章中也提出了类似的观点，题为“The Unreasonable Effectiveness of Data”数据的非理性效果，发表于IEEE Intelligent Systems 2009年34月合刊。 [5] 这些规格对应的是希捷的ST-41600n硬盘。 [6]2007年1月，数据库理论专家David J. DeWitt和Michael Stonebraker发表的论文引发一场激烈的口水大战，论文标题为“MapReduce: A major step backwards”MapReduce：一个巨大的倒退，原文可参见http:databasecolumn.vertica.com database-innovationmapreduce a-major-step-backwards，中文版可参考http:wap. oschina.netquestion17793_31108。在文中，他们认为MapReduce不宜取代关系型数据库。许多评论认为这是一种错误的比较，详情可参见Mark C. Chu-Carroll的文章“Databasesare hammers; MapReduce is a screwdriver”如果说数据库是锤子，MapReduce则是螺丝刀，英文版网址为http:scienceblogs.com goodmath200801 databases_are_hammers_mapreduc.php，中文版可以参考http:blog.csdn.net wanghai__articledetails5954108。DeWitt与Stonebraker以“再说MapReduce”一文对其他人的观点进行了阐述，原文可参见http:databasecolumn. vertica.comdatabase-innovationmapreduce-ii，他们对其他人的主要观点进行了阐述。 [7]1998年图灵奖得主Jim Gray在2003年3月发表的“Distributed Computing Economics”分布式计算经济学一文中，率先提出这个结论：数据处理应该在离数据本身比较近的地方进行，因为这样有利于降低成本，尤其是网络带宽消费所造成的成本。原文网址为http:research.microsoft.comappspubsdefault.aspx?id=70001。 [8] 这里讲得太简单了一点，因为MapReduce 系统本身控制着mapper输出结果传给reducer的过程，所以在这种情况下，重新运行reducer比重新运行mapper更要小心，因为reducer需要获取必要的mapper输出结果，如果没有，必须再次运行对应的mapper，重新生成输出结果。 [9] Apache Mahouthttp:mahout.apache.org是一个在Hadoop上运行的机器学习类库例如分类和聚类算法。 [10] 2008年1月，SETI@home发表评论说每天使用320 000台计算机处理300GB数据，同时他们也在做其他的一些数据计算，原文参见http:www.planetary.orgprograms projectssetiathomesetiathome_20080115。 [11] 在本书中我们使用小写的jobtracker来代表实体泛称，用驼峰体JobTracker来表示对Java类的实现。 [12] Mike Cafarella和Doug Cutting在2004年4月发表在ACM Queue上的文章“Building Nutch: Open Source Search”，网址为http:queue.acm.orgdetail.cfm?id=988408。 [13] Sanjay Ghemawat，Howard Gobioff和Shun-Tak Leung在2003年10月发表的文章“The Google File System”，网址为http:labs.google.compapersgfs.html。 [14] 参见Jeffrey Dean和Sanjay Ghemawat 2004年12月发表的文章“MapReduce: Simplified Data Processing on Large Clusters”MapReduce: 大型集群的数据简化处理，网址为http:labs.google.compapers mapreduce.html。 [15] 参见2008年2月19日发表的文章“雅虎发布全球最大的Hadoop产品应用”Yahoo! Lauches World’s Largest Hadoop ProductionApplications，网址为http:developer. yahoo.comblogshadoopposts2008 02yahoo-worlds-largest-production-hadoop。 [16] 参见Derek Gottfrid在 2007年11月1日发表的文章“Self-service, Prorated Super Computing Fun!”自助式比例分配超级计算的乐趣！，网址为http:open.blogs.nytimes. com20071101self-service-prorated-super-computing-fun。 [17] 全文参见2008年11月21日的文章“Sorting 1PB with MapReduce”MapReduce处理1 PB数据，网址为http:googleblog.blogspot.com200811sorting-1pb-with-mapreduce.html。 [18] 编者注：该公司是雅虎的几个核心开发人员创办的，主要提供Hadoop支持和咨询服务，他们已经与微软在2011年建立战略合作关系，帮助微软将Hadoop移植到Wiondows Server和Azure。

書城介紹　 |　合作申請　|　索要書目　 |　新手入門　|　聯絡方式　 |　幫助中心　|　找書說明　 |　送貨方式　|　付款方式	台灣用户　|　香港/海外用户
megBook.com.tw
Copyright (C) 2013 - 2024 （香港）大書城有限公司　All Rights Reserved.