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

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

香港／國際用戶

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

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

送貨：速遞 / EMS，時效：出貨後2-3日

新書推薦： 《 春日喜你 》 售價：NT$ 257.0 《 我们八月见 》 售價：NT$ 215.0 《 东线炼狱 : 德国反坦克兵的东线日记 : 1941—1942 》 售價：NT$ 439.0 《 献给皇帝的礼物：Wedgwood瓷器王国与漫长的十八世纪 》 售價：NT$ 594.0 《 东京札记 》 售價：NT$ 704.0 《 大学问·明代国家权力结构及运行机制 》 售價：NT$ 649.0 《 蹇蹇录：甲午战争外交秘录 》 售價：NT$ 270.0 《 佛教文化十八讲 》 售價：NT$ 418.0

建議一齊購買： + NT$ 359 《 大数据技术基础——基于Hadoop与Spark 》 + NT$ 359 《 Hadoop大数据开发案例教程与项目实战（在线实验+在线自测） 》 + NT$ 569 《 架构探险：轻量级微服务架构（下册） 》 + NT$ 497 《 Python数据分析基础 》 + NT$ 569 《 深度学习与计算机视觉 算法原理、框架应用与代码实现 》 + NT$ 641 《 Kotlin实战 》 編輯推薦： 本书结合理论和实践，由浅入深，全方位介绍了Hadoop 这一高性能的海量数据处理和分析平台。全书5部分24 章，第Ⅰ部分介绍Hadoop 基础知识，第Ⅱ部分介绍MapReduce,第Ⅲ部分介绍Hadoop 的运维，第Ⅳ部分介绍Hadoop 相关开源项目，第Ⅴ部分提供了三个案例，分别来自医疗卫生信息技术服务商塞纳Cerner、微软的人工智能项目ADAM一种大规模分布式深度学习框架和开源项目Cascading一个新的针对MapReduce 的数据处理API。本书是一本专业、全面的Hadoop 参考书和工具书，阐述了Hadoop 生态圈的新发展和应用，程序员可以从中探索海量数据集的存储和分析，管理员可以从中了解Hadoop 集群的安装和运维。 內容簡介： 本书结合理论和实践，由浅入深，全方位介绍了Hadoop这一高性能的海量数据处理和分析平台。全书5部分24章，第Ⅰ部分介绍Hadoop基础知识，主题涉及Hadoop、MapReduce、Hadoop分布式文件系统、YARN、Hadoop的IO操作。第Ⅱ部分介绍MapReduce,主题包括MapReduce应用开发；MapReduce的工作机制、MapReduce的类型与格式、MapReduce的特性。第Ⅲ部分介绍Hadoop的运维，主题涉及构建Hadoop集群、管理Hadoop。第Ⅳ部分介绍Hadoop相关开源项目，主题涉及Avro、Parquet、Flume、Sqoop、Pig、Hive、Crunch、Spark、HBase、ZooKeeper。第Ⅴ部分提供了三个案例，分别来自医疗卫生信息技术服务商塞纳Cerner、微软的人工智能项目ADAM一种大规模分布式深度学习框架和开源项目Cascading一个新的针对MapReduce的数据处理API。 本书是一本权威、全面的Hadoop参考书和工具书，阐述了Hadoop生态圈的*发展和应用，程序员可以从中探索海量数据集的存储和分析，管理员可以从中了解Hadoop集群的安装和运维。 關於作者： 作者简介 Tom White是最杰出的Hadoop专家之一。自2007年2月以来，Tom White一直是ApacheHadoop的提交者committer，也是Apache软件基金会的成员。Tom是Cloudera的软件工程师，他是Cloudera的首批员工，对Apache和Cloudera做出了举足轻重的贡献。在此之前，他是一名独立的Hadoop顾问，帮助公司搭建、使用和扩展Hadoop。他是很多行业大会的专题演讲人，比如ApacheCon、OSCON和Strata。Tom在英国剑桥大学获得数学学士学位，在利兹大学获得科学哲学硕士学位。他目前与家人居住在威尔士。 译者简介 王海博士，解放军理工大学通信工程学院教授，博导，教研中心主任，长期从事无线自组网网络的设计与研发工作，主持国家自然科学基金、国家863计划课题等多项*课题，近5年获军队科技进步二等奖1项，三等奖6项，作为第一发明人申请国家发明专利十余项，发表学术论文50余篇。 作者简介 Tom White是最杰出的Hadoop专家之一。自2007年2月以来，Tom White一直是Apache Hadoop的提交者committer，也是Apache软件基金会的成员。Tom是Cloudera的软件工程师，他是Cloudera的首批员工，对Apache和Cloudera做出了举足轻重的贡献。在此之前，他是一名独立的Hadoop顾问，帮助公司搭建、使用和扩展Hadoop。他是很多行业大会的专题演讲人，比如ApacheCon、OSCON和Strata。Tom在英国剑桥大学获得数学学士学位，在利兹大学获得科学哲学硕士学位。他目前与家人居住在威尔士。 译者简介 王海博士，解放军理工大学通信工程学院教授，博导，教研中心主任，长期从事无线自组网网络的设计与研发工作，主持国家自然科学基金、国家863计划课题等多项*课题，近5年获军队科技进步二等奖1项，三等奖6项，作为第一发明人申请国家发明专利十余项，发表学术论文50余篇。 华东博士，现任南京医科大学计算机教研室教师，一直致力于计算机辅助教学的相关技术研究，陆续开发了人体解剖学网络自主学习考试平台、诊断学自主学习平台和面向执业医师考试的预约化考试平台等系统，并在各个学科得到广泛的使用，获得全国高等学校计算机课件评比一等奖和三等奖各一项。主编、副主编教材两部，获发明专利一项、软件著作权多项。 刘喻博士，长期从事软件开发、软件测试和软件工程化管理工作，目前任教于清华大学软件所。 吕粤海，长期从事军事通信网络技术研究与软件开发工作，先后通过华为光网络高级工程师认证、思科网络工程师认证。 目錄： 第Ⅰ部分 Hadoop基础知识 第1章 初识Hadoop3 1.1 数据！数据！3 1.2 数据的存储与分析5 1.3 查询所有数据6 1.4 不仅仅是批处理7 1.5 相较于其他系统的优势8 1.5.1 关系型数据库管理系统8 1.5.2 网格计算10 1.5.3 志愿计算11 1.6 Apache Hadoop发展简史12 1.7 本书包含的内容16 第2章 关于MapReduce19 2.1 气象数据集19 2.2 使用Unix工具来分析数据21 2.3 使用Hadoop来分析数据22 2.3.1 map和reduce23 2.3.2 Java MapReduce24 2.4 横向扩展31 2.4.1 数据流31 2.4.2 combiner函数35 2.4.3 运行分布式的 MapReduce作业37 2.5 Hadoop Streaming37 2.5.1 Ruby版本38 2.5.2 Python版本40 第3章 Hadoop分布式文件系统42 3.1 HDFS的设计42 3.2 HDFS的概念44 3.2.1 数据块44 3.2.2 namenode和datanode45 3.2.3 块缓存46 3.2.4 联邦HDFS47 3.2.5 HDFS的高可用性47 3.3 命令行接口50 3.4 Hadoop文件系统52 3.5 Java接口56 3.5.1 从Hadoop URL读取 数据56 3.5.2 通过FileSystem API 读取数据58 3.5.3 写入数据61 3.5.4 目录63 3.5.5 查询文件系统63 3.5.6 删除数据68 3.6 数据流68 3.6.1 剖析文件读取68 3.6.2 剖析文件写入71 3.6.3 一致模型74 3.7 通过distcp并行复制76 第4章 关于YARN78 4.1 剖析YARN应用运行机制79 4.1.1 资源请求80 4.1.2 应用生命期81 4.1.3 构建YARN应用81 4.2 YARN与MapReduce 1相比82 4.3 YARN中的调度85 4.3.1 调度选项85 4.3.2 容量调度器配置87 4.3.3 公平调度器配置89 4.3.5 延迟调度93 4.3.5 主导资源公平性94 4.4 延伸阅读95 第5章 Hadoop的IO操作96 5.1 数据完整性96 5.1.1 HDFS的数据完整性97 5.1.2 LocalFileSystem98 5.1.3 ChecksumFileSystem98 5.2 压缩99 5.2.1 codec100 5.2.2 压缩和输入分片105 5.2.3 在MapReduce中使用 压缩106 5.3 序列化109 5.3.1 Writable接口110 5.3.2 Writable类112 5.3.3 实现定制的Writable 集合121 5.3.4 序列化框架125 5.4 基于文件的数据结构127 5.4.1 关于SequenceFile127 5.4.2 关于MapFile135 5.4.3 其他文件格式和 面向列的格式136 第Ⅱ部分 关于MapReduce 第6章 MapReduce应用开发141 6.1 用于配置的API142 6.1.1 资源合并143 6.1.2 变量扩展144 6.2 配置开发环境144 6.2.1 管理配置146 6.2.2 辅助类GenericOptionsParser， Tool和ToolRunner149 6.3 用MRUnit来写单元测试152 6.3.1 关于Mapper152 6.3.2 关于Reducer156 6.4 本地运行测试数据156 6.4.1 在本地作业运行器上 运行作业156 6.4.2 测试驱动程序158 6.5 在集群上运行160 6.5.1 打包作业160 6.5.2 启动作业162 6.5.3 MapReduce的Web 界面165 6.5.4 获取结果167 6.5.5 作业调试168 6.5.6 Hadoop日志171 6.5.7 远程调试173 6.6 作业调优174 6.7 MapReduce的工作流176 6.7.1 将问题分解成 MapReduce作业177 6.7.2 关于JobControl178 6.7.3 关于Apache Oozie179 第7章 MapReduce的工作机制184 7.1 剖析MapReduce作业运行 机制184 7.1.1 作业的提交185 7.1.2 作业的初始化186 7.1.3 任务的分配187 7.1.4 任务的执行188 7.1.5 进度和状态的更新189 7.1.6 作业的完成191 7.2 失败191 7.2.1 任务运行失败191 7.2.2 application master 运行失败193 7.2.3 节点管理器运行失败193 7.2.4 资源管理器运行失败194 7.3 shuffle和排序195 7.3.1 map端195 7.3.2 reduce端197 7.3.3 配置调优199 7.4 任务的执行201 7.4.1 任务执行环境201 7.4.2 推测执行202 7.4.3 关于 OutputCommitters204 第8章 MapReduce的 类型与格式207 8.1 MapReduce的类型207 8.1.1 默认的MapReduce 作业212 8.1.2 默认的Streaming 作业216 8.2 输入格式218 8.2.1 输入分片与记录218 8.2.2 文本输入229 8.2.3 二进制输入233 8.2.4 多个输入234 8.2.5 数据库输入和输出235 8.3 输出格式236 8.3.1 文本输出236 8.3.2 二进制输出237 8.3.3 多个输出237 8.3.4 延迟输出242 8.3.5 数据库输出242 第9章 MapReduce的特性243 9.1 计数器243 9.1.1 内置计数器243 9.1.2 用户定义的Java 计数器248 9.1.3 用户定义的Streaming 计数器251 9.2 排序252 9.2.1 准备252 9.2.2 部分排序253 9.2.3 全排序255 9.2.4 辅助排序259 9.3 连接264 9.3.1 map端连接266 9.3.2 reduce端连接266 9.4 边数据分布270 9.4.1 利用JobConf来配置 作业270 9.4.2 分布式缓存270 9.5 MapReduce库类276 第Ⅲ部分 Hadoop的操作 第10章 构建Hadoop集群279 10.1 集群规范280 10.1.1 集群规模281 10.1.2 网络拓扑282 10.2 集群的构建和安装284 10.2.1 安装Java284 10.2.2 创建Unix 用户账号284 10.2.3 安装Hadoop284 10.2.4 SSH配置285 10.2.5 配置Hadoop286 10.2.6 格式化HDFS 文件 系统286 10.2.7 启动和停止守护 进程286 10.2.8 创建用户目录288 10.3 Hadoop配置288 10.3.1 配置管理289 10.3.2 环境设置290 10.3.3 Hadoop守护进程的 关键属性293 10.3.4 Hadoop守护进程的 地址和端口300 10.3.5 Hadoop的其他属性303 10.4 安全性305 10.4.1 Kerberos和Hadoop306 10.4.2 委托令牌308 10.4.3 其他安全性改进309 10.5 利用基准评测程序测试 Hadoop集群311 10.5.1 Hadoop基准评测 程序311 10.5.2 用户作业313 第11章 管理Hadoop314 11.1 HDFS314 11.1.1 永久性数据结构314 11.1.2 安全模式320 11.1.3 日志审计322 11.1.4 工具322 11.2 监控327 11.2.1 日志327 11.2.2 度量和JMXJava 管理扩展328 11.3 维护329 11.3.1 日常管理过程329 11.3.2 委任和解除节点331 11.3.3 升级334 第Ⅳ部分 Hadoop相关开源项目 第12章 关于Avro341 12.1 Avro数据类型和模式342 12.2 内存中的序列化和 反序列化特定API347 12.3 Avro数据文件349 12.4 互操作性351 12.4.1 Python API351 12.4.2 Avro工具集352 12.5 模式解析352 12.6 排列顺序354 12.7 关于Avro MapReduce356 12.8 使用Avro MapReduce 进行排序359 12.9 其他语言的Avro362 第13章 关于Parquet363 13.1 数据模型364 13.2 Parquet文件格式367 13.3 Parquet的配置368 13.4 Parquet文件的读写369 13.4.1 Avro、Protocol Buffers 和Thrift371 13.4.2 投影模式和读取 模式373 13.5 Parquet MapReduce374 第14章 关于Flume377 14.1 安装Flume378 14.2 示例378 14.3 事务和可靠性380 14.4 HDFS Sink382 14.5 扇出385 14.5.1 交付保证386 14.5.2 复制和复用选择器387 14.6 通过代理层分发387 14.7 Sink组391 14.8 Flume与应用程序的集成395 14.9 组件编目395 14.10 延伸阅读397 第15章 关于Sqoop398 15.1 获取Sqoop398 15.2 Sqoop连接器400 15.3 一个导入的例子401 15.4 生成代码404 15.5 深入了解数据库导入405 15.5.1 导入控制407 15.5.2 导入和一致性408 15.5.3 增量导入408 15.5.4 直接模式导入408 15.6 使用导入的数据409 15.7 导入大对象412 15.8 执行导出414 15.9 深入了解导出功能416 15.9.1 导出与事务417 15.9.2 导出和SequenceFile418 15.10 延伸阅读419 第16章 关于Pig420 16.1 安装与运行Pig421 16.1.1 执行类型422 16.1.2 运行Pig程序423 16.1.3 Grunt424 16.1.4 Pig Latin编辑器424 16.2 示例425 16.3 与数据库进行比较428 16.4 PigLatin429 16.4.1 结构430 16.4.2 语句431 16.4.3 表达式436 16.4.4 类型437 16.4.5 模式438 16.4.6 函数443 16.4.7 宏445 16.5 用户自定义函数446 16.5.1 过滤UDF447 16.5.2 计算UDF450 16.5.3 加载UDF452 16.6 数据处理操作455 16.6.1 数据的加载和存储455 16.6.2 数据的过滤455 16.6.3 数据的分组与连接458 16.6.4 数据的排序463 16.6.5 数据的组合和切分465 16.7 Pig实战465 16.7.1 并行处理465 16.7.2 匿名关系466 16.7.3 参数代换467 16.8 延伸阅读468 第17章 关于Hive469 17.1 安装Hive470 Hive的shell环境471 17.2 示例472 17.3 运行Hive473 17.3.1 配置Hive473 17.3.2 Hive服务476 17.3.3 Metastore478 17.4 Hive与传统数据库相比480 17.4.1 读时模式vs.写时 模式480 17.4.2 更新、事务和索引481 17.4.3 其他SQL-on-Hadoop 技术482 17.5 HiveQL483 17.5.1 数据类型484 17.5.2 操作与函数487 17.6 表488 17.6.1 托管表和外部表488 17.6.2 分区和桶490 17.6.3 存储格式494 17.6.4 导入数据498 17.6.5 表的修改500 17.6.6 表的丢弃501 17.7 查询数据501 17.7.1 排序和聚集501 17.7.2 MapReduce脚本502 17.7.3 连接503 17.7.4 子查询506 17.7.5 视图507 17.8 用户定义函数508 17.8.1 写UDF510 17.8.2 写UDAF512 17.9 延伸阅读516 第18章 关于Crunch517 18.1 示例518 18.2 Crunch核心API521 18.2.1 基本操作522 18.2.2 类型527 18.2.3 源和目标530 18.2.4 函数532 18.2.5 物化535 18.3 管线执行537 18.3.1 运行管线538 18.3.2 停止管线539 18.3.3 查看Crunch计划540 18.3.4 迭代算法543 18.3.5 给管线设置检查点544 18.4 Crunch库545 18.5 延伸阅读547 第19章 关于Spark548 19.1 安装Spark549 19.2 示例549 19.2.1 Spark应用、作业、 阶段和任务551 19.2.2 Scala独立应用552 19.2.3 Java示例553 19.2.4 Python示例554 19.3 弹性分布式数据集555 19.3.1 创建555 19.3.2 转换和动作557 19.3.3 持久化561 19.3.4 序列化563 19.4 共享变量564 19.4.1 广播变量564 19.4.2 累加器565 19.5 剖析Spark作业运行机制565 19.5.1 作业提交566 19.5.2 DAG的构建566 19.5.3 任务调度569 19.5.4 任务执行570 19.6 执行器和集群管理器570 19.7 延伸阅读574 第20章 关于HBase575 20.1 HBase基础575 20.2 概念576 20.2.1 数据模型的 旋风之旅576 20.2.2 实现578 20.3 安装581 20.4 客户端584 20.4.1 Java584 20.4.2 MapReduce588 20.4.3 REST和Thrift589 20.5 创建在线查询应用589 20.5.1 模式设计590 20.5.2 加载数据591 20.5.3 在线查询595 20.6 HBase和RDBMS的比较598 20.6.1 成功的服务599 20.6.2 HBase600 20.7 Praxis601 20.7.1 HDFS601 20.7.2 用户界面602 20.7.3 度量602 20.7.4 计数器602 20.8 延伸阅读602 第21章 关于ZooKeeper604 21.1 安装和运行ZooKeeper605 21.2 示例607 21.2.1 ZooKeeper中的 组成员关系608 21.2.2 创建组608 21.2.3 加入组611 21.2.4 列出组成员612 21.2.5 删除组614 21.3 ZooKeeper服务615 21.3.1 数据模型615 21.3.2 操作618 21.3.3 实现622 21.3.4 一致性624 21.3.5 会话626 21.3.6 状态628 21.4 使用ZooKeeper来构建 应用629 21.4.1 配置服务629 21.4.2 可复原的ZooKeeper 应用633 21.4.3 锁服务637 21.4.4 更多分布式数据 结构和协议639 21.5 生产环境中的ZooKeeper640 21.5.1 可恢复性和性能641 21.5.2 配置642 21.6 延伸阅读643 第Ⅴ部分 案例学习 第22章 医疗公司塞纳Cerner 的可聚合数据647 22.1 从多CPU到语义集成647 22.2 进入Apache Crunch648 22.3 建立全貌649 22.4 集成健康医疗数据651 22.5 框架之上的可组合性654 22.6 下一步655 第23章 生物数据科学： 用软件拯救生命657 23.1 DNA的结构659 23.2 遗传密码：将DNA字符 转译为蛋白质660 22.3 将DNA想象成源代码661 23.4 人类基因组计划和参考 基因组663 22.5 DNA测序和比对664 23.6 ADAM，一个可扩展的 基因组分析平台666 23.7 使用Avro接口描述语言进行 自然语言编程666 23.8 使用Parquet进行面向列的 存取668 23.9 一个简单例子：用Spark和 ADAM做k-mer计数669 23.10 从个性化广告到个性化 医疗672 23.11 联系我们673 第24章 开源项目Cascading674 24.1 字段、元组和管道675 24.2 操作678 24.3 Taps，Schemes和Flows680 24.4 Cascading实践应用681 24.5 灵活性684 24.6 ShareThis中的Hadoop和 Cascading685 24.7 总结689 附录A安装Apache Hadoop691 附录B关于CDH697 附录C准备NCDC气象数据699 附录D新版和旧版Java MapReduce API702 內容試閱： 前言 数学科普作家马丁加德纳Martin Gardner曾经在一次采访中谈到： 在我的世界里，只有微积分。这是我的专栏取得成功的奥秘。我花了很多时间才明白如何以大多数读者都能明白的方式将自己所知道的东西娓娓道来。 这也是我对Hadoop的诸多感受。它的内部工作机制非常复杂，是一个集分布式系统理论、实际工程和常识于一体的系统。而且，对门外汉而言，Hadoop更像是天外来客。 但Hadoop其实并没有那么让人费解，抽丝剥茧，我们来看看它的庐山真面目。Hadoop提供的用于处理大数据的工具都非常简单。如果说这些工具有一个共同的主题，那就是它们更抽象，为有大量数据需要存储和分析却没有足够的时间、技能或者不想成为分布式系统专家的程序员提供一套组件，使其能够利用Hadoop来构建一个处理数据的基础平台。 这样一个简单、通用的特性集，促使我在开始使用Hadoop时便明显感觉到Hadoop真的值得推广。但最开始的时候2006年初，安装、配置和Hadoop应用编程是一门高深的艺术。之后，情况确实有所改善：文档增多了；示例增多了；碰到问题时，可以向大量活跃的邮件列表发邮件求助。对新手而言，最大的障碍是理解Hadoop有哪些能耐，它擅长什么，它如何使用。这些问题使我萌发了写作本书的动机。 Apache Hadoop社区的发展来之不易。从本书的第1版发行以来，Hadoop项目如雨后春笋般发展兴旺。大数据已成为大家耳熟能详的名词术语。当前，软件在可用性、性能、可靠性、可扩展性和可管理性方面都实现了巨大的飞跃。在Hadoop平台上搭建和运行的应用增长迅猛。事实上，对任何一个人来说，跟踪这些发展动向都很困难。但为了让更多的人采用Hadoop，我认为我们要让Hadoop更好用。这需要创建更多新的工具，集成更多的系统，创建新的增强型API。我希望自己能够参与，同时也希望本书能够鼓励并吸引其他人也参与Hadoop项目。 说明 在文中讨论特定的Java类时，我常常会忽略包的名称以免啰嗦杂乱。如果想知道一个类在哪个包内，可以查阅Hadoop或相关项目的Java API 文档ApacheHadoop主页http：hadoop.apache.org上有链接可以访问。如果使用IDE编程，其自动补全机制也称自动完成机制能够帮助你找到你需要的东西。 与此类似，尽管偏离传统的编码规范，但如果要导入同一个包的多个类，程序可以使用星号通配符来节省空间例如import org.apache.hadoop.io.*。 本书中的示例代码可以从本书网站下载，网址为http：www.hadoopbook.com。可以根据网页上的指示获取本书示例所用的数据集以及运行本书示例的详细说明、更新链接、额外的资源与我的博客。 第4版新增内容 第4版的主题是Hadoop2。Hadoop 2系列发行版本是当前应用最活跃的系列，且包含Hadoop的最稳定的版本。 第4版新增的章节包括YARN第4章、Parquet第13章、Flume第14章、Crunch第18章和Spark第19章。此外，为了帮助读者更方便地阅读本书，第1章新增了一节本书包含的内容参见1.7节。 第4版包括两个新的实例学习第22章和第23章：一个是关于Hadoop如何应用于医疗健康系统，另一个是关于将Hadoop技术如何应用于基因数据处理。旧版本中的实例学习可以在线查到，网址为http：bit.lyhadoop_tdg_prev。 为了和Hadoop最新发行版本及其相关项目同步，第4版对原有章节进行了修订、更新和优化。 第3版新增内容 第3版概述Apache Hadoop 1.x以前的0.20系列发行版本，以及新近的0.22和2.x以前的0.23系列。除了少部分文中有说明例外，本书包含的所有范例都在这些版本上运行过。 第3版的大部分范例代码都使用了新的MapReduce API。因为旧的API仍然应用很广，所以文中在讨论新的API时我们还会继续讨论它，使用旧API的对应范例代码可以到本书的配套网站下载。 Hadoop 2.0最主要的变化是新增的MapReduce运行时MapReduce 2，它建立在一个新的分布式资源管理系统之上，该系统称为YARN。针对建立在YARN之上的MapReduce，第3版增加了相关的介绍，包括它的工作机制第7章及如何运行第10章。 第3版还增加了更多对MapReduce的介绍，包括丰富的开发实践，比如用Maven打包MapReduce作业，设置用户的Java类路径，用MRUnit写测试等这些内容都请参见第6章。第3版还深入介绍了一些特性，如输出committer和分布式缓存第9章，任务内存监控第10章。第3版还新增了两小节内容，一节是关于如何写MapReduce作业来处理Avro数据参见第12章，另一节是关于如何在Oozie中运行一个简单的MapReduce工作流参见第6章。 关于HDFS的章节第3章，新增了对高可用性、联邦HDFS、新的WebHDFS和HttpFS文件系统的介绍。 对Pig，Hive，Sqoop和ZooKeeper的相关介绍，第3版全部进行了相应的扩展，广泛介绍其最新发行版本中的新特性和变化。 此外，第3版还对第2版进行了彻底的更新、修订和优化。 第2版新增内容 《Hadoop权威指南》第2版新增两章内容，分别介绍Sqoop和Hive第15章和第17章，新增一个小节专门介绍Avro参见第12章，补充了关于Hadoop新增安全特性的介绍参见第10章以及一个介绍如何使用Hadoop来分析海量网络图的新实例分析。 第2版继续介绍ApacheHadoop0.20系列发行版本，因为当时最新、最稳定的发行版本。书中有时会提到一些最新发行版本中的一些新特性，但在首次介绍这些特性时，有说明具体的Hadoop版本号。 本书采用的约定 本书采用以下排版约定。 斜体 用于表明新的术语、URL、电子邮件地址、文件名和文件扩展名。 等宽字体Consolas 用于程序清单，在正文段落中出现的程序元素如变量或函数名、数据库、数据类型、环境变量、语句和关键字也采用这样的字体。 等宽字体Consolas 加粗 用于显示命令或应该由用户键入的其他文本。 等宽字体Consolas 斜体 表明这里的文本需要替换为用户提供的值或其他由上下文确定的值。 这个图标表示通用的说明。 这个图标表示重要的指示或建议。 这个图标表示警告或需要注意的问题。 示例代码的使用 本书的补充材料（代码、示例及练习等）可以从本书网站http：www.hadoopbook.com或GitHubhttps：github.comtomwhitehadoop-book下载。 本书的目的是帮助读者完成工作。通常情况下，可以在你的程序或文档中使用本书中给出的代码。不必联系我们获得代码使用授权，除非你需要使用大量的代码。例如，在写程序的时候引用几段代码不需要向我们申请许可。但以光盘方式销售或重新发行OReilly书中的示例的确需要获得许可。引用本书或引用本书中的示例代码来回答问题也不需要申请许可。但是，如果要将本书中的大量范例代码加入你的产品文档，则需要申请许可。 我们欣赏你在引用时注明出处，但不强求。引用通常包括书名、作者、出版社和ISBN，如Hadoop： The Definitive Guide, FourthEdition, by Tom WhiteOReilly.Copyright2015Tom White，978-1-491-90163-2。 如果觉得使用示例代码的情况不属于前面列出的合理使用或许可范围，请通过电子邮件联系我们，邮箱地址为permissions@oreilly.com。 SafariBooks Online SafariBooks Onlinewww.safaribooksonline.com是一个按需定制的数字图书馆，以图书和视频的形式提供全球技术领 域和经管领域内知名作者的专业作品。 专业技术人员、软件开发人员、网页设计人员、商务人员和创意专家将Safari Books Online用作自己开展研究、解决问题、学习和完成资格认证培训的重要来源。 Safari Books Online为企业、政府部门、教育机构和个人提供广泛、灵活的计划和定价。 在这里，成员们通过一个可以全文检索的数据库中就能够访问数千种图书、培训视频和正式出版之前的书稿，这些内容提供商有O''Reilly Media、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology及其他上百家出版社。欢迎访问Safari Books Online，了解更多详情。 联系我们 对于本书，如果有任何意见或疑问，请通过以下地址联系出版商： 美国： OReillyMedia,Inc. 1005GravensteinHighwayNorth Sebastopol,CA95472 中国： 北京市西城区西直门南大街2号成铭大厦C座807室100035 奥莱利技术咨询北京有限公司 本书也有相关的网页，我们在上面列出了勘误表、范例以及其他一些信息。网址如下： http：bit.lyhadoop_tdg_4e英文版 http：www.oreilly.com.cnbook.php?bn=978-7-302-46513-3中文版 对本书做出评论或者询问技术问题，请发送E-mail至以下邮箱： bookquestions@oreilly.com 如果希望获得关于本书、会议、资源中心和OReilly的更多信息，请访问以下网址： http：www.oreilly.com http：www.oreilly.com.cn 致谢 在本书写作期间，我仰赖于许多人的帮助，直接的或间接的。感谢Hadoop社区，我从中学到很多，这样的学习仍将继续。 特别感谢Michael Stack和Jonathan Gray，HBase这一章的内容就是他们写的。我还要感谢Adrian Woodhead，Marc de Palol，Joydeep Sen Sarma，Ashish Thusoo，Andrzej Bia?ecki，Stu Hood，Chris K.Wensel和Owen OMalley，他们提供了学习实例。 感谢为草稿提出有用建议和改进建议的评审人：Raghu Angadi，Matt Biddulph，Christophe Bisciglia，Ryan Cox，Devaraj Das，Alex Dorman，Chris Douglas，Alan Gates，Lars George，Patrick Hunt，Aaron Kimball，Peter Krey，Hairong Kuang，Simon Maxen，Olga Natkovich，Benjamin Reed，Konstantin Shvachko，AllenWittenauer，Matei Zaharia和Philip Zeyliger。Ajay Anand组织本书的评审并使其顺利完成。Philipflip Komer帮助我获得了NCDC气温数据，使本书示例很有特色。特别感谢Owen OMalley 和Arun C. Murthy，他们为我清楚解释了MapReduce中shuffle的复杂过程。当然，如果有任何错误，得归咎于我。 对于第2版，我特别感谢Jeff Bean，Doug Cutting，Glynn Durham，Alan Gates，Jeff Hammerbacher，Alex Kozlov，Ken Krugler，Jimmy Lin，Todd Lipcon，Sarah Sproehnle，Vinithra Varadharajan和Ian Wrigley，感谢他们仔细审阅本书，并提出宝贵的建议，同时也感谢对本书第1版提出勘误建议的读者。我也想感谢Aaron Kimball对Sqoop所做的贡献和PhilipflipKromer对图处理实例分析所做的贡献。 对于第3版，我想感谢Alejandro Abdelnur，Eva Andreasson，Eli Collins，Doug Cutting，Patrick Hunt，Aaron Kimball，AaronT. Myers，Brock Noland，Arvind Prabhakar，Ahmed Radwan和Tom Wheeler，感谢他们的反馈意见和建议。Rob Weltman友善地对整本书提出了非常详细的反馈意见，这些意见和建议使得本书终稿的质量得以更上一层楼。此外，我还要向提交第2版勘误的所有读者表达最真挚的谢意。 对于第4版，我想感谢Jodok Batlogg，Meghan Blanchette，Ryan Blue，Jarek Jarcec Cecho，Jules Damji，Dennis Dawson，Matthew Gast，Karthik Kambatla，Julien Le Dem，Brock Noland，Sandy Ryza，Akshai Sarma，Ben Spivey，Michael Stack，Kate Ting，Josh Walter，Josh Wills和Adrian Woodhead，感谢他们所有人非常宝贵的审阅反馈。Ryan Brush，Micah Whitacre和Matt Massie kindly为第4版友情提供新的实例学习。再次感谢提交勘误的所有读者。 特别感谢Doug Cutting对我的鼓励、支持、友谊以及他为本书所写的序。 我还要感谢在本书写作期间以对话和邮件方式进行交流的其他人。 在本书第1版写到一半的时候，我加入了Cloudera，我想感谢我的同事，他们为我提供了大量的帮助和支持，使我有充足的时间好好写书，并能及时交稿。 非常感谢我的编辑Mike Loukides、Meghan Blanchette及其OReillyMedia的同事，他们在本书的准备阶段为我提供了很多帮助。Mike和Meghan一直为我答疑解惑、审读我的初稿并帮助我如期完稿。 最后，写作是一项艰巨的任务，如果没有家人一如既往地支持，我是不可能完成这本的。我的妻子Eliane，她不仅操持着整个家庭，还协助我，参与本书的审稿、编辑和跟进案例学习。还有我的女儿Emilia和Lottie，她们一直都非常理解并支持我的工作，我期待有更多时间好好陪陪她们。 第3章 Hadoop分布式文件系统 当数据集的大小超过一台独立的物理计算机的存储能力时，就有必要对它进行分区partition并存储到若干台单独的计算机上。管理网络中跨多台计算机存储的文件系统称为分布式文件系统distributed filesystem。该系统架构于网络之上，势必会引入网络编程的复杂性，因此分布式文件系统比普通磁盘文件系统更为复杂。例如，使文件系统能够容忍节点故障且不丢失任何数据，就是一个极大的挑战。 Hadoop自带一个称为HDFS的分布式文件系统，即Hadoop Distributed Filesystem。在非正式文档或旧文档以及配置文件中，有时也简称为DFS，它们是一回事儿。HDFS是Hadoop的旗舰级文件系统，也是本章的重点，但实际上Hadoop是一个综合性的文件系统抽象，因此接下来我们将了解将Hadoop与其他存储系统集成的途径，例如本地文件系统和Amazon S3系统。 3.1 HDFS的设计 HDFS以流式数据访问模式来存储超大文件，运行于商用硬件集群上。①让我们仔细看看下面的描述。 * 超大文件 超大文件在这里指具有几百MB、几百GB甚至几百TB大小的文件。目前已经有存储PB级数据的Hadoop 集群了。② * 流式数据访问 HDFS的构建思路是这样的：一次写入、多次读取是最高效的访问模式。数据集通常由数据源生成或从数据源复制而来，接着长时间在此数据集上进行各种分析。每次分析都将涉及该数据集的大部分数据甚至全部，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要。 * 商用硬件 Hadoop并不需要运行在昂贵且高可靠的硬件上。它是设计运行在商用硬件在各种零售店都能买到的普通硬件③的集群上的，因此至少对于庞大的集群来说，节点故障的几率还是非常高的。HDFS遇到上述故障时，被设计成能够继续运行且不让用户察觉到明显的中断。 同样，那些不适合在HDFS上运行的应用也值得研究。目前HDFS对某些应用领域并不适合，不过以后可能会有所改进。 * 低时间延迟的数据访问 要求低时间延迟数据访问的应用，例如几十毫秒范围，不适合在HDFS上运行。记住，HDFS是为高数据吞吐量应用优化的，这可能会以提高时间延迟为代价。目前，对于低延迟的访问需求，HBase参见第20 章是更好的选择。 * 大量的小文件 由于namenode将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于namenode的内存容量。根据经验，每个文件、目录和数据块的存储信息大约占150字节。因此，举例来说，如果有一百万个文件，且每个文件占一个数据块，那至少需要300 MB 的内存。尽管存储上百万个文件是可行的，但是存储数十亿个文件就超出了当前硬件的能力。④ * 多用户写入，任意修改文件 HDFS中的文件写入只支持单个写入者，而且写操作总是以只添加方式在文件末尾写数据。它不支持多个写入者的操作，也不支持在文件的任意位置进行修改。可能以后会支持这些操作，但它们相对比较低效。 3.2 HDFS的概念 3.2.1 数据块 每个磁盘都有默认的数据块大小，这是磁盘进行数据读写的最小单位。构建于单个磁盘之上的文件系统通过磁盘块来管理该文件系统中的块，该文件系统块的大小可以是磁盘块的整数倍。文件系统块一般为几千字节，而磁盘块一般为512字节。这些信息文件系统块大小对于需要读写文件的文件系统用户来说是透明的。尽管如此，系统仍然提供了一些工具如df和fsck来维护文件系统，由它们对文件系统中的块进行操作。 HDFS同样也有块block的概念，但是大得多，默认为128 MB。与单一磁盘上的文件系统相似，HDFS上的文件也被划分为块大小的多个分块chunk，作为独立的存储单元。但与面向单一磁盘的文件系统不同的是，HDFS中小于一个块大小的文件不会占据整个块的空间例如，当一个 1MB的文件存储在一个128 MB 的块中时，文件只使用1 MB的磁盘空间，而不是128 MB。如果没有特殊指出，本书中提到的块特指HDFS中的块。 HDFS中的块为什么这么大？ HDFS的块比磁盘的块大，其目的是为了最小化寻址开销。如果块足够大，从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。因而，传输一个由多个块组成的大文件的时间取决于磁盘传输速率。 我们来做一个速算，如果寻址时间约为10 ms，传输速率为100 MBs，为了使寻址时间仅占传输时间的1%，我们要将块大小设置约为100 MB。默认的块大小实际为128 MB，但是很多情况下HDFS安装时使用更大的块。以后随着新一代磁盘驱动器传输速率的提升，块的大小会被设置得更大。 但是这个参数也不会设置得过大。MapReduce中的map任务通常一次只处理一个块中的数据，因此如果任务数太少少于集群中的节点数量，作业的运行速度就会比较慢。 对分布式文件系统中的块进行抽象会带来很多好处。第一个最明显的好处是，一个文件的大小可以大于网络中任意一个磁盘的容量。文件的所有块并不需要存储在同一个磁盘上，因此它们可以利用集群上的任意一个磁盘进行存储。事实上，尽管不常见，但对于整个HDFS集群而言，也可以仅存储一个文件，该文件的块占满集群中所有的磁盘。 第二个好处是，使用抽象块而非整个文件作为存储单元，大大简化了存储子系统的设计。简化是所有系统的目标，但是这对于故障种类繁多的分布式系统来说尤为重要。将存储子系统的处理对象设置为块，可简化存储管理由于块的大小是固定的，因此计算单个磁盘能存储多少个块就相对容易。同时也消除了对元数据的顾虑块只是要存储的大块数据，而文件的元数据，如权限信息，并不需要与块一同存储，这样一来，其他系统就可以单独管理这些元数据。 不仅如此，块还非常适合用于数据备份进而提供数据容错能力和提高可用性。将每个块复制到少数几个物理上相互独立的机器上默认为3个，可以确保在块、磁盘或机器发生故障后数据不会丢失。如果发现一个块不可用，系统会从其他地方读取另一个复本，而这个过程对用户是透明的。一个因损坏或机器故障而丢失的块可以从其他候选地点复制到另一台可以正常运行的机器上，以保证复本的数量回到正常水平参见5.1节对数据完整性的讨论，进一步了解如何应对数据损坏。同样，有些应用程序可能选择为一些常用的文件块设置更高的复本数量进而分散集群中的读取负载。 与磁盘文件系统相似，HDFS中fsck指令可以显示块信息。例如，执行以下命令将列出文件系统中各个文件由哪些块构成，详情可以参见11.1.4节对文件系统检查fsck的讨论： % hdfs fsck -files -blocks 3.2.2 namenode和datanode HDFS集群有两类节点以管理节点-工作节点模式运行，即一个namenode管理节点和多个datanode工作节点。namenode管理文件系统的命名空间。它维护着文件系统树及整棵树内所有的文件和目录。这些信息以两个文件形式永久保存在本地磁盘上：命名空间镜像文件和编辑日志文件。namenode也记录着每个文件中各个块所在的数据节点信息，但它并不永久保存块的位置信息，因为这些信息会在系统启动时根据数据节点信息重建。 客户端client代表用户通过与namenode和datanode交互来访问整个文件系统。客户端提供一个类似于POSIX可移植操作系统界面的文件系统接口，因此用户在编程时无需知道namenode和datanode也可实现其功能。 datanode是文件系统的工作节点。它们根据需要存储并检索数据块受客户端或namenode调度，并且定期向namenode发送它们所存储的块的列表。 没有namenode，文件系统将无法使用。事实上，如果运行namenode服务的机器毁坏，文件系统上所有的文件将会丢失，因为我们不知道如何根据datanode的块重建文件。因此，对namenode实现容错非常重要，Hadoop为此提供两种机制。 第一种机制是备份那些组成文件系统元数据持久状态的文件。Hadoop可以通过配置使namenode在多个文件系统上保存元数据的持久状态。这些写操作是实时同步的，且是原子操作。一般的配置是，将持久状态写入本地磁盘的同时，写入一个远程挂载的网络文件系统NFS。 另一种可行的方法是运行一个辅助namenode，但它不能被用作namenode。这个辅助namenode的重要作用是定期合并编辑日志与命名空间镜像，以防止编辑日志过大。这个辅助namenode一般在另一台单独的物理计算机上运行，因为它需要占用大量CPU时间，并且需要与namenode一样多的内存来执行合并操作。它会保存合并后的命名空间镜像的副本，并在namenode发生故障时启用。但是，辅助namenode保存的状态总是滞后于主节点，所以在主节点全部失效时，难免会丢失部分数据。在这种情况下，一般把存储在NFS上的namenode元数据复制到辅助namenode并作为新的主namenode运行。注意，也可以运行热备份namenode代替运行辅助namenode，具体参见3.2.5节对HDFS高可用性的讨论。 关于文件系统镜像和编辑日志的更多讨论，请参见11.1.1节。 3.2.3 块缓存 通常datanode从磁盘中读取块，但对于访问频繁的文件，其对应的块可能被显式地缓存在datanode的内存中，以堆外块缓存off-heap block cache的形式存在。默认情况下，一个块仅缓存在一个datanode的内存中，当然可以针每个文件配置datanode的数量。作业调度器用于MapReduce、Spark和其他框架的通过在缓存块的datanode上运行任务，可以利用块缓存的优势提高读操作的性能。例如，连接join操作中使用的一个小的查询表就是块缓存的一个很好的候选。 用户或应用通过在缓存池cache pool中增加一个cache directive来告诉namenode需要缓存哪些文件及存多久。缓存池是一个用于管理缓存权限和资源使用的管理性分组。 3.2.4 联邦HDFS namenode在内存中保存文件系统中每个文件和每个数据块的引用关系，这意味着对于一个拥有大量文件的超大集群来说，内存将成为限制系统横向扩展的瓶颈参见10.3.2节。在2.x发行版本系列中引入的联邦HDFS允许系统通过添加namenode实现扩展，其中每个namenode管理文件系统命名空间中的一部分。例如，一个namenode可能管理user目录下的所有文件，而另一个namenode可能管理share目录下的所有文件。 在联邦环境下，每个namenode维护一个命名空间卷namespace volume，由命名空间的元数据和一个数据块池block pool组成，数据块池包含该命名空间下文件的所有数据块。命名空间卷之间是相互独立的，两两之间并不相互通信，甚至其中一个namenode的失效也不会影响由其他namenode维护的命名空间的可用性。数据块池不再进行切分，因此集群中的datanode需要注册到每个namenode，并且存储着来自多个数据块池中的数据块。 要想访问联邦HDFS集群，客户端需要使用客户端挂载数据表将文件路径映射到namenode。该功能可以通过ViewFileSystem和viewfs：URI进行配置和管理。 3.2.5 HDFS的高可用性 通过联合使用在多个文件系统中备份namenode的元数据和通过备用namenode创建监测点能防止数据丢失，但是依旧无法实现文件系统的高可用性。namenode 依旧存在单点失效SPOF, single point of failure的问题。如果namenode失效了，那么所有的客户端，包括MapReduce作业，均无法读、写或列举list文件，因为namenode是唯一存储元数据与文件到数据块映射的地方。在这一情况下，Hadoop系统无法提供服务直到有新的namenode上线。 在这样的情况下，要想从一个失效的namenode恢复，系统管理员得启动一个拥有文件系统元数据副本的新的namenode，并配置datanode和客户端以便使用这个新的namenode。新的namenode直到满足以下情形才能响应服务：1将命名空间的映像导入内存中；2重演编辑日志；3接收到足够多的来自datanode的数据块报告并退出安全模式。对于一个大型并拥有大量文件和数据块的集群，namenode的冷启动需要30分钟，甚至更长时间。 系统恢复时间太长，也会影响到日常维护。事实上，预期外的namenode失效出现概率很低，所以在现实中，计划内的系统失效时间实际更为重要。 Hadoop2针对上述问题增加了对HDFS高可用性HA的支持。在这一实现中，配置了一对活动-备用active-standby namenode。当活动namenode失效，备用namenode就会接管它的任务并开始服务于来自客户端的请求，不会有任何明显中断。实现这一目标需要在架构上做如下修改。 * namenode之间需要通过高可用共享存储实现编辑日志的共享。当备用namenode接管工作之后，它将通读共享编辑日志直至末尾，以实现与活动namenode的状态同步，并继续读取由活动namenode写入的新条目。 * datanode需要同时向两个namenode发送数据块处理报告，因为数据块的映射信息存储在namenode的内存中，而非磁盘。 * 客户端需要使用特定的机制来处理namenode的失效问题，这一机制对用户是透明的。 * 辅助namenode的角色被备用namenode所包含，备用namenode为活动的namenode命名空间设置周期性检查点。 可以从两种高可用性共享存储做出选择：NFS过滤器或群体日志管理器QJM，quorum journal manager。QJM是一个专用的HDFS实现，为提供一个高可用的编辑日志而设计，被推荐用于大多数HDFS部署中。QJM以一组日志节点journal node的形式运行，每一次编辑必须写入多数日志节点。典型的，有三个journal节点，所以系统能够忍受其中任何一个的丢失。这种安排与ZooKeeper的工作方式类似，当然必须认识到，QJM的实现并没使用ZooKeeper。然而，值得注意的是，HDFS HA在选取活动的namenode时确实使用了ZooKeeper技术，详情参见下一章。 在活动namenode失效之后，备用namenode能够快速几十秒的时间实现任务接管，因为最新的状态存储在内存中：包括最新的编辑日志条目和最新的数据块映射信息。实际观察到的失效时间略长一点需要1分钟左右，这是因为系统需要保守确定活动namenode是否真的失效了。 在活动namenode失效且备用namenode也失效的情况下，当然这类情况发生的概率非常低，管理员依旧可以声明一个备用namenode并实现冷启动。这类情况并不会比非高可用non-HA的情况更差，并且从操作的角度讲这是一个进步，因为上述处理已是一个标准的处理过程并植入Hadoop中。 故障切换与规避 系统中有一个称为故障转移控制器failover controller的新实体，管理着将活动namenode转移为备用namenode的转换过程。有多种故障转移控制器，但默认的一种是使用了ZooKeeper来确保有且仅有一个活动namenode。每一个namenode运行着一个轻量级的故障转移控制器，其工作就是监视宿主namenode是否失效通过一个简单的心跳机制实现并在namenode失效时进行故障切换。 管理员也可以手动发起故障转移，例如在进行日常维护时。这称为平稳的故障转移graceful failover，因为故障转移控制器可以组织两个namenode有序地切换角色。 但在非平稳故障转移的情况下，无法确切知道失效namenode是否已经停止运行。例如，在网速非常慢或者网络被分割的情况下，同样也可能激发故障转移，但是先前的活动namenode依然运行着并且依旧是活动namenode。高可用实现做了更进一步的优化，以确保先前活动的namenode不会执行危害系统并导致系统崩溃的操作，该方法称为规避fencing。 同一时间QJM仅允许一个namenode向编辑日志中写入数据。然而，对于先前的活动namenode而言，仍有可能响应并处理客户过时的读请求，因此，设置一个SSH规避命令用于杀死namenode的进程是一个好主意。当使用NFS过滤器实现共享编辑日志时，由于不可能同一时间只允许一个namenode写入数据这也是为什么推荐QJM的原因，因此需要更有力的规避方法。规避机制包括：撤销namenode访问共享存储目录的权限（通常使用供应商指定的NFS命令）、通过远程管理命令屏蔽相应的网络端口。诉诸的最后手段是，先前活动namenode可以通过一个相当形象的称为一枪爆头STONITH，shoot the other node in the head的技术进行规避，该方法主要通过一个特定的供电单元对相应主机进行断电操作。 客户端的故障转移通过客户端类库实现透明处理。最简单的实现是通过客户端的配置文件实现故障转移的控制。HDFS URI使用一个逻辑主机名，该主机名映射到一对namenode地址在配置文件中设置，客户端类库会访问每一个namenode地址直至处理完成。 3.3 命令行接口 现在我们通过命令行交互来进一步认识HDFS。HDFS还有很多其他接口，但命令行是最简单的，同时也是许多开发者最熟悉的。 参照附录A中伪分布模式下设置Hadoop的说明，我们先在一台机器上运行HDFS。稍后介绍如何在集群上运行HDFS，以提供可扩展性与容错性。 在我们设置伪分布配置时，有两个属性项需要进一步解释。第一项是fs.defaultFS，设置为hdfs：localhost，用于设置Hadoop的默认文件系统。⑤文件系统是由URI指定的，这里我们已使用hdfs URI来配置HDFS为Hadoop的默认文件系统。HDFS的守护程序通过该属性项来确定HDFS namenode的主机及端口。我们将在localhost默认的HDFS端口8020上运行namenode。这样一来，HDFS客户端可以通过该属性得知namenode在哪里运行进而连接到它。 第二个属性dfs.replication，我们设为1，这样一来，HDFS就不会按默认设置将文件系统块复本设为3。在单独一个datanode上运行时，HDFS无法将块复制到3个datanode上，所以会持续给出块复本不足的警告。设置这个属性之后，上述问题就不会再出现了。 文件系统的基本操作 至此，文件系统已经可以使用了，我们可以执行所有常用的文件系统操作，例如，读取文件，新建目录，移动文件，删除数据，列出目录，等等。可以输入hadoop fs -help命令获取每个命令的详细帮助文件。 首先从本地文件系统将一个文件复制到HDFS： % hadoop fs -copyFromLocal inputdocsquangle.txt \ hdfs：localhostusertomquangle.txt 该命令调用Hadoop文件系统的shell命令fs，后者提供了一系列子命令，在这个例子中，我们执行的是-copyFromLocal。本地文件quangle.txt被复制到运行在localhost上的 HDFS实例中，路径为usertomquangle.txt。事实上，我们可以简化命令格式以省略主机的URI并使用默认设置，即省略hdfs：localhost，因为该项已在core-site.xml中指定。 % hadoop fs -copyFromLocal inputdocsquangle.txt usertomquangle.txt 我们也可以使用相对路径，并将文件复制到HDFS的home目录中，本例中为usertom： % hadoop fs -copyFromLocal inputdocsquangle.txt quangle.txt 我们把文件复制回本地文件系统，并检查是否一致： % hadoop fs -copyToLocal quangle.txt quangle.copy.txt % md5 inputdocsquangle.txt quangle.copy.txt MD5 inputdocsquangle.txt = e7891a2627cf263a079fb0f18256ffb2 MD5 quangle.copy.txt = e7891a2627cf263a079fb0f18256ffb2 MD5键值相同，表明这个文件在HDFS之旅中得以幸存并保存完整。 最后，看一下HDFS文件列表。我们新建一个目录，看它在列表中怎么显示： % hadoop fs -mkdir books % hadoop fs -ls . Found 2 items drwxr-xr-x - tom supergroup 0 2014-10-04 13：22 books -rw-r--r-- 1 tom supergroup 119 2014-10-04 13：21 quangle.txt 返回的结果信息与Unix命令ls -l的输出结果非常相似，仅有细微差别。第1列显示的是文件模式。第2列是这个文件的备份数这在传统Unix文件系统是没有的。由于我们在整个文件系统范围内设置的默认复本数为1，所以这里显示的也都是1。这一列的开头目录为空，因为本例中没有使用复本的概念，目录作为元数据保存在namenode中，而非datanode中。第3列和第4列显示文件的所属用户和组别。第5列是文件的大小，以字节为单位，目录为0。第6列和第7列是文件的最后修改日期与时间。最后，第8列是文件或目录的名称。 HDFS中的文件访问权限 针对文件和目录，HDFS的权限模式与POSIX 的权限模式非常相似。 一共提供三类权限模式：只读权限r、写入权限w和可执行权限x。读取文件或列出目录内容时需要只读权限。写入一个文件或是在一个目录上新建及删 除文件或目录，需要写入权限。对于文件而言，可执行权限可以忽略，因为你不能在HDFS中执行文件与POSIX不同，但在访问一个目录的子项时需要该权限。 每个文件和目录都有所属用户owner、所属组别group及模式mode。这个模式是由所属用户的权限、组内成员的权限及其他用户的权限组成的。 在默认情况下，Hadoop运行时安全措施处于停用模式，意味着客户端身份是没有经过认证的。由于客户端是远程的，一个客户端可以在远程系统上通过创建和任一个合法用户同名的账号来进行访问。当然，如果安全设施处于启用模式，这些都是不可能的详情见10.4节关于安全性的有关论述。无论怎样，为防止用户或自动工具及程序意外修改或删除文件系统的重要部分，启用权限控制还是很重要的这也是默认的配置，参见dfs.permissions.enabled属性 如果启用权限检查，就会检查所属用户权限，以确认客户端的用户名与所属用户是否匹配，另外也将检查所属组别权限，以确认该客户端是否是该用户组的成员；若不符，则检查其他权限。 这里有一个超级用户super-user的概念，超级用户是namenode进程的标识。对于超级用户，系统不会执行任何权限检查。3.4 Hadoop文件系统 Hadoop有一个抽象的文件系统概念，HDFS只是其中的一个实现。Java抽象类 org.apache.hadoop.fs.FileSystem定义了Hadoop 中一个文件系统的客户端接口，并且该抽象类有几个具体实现，其中和Hadoop紧密相关的见表3-1。 表3-1. Hadoop文件系统 文件系统URI方案Java实现都在org.apache. hadoop包中描述Localfilefs.LocalFileSystem使用客户端校验和的本地磁盘文件系统。使用RawLocalFileSystem表示无校验和的本地磁盘文件系统。详情参见5.1.2节HDFShdfshdfs.DistributedFileSystemHadoop 的分布式文件系统。将HDFS设计成与MapReduce结合使用，可以实现高性能 续表 文件系统URI方案Java实现都在org.apache. hadoop包中描述WebHDFSWebhdfsHdfs.web.WebHdfsFileSystem基于HTTP的文件系统，提供对HDFS的认证读写访问。详情参见3.4节相关内容Secure WebHDFSswebhdfshdfs.web.SWebHdfsFileSystemWebHDFS的HTTPS版本HARharfs.HarFileSystem一个构建在其他文件系统之上用于文件存档的文件系统。Hadoop存档文件系统通常用于将HDFS中的多个文件打包成一个存档文件，以减少namenode内存的使用。使用hadoop的achive命令来创建HAR 文件Viewviewfsviewfs.ViewFileSystem针对其他Hadoop文件系统的客户端挂载表。通常用于为联邦namenode创建挂载点，详情参见3.2.4节FTPftpfs.ftp.FTPFileSystem由FTP 服务器支持的文件系统S3S3afs.s3a.S3AFileSystem由Amazon S3 支持的文件系统。替代老版本的s3nS3 原生实现Azurewasbfs.azure.NativeAzure FileSystem由Microsoft Azure支持的文件系统Swiftswiftfs.swift.snative. SwiftNativeFileSystem由OpenStack Swift支持的文件系统 Hadoop 对文件系统提供了许多接口，它一般使用URI 方案来选取合适的文件系统实例进行交互。举例来说，我们在前一小节中遇到的文件系统命令行解释器可以操作所有的Hadoop 文件系统命令。要想列出本地文件系统根目录下的文件，可以输入以下命令： % hadoop fs -ls file： 尽管运行的MapReduce程序可以访问任何文件系统有时也很方便，但在处理大数据集时，建议你还是选择一个有数据本地优化的分布式文件系统，如HDFS参见2.4节。 接口 Hadoop是用Java写的，通过Java API可以调用大部分Hadoop文件系统的交互操作。例如，文件系统的命令解释器就是一个Java 应用，它使用Java 的FileSystem类来提供文件系统操作。其他一些文件系统接口也将在本小节中做简单介绍。这些接口通常与HDFS一同使用，因为Hadoop中的其他文件系统一般都有访问基本文件系统的工具对于FTP，有FTP客户端；对于S3，有S3工具，等等，但它们大多数都能用于任何Hadoop 文件系统。 1. HTTP Hadoop以Java API的形式提供文件系统访问接口，非Java开发的应用访问HDFS会很不方便。由WebHDFS协议提供的HTTP REST API则使得其他语言开发的应用能够更方便地与HDFS交互。注意，HTTP接口比原生的Java客户端要慢，所以不到万不得已，尽量不要用它来传输特大数据。 通过HTTP来访问HDFS有两种方法：直接访问，HDFS守护进程直接服务于来自客户端的HTTP请求；通过代理一个或多个访问，客户端通常使用DistributedFileSystem API访问HDFS。这两种方法如图3-1所示。两者都使用了WebHDFS协议。 图3-1. 通过HTTP直接访问HDFS或者通过多个HDFS代理访问HDFS 在第一种情况中，namenode和datanode内嵌的web服务器作为WebHDFS的端节点运行。由于dfs.webhdfs.enabled被设置为true，WebHDFS默认是启用状态。文件元数据操作由namenode管理，文件读写操作首先被发往namenode，由namenode发送一个HTTP重定向至某个客户端，指示以流方式传输文件数据的目的或源datanode。 第二种方法依靠一个或者多个独立代理服务器通过HTTP访问HDFS。由于代理服务是无状态的，因此可以运行在标准的负载均衡器之后。所有到集群的网络通信都需要经过代理，因此客户端从来不直接访问namenode或datanode。使用代理服务器后可以使用更严格的防火墙策略和带宽限制策略。通常情况下都通过代理服务器，实现在不同数据中心中部署的Hadoop集群之间的数据传输，或从外部网络访问云端运行的Hadoop集群。 HttpFS 代理提供和WebHDFS相同的HTTP和HTTPS接口, 这样客户端能够通过webhdfsswebhdfs URI访问这两类接口。HttpFS 代理的启动独立于namenode和datanode的守护进程，使用httpfs.sh脚本，默认在一个不同的端口上监听端口号14000。 2. C语言 Hadoop提供了一个名为libhdfs的C语言库，该语言库是Java FileSystem接口类的一个镜像它被写成访问HDFS的C语言库，但其实它可以访问任何一个Hadoop文件系统。它使用Java原生接口JNI, Java Native Interface调用Java 文件系统客户端。同样还有一个libwebhdfs库，该库使用了前述章节描述的WebHDFS接口。 这个C语言API 与Java的API非常相似，但它的开发滞后于Java API，因此目前一些新的特性可能还不支持。可以在Apache Hapdoop二进制压缩发行包的include目录中找到头文件hdfs.h。 Apache Hapdoop二进制压缩包自带预先编译好的libhdfs二进制编码，支持64位Linux。但对于其他平台，需要按照源代码树顶层的BUILDING.txt指南自行编译。 3. NFS 使用Hadoop的NFSv3网关将HDFS挂载为本地客户端的文件系统是可行的。然后你可以使用Unix实用程序如ls和cat 与该文件系统交互，上传文件，通过任意一种编程语言调用POSIX 库来访问文件系统。由于HDFS仅能以追加模式写文件，因此可以往文件末尾添加数据，但不能随机修改文件。 关于如何配置和运行NFS网关，以及如何从客户端连接网关，可以参考Hadoop相关文档资料。 4. FUSE 用户空间文件系统FUSE, Filesystem in Userspace，允许将用户空间实现的文件系统作为Unix文件系统进行集成。通过使用Hadoop的Fuse-DFS功能模块，HDFS或任何一个Hadoop 文件系统均可以作为一个标准的本地文件系统进行挂载。Fuse-DFS是用C语言实现的，使用libhdfs作为访问HDFS的接口。在写操作时，Hadoop NFS网关对于挂载HDFS来说是更健壮的解决方案，相比Fuse-DFS而言应优先选择。

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