网志栈编辑推荐
；
内容简介
本书侧重于大数据的实践性技术，系统地介绍了主流大数据平台及工具的安装部署、管理维护和应用开发。平台和工具的选择均为当前业界主流的开源产品，因此，对于读者来说，有很强的可操作性。
本书涉及的开源技术包括：HDFS、MapReduce、YARN、Zookeeper、HBase、Hive、Sqoop、Storm、Kafka、Flume等。除介绍一般性的背景知识、安装部署、管理维护和应用开发技术外，还特别注重案例实践，重要的技术点以实际工作场景或案例为依托，使读者能快速入门，参考案例动手实践，通过具体深入的实践，体会大数据的技术本质特征，领略大数据技术带来的创新理念，更好地理解和把握信息技术的发展趋势。
本书主要内容包括以下几大部分。
大数据存储篇：以HDFS为基础，介绍分布式文件系统的原理、安装、fs命令的使用、编程，介绍如何用HDFS实现，并通过HTTP调用。
大数据计算篇：以MapReduce、YARN为基础，介绍分布式计算的原理、部署，以及编程案例。
非关系型数据库篇：以HBase为基础，重点介绍非关系型数据库的优势、原理、部署，以及命令行使用，编程案例，与Sqoop配合使用等。
作者简介
祁伟：毕业于北京师范大学，目前担任《中国教育信息化》杂志社总编辑，具有超过20年的IT工作经验，在网络路由、服务器虚拟化、数据库等方面有深入研究和丰富的实践经验。
刘冰：毕业于中国科学院计算技术研究所，数据中心架构师，从事虚拟化、监测与大数据分析等方面研究，曾与祁伟总编共同著有《云计算：从基础架构到*实践》，现就职于教育部教育管理信息中心。
常志军：毕业于中国科学院自动化研究所，大数据平台架构师，分布式系统研究人员。先后在搜狐畅游、中国搜索、Opera欧朋、中科院自动化所从事大数据领域的探索与研发工作。
赵廷涛：毕业于中国传媒大学，现就职于科技部信息中心，有多年大数据存储研发经验，现从事数据中心管理运维工作，专注于虚拟化、应用系统建设等相关技术研究。
高俊秀：毕业于北京航空航天大学计算机学院，数据仓库架构师，八年互联网大数据从业经验。历任百度、豌豆荚、今日头条的数据平台和数据仓库核心研发和负责人，对数据在业务上发挥价值有深入的理解。
目录
目 ； ； ； 录
；大数据存储篇
第1章 ； 概述.... 1
1.1 ； 什么是大数据... 2
1.2 ； 大数据的技术转型... 3
1.3 ； 数据分片... 4
1.4 ； 数据一致性... 5
1.4.1 ； CAP原则... 5
1.4.2 ； CAP与ACID.. 7
1.4.3 ； BASE原则... 8
1.5 ； 主流大数据技术... 8
1.6 ； 大数据职业方向... 10
1.7 ； 大数据实践平台的搭建... 10
1.7.1 ； 初学者模式... 10
1.7.2 ； 物理集群模式... 11
1.7.3 ； 虚拟化集群模式... 11
1.8 ； 小结... 12
第2章 ； HDFS文件系统.... 13
2.1 HDFS概述... 14
2.1.1 分布式文件系统... 14
2.1.2 ； HDFS介绍... 16
2.2 HDFS的运行机制... 18
2.2.1 ； HDFS的结构与组成... 18
2.2.2 ； HDFS的数据操作... 20
2.2.3 ； 访问权限... 22
2.2.4 ； 通信协议簇... 23
2.2.5 ； HDFS的高可用性... 24
2.2.6 ； 集中缓存管理... 25
2.2.7 ； 日志和检查点... 26
2.2.8 ； HDFS快照... 28
2.3 HDFS的数据存储... 29
2.3.1 数据完整性... 29
2.3.2 数据压缩... 30
2.3.3 序列化... 32
2.4 HDFS的安装和配置... 34
2.4.1 Hadoop的安装... 34
2.4.2 ； HDFS的配置... 40
2.4.3 ； 启动HDFS. 45
2.5 小结... 47
第3章 ； HDFS操作实践.... 49
3.1 HDFS接口与编程... 50
3.1.1 ； Shell命令... 50
3.1.2 ； Java接口操作... 62
3.1.3 ； WebHDFS. 69
3.1.4 ； 其他接口... 71
3.2 操作实践... 73
3.2.1 文件操作... 73
3.2.2 压缩与解压缩... 77
3.3 小结... 80
大数据计算篇
第4章 ； YARN.. 81
4.1 ； YARN概述... 82
4.2 ； YARN的主要组成模块... 83
4.3 ； YARN的整体设计... 83
4.4 ； 容量调度器... 84
4.4.1 ； 什么是容量调度器... 84
4.4.2 ； 容量调度器的特性... 85
4.4.3 ； 配置RM使用容量调度器... 85
4.5 ； 公平调度器(Fair Scheduler) 86
4.5.1 ； 什么是公平调度器... 86
4.5.2 ； 分级队列... 87
4.5.3 ； 公平调度器队列的设置... 87
4.6 ； 资源管理者(RM)重启机制... 90
4.6.1 ； 什么是资源管理器重启... 90
4.6.2 ； 非工作保存RM重启... 90
4.6.3 ； 工作保存RM重启... 91
4.6.4 ； RM重启配置yarn-site.xml 91
4.7 ； 资源管理器的高可用性(RM HA) 92
4.7.1 ； 什么是资源管理器的
高可用性... 92
4.7.2 ； 自动故障转移... 92
4.7.3 ； 客户端/应用管理器/节点
管理器的故障转移... 92
4.7.4 部署RM HA.. 93
4.7.5 配置例子... 94
4.7.6 管理员命令... 95
4.8 节点标签... 95
4.8.1 节点标签的特点... 95
4.8.2 节点标签的属性... 95
4.8.3 节点标签的配置... 96
4.8.4 使用节点标签的调度器配置... 96
4.8.5 节点标签配置示例... 97
4.8.6 指定应用的节点标签... 97
4.8.7 节点标签的监控... 98
4.9 YARN编程... 98
4.9.1 什么是YARN级别编程... 98
4.9.2 YARN的相关接口... 99
4.9.3 编程实践... 99
4.10 YARN服务注册... 107
4.10.1 为什么需要服务注册... 107
4.10.2 配置服务注册... 107
4.10.3 安全选项... 108
4.11 小结... 108
第5章 MapReduce.. 109
5.1 MapReduce概述... 110
5.1.1 HadoopMapReduce. 110
5.1.2 MapReduce的发展史... 110
5.1.3 MapReduce的使用场景... 111
5.2 Key-Value结构的特点... 111
5.2.1 key的设计... 111
5.2.2 value的设计... 112
5.3 MapReduce的部署... 112
5.3.1 软件准备... 112
5.3.2 配置文件... 113
5.3.3 启动YARN守护进程... 113
5.4 MapReduce的程序结构... 113
5.4.1 MR框架的输入和输出... 114
5.4.2 WordCount 114
5.5 MapReduce的编程接口... 116
5.5.1 Mapper接口... 117
5.5.2 Reducer接口... 117
5.5.3 Partitioner(分区) 118
5.5.4 Counter(计数器) 118
5.5.5 job工作机理... 118
5.5.6 任务提交和监控(Job
Submission and Monitoring) 121
5.5.7 任务的辅助文件(Task
Side-Effect Files) 123
5.5.8 提交作业到队列... 123
5.5.9 MR中的计数器(Counters) 123
5.5.10 Profiling. 123
5.5.11 Debugging. 124
5.5.12 jobOutputs. 124
5.5.13 忽略坏记录(Skipping
Bad Records) 124
5.6 MapReduce的命令行... 125
5.6.1 概述... 125
5.6.2 用户命令(User Commands) 125
5.6.3 管理员命令(Administration
Commands) 127
5.6.4 YARN-MapReduce的部署... 128
5.7 WordCount的实现... 129
5.8 小结... 136
非关系型数据库篇
第6章 使用HBase.. 137
6.1 HBase基础... 138
6.1.1 HBase是什么... 138
6.1.2 HBase伪分布式部署... 140
6.1.3 服务的启动与验证... 142
6.1.4 HBase Shell测试... 142
6.1.5 Web测试... 144
6.1.6 服务的关闭... 147
6.2 HBase的架构原理... 147
6.2.1 组成架构... 147
6.2.2 数据模型... 151
6.2.3 物理存储... 153
6.3 HBase的命令实践... 156
6.3.1 概述... 157
6.3.2 命名空间... 158
6.3.3 表管理... 160
6.4 HBase的数据管理... 166
6.4.1 数据的添加... 167
6.4.2 数据的追加... 168
6.4.3 数据的获取... 169
6.4.4 数据统计... 172
6.4.5 表的扫描... 173
6.4.6 数据的删除... 175
6.4.7 表的重建... 175
6.5 HBase的集群管理... 177
6.5.1 集群部署... 177
6.5.2 自动化脚本... 180
6.5.3 权限管理... 182
6.5.4 集群调度... 184
6.5.5 日志分析... 186
6.6 小结... 187
第7章 HBase编程开发.... 189
7.1 HBase的编程接口... 190
7.1.1 rest编程接口... 190
7.1.2 thrift接口... 196
7.1.3 Java API接口... 198
7.1.4 Java API示例... 199
7.2 表与命名空间的编程... 202
7.2.1 表的查看... 203
7.2.2 表的创建... 206
7.2.3 表的删除... 207
7.2.4 表的修改... 208
7.2.5 命名空间... 210
7.3 数据编程... 213
7.3.1 数据的增加... 214
7.3.2 单行查询... 216
7.3.3 集合查询... 217
7.3.4 过滤器... 219
7.3.5 数据删除... 221
7.4 集群与优化编程... 222
7.4.1 集群管理... 222
7.4.2 集群监测... 224
7.4.3 多表与表池... 227
7.4.4 批处理... 230
7.4.5 数据迁移... 231
7.5 小结... 234
大数据仓库篇
第8章 数据仓库概论.... 235
8.1 初识数据仓库... 236
8.1.1 什么是数据仓库... 236
8.1.2 数据仓库与数据库... 237
8.1.3 为什么要有数据仓库... 239
8.2 数据仓库的核心概念... 240
8.2.1 数据平台... 240
8.2.2 数据产品... 241
8.2.3 商务智能(BI) 242
8.2.4 元数据... 242
8.2.5 OLAP. 242
8.2.6 ETL. 243
8.2.7 数据质量... 243
8.3 数据仓库中的数据内容划分... 243
8.3.1 多个数据仓库... 243
8.3.2 典型的数据仓库分层... 245
8.3.3 数据集市... 246
8.4 OLAP. 247
8.4.1 定义... 247
8.4.2 维度建模... 248
8.4.3 事实表... 250
8.4.4 维度表... 251
8.5 ETL. 251
8.5.1 抽取... 252
8.5.2 转换... 252
8.5.3 加载... 254
8.5.4 ETL元数据... 255
8.5.5 ETL工具... 256
8.6 调度和运行... 256
8.6.1 调度怎么工作... 257
8.6.2 需要考虑的其他方面... 258
8.6.3 简易调度示例... 259
8.7 数据仓库的架构... 259
8.8 数据仓库的展望... 260
8.8.1 数据仓库发展的阶段性... 260
8.8.2 未来的数据仓库... 262
8.9 小结... 262
第9章 Hive.. 263
9.1 初识Hive. 264
9.1.1 Hive是什么... 264
9.1.2 Hive的部署... 264
9.1.3 以MySQL作为Hive的
元数据库... 266
9.1.4 Hive的体系结构... 268
9.1.5 Web界面展示... 269
9.2 Hive命令行接口... 270
9.2.1 启动Hive命令行... 270
9.2.2 可用的命令... 271
9.3 Hive数据类型与常见的结构... 271
9.3.1 数据类型... 271
9.3.2 文件的存储结构... 273
9.4 HiveSQL. 274
9.4.1 数据定义语言DDL. 274
9.4.2 数据操纵语言DML. 277
9.5 Hive的自定义函数... 283
9.5.1 UDF. 284
9.5.2 UDAF. 286
9.5.3 UDTF. 289
9.6 Hive的高级使用... 292
9.6.1 视图... 292
9.6.2 索引... 293
9.6.3 权限... 294
9.6.4 Thrift服务... 296
9.7 使用Hive构建数据仓库... 298
9.7.1 原始数据和结构... 298
9.7.2 数据需求和模型设计... 300
9.7.3 各层次数据的生成... 301
9.8 小结... 302
大数据实时计算篇
第10章 Storm实时系统.... 303
10.1 大数据实时系统概述... 304
10.2 Kafka分布式消息系统... 305
10.2.1 Kafka是什么... 305
10.2.2 主题的工作原理... 306
10.2.3 分布式分区... 307
10.2.4 生产者、消费者... 307
10.2.5 数据保证... 308
10.2.6 Kafka系统的应用场景... 308
10.2.7 Kafka系统的部署... 309
10.3 Storm实时处理系统... 316
10.3.1 概述... 316
10.3.2 为什么使用Storm.. 316
10.3.3 Storm系统的特点... 317
10.3.4 Storm系统的工作机制... 318
10.3.5 Storm的分组方法... 319
10.3.6 Storm系统的组件... 320
10.3.7 搭建单点Storm系统... 320
10.3.8 查看Storm UI 322
10.3.9 搭建Storm集群... 322
10.3.10 Storm系统的操作实践... 323
10.3.11 StormWordCount
(写RDB) 324
10.3.12 StormWordCount(从Kafka
读取数据) 329
10.4 小结... 331
参考文献.... 332
前沿
前 言
技术革命的浪潮推动着人类文明的发展。
第一次浪潮造就了农业革命，它在数千年前出现并持续了数千年；第二次浪潮造就了工业革命，它在数百年前出现并持续了数百年；我们今天正在经历着信息技术第三次浪潮，发端于数十年前，目前也只是处在初级阶段。
农业技术革命释放了"物之力"；工业技术革命释放了"能之力"，而今天的信息技术革命释放的是"智之力"。
距今400年前，培根在《伟大的复兴》中预言：知识就是力量。今天，人类终于迎来"知识经济时代"，它是人类社会经济增长方式与经济发展的全新模式。
人类认识物质世界、人类社会和精神世界的最高境界是智慧，而要达智慧的境界，必然要跨越数据、信息、知识三个层级。
数据作为基础，是信息之母、知识之初、智慧之源。正是今天的大数据技术，引燃了人们实现智慧城市、智慧医疗、智慧教育等有关人工智慧的激情。人们真切地认识到，对于人工智能，只要让数据发生质变，即使是简单的数据，也比复杂的算法更有效。
今天，移动互联网的发展，使我们在获取数据上有了质的飞跃，人类的各种社会活动都与互联网这个虚拟世界相联系，使全样本、全过程地有效测量和记录成为可能，构建了生成大数据生态的土壤，同时，人们还在期待和憧憬物联网带来更大的冲击。
另一方面，云计算发展到今天，不论从技术到产业都开始进入成熟期，这也是大数据发展的基石和推进器。
在今天这个时代中，运用大数据洞见事物蕴藏的"智慧"成为人们的渴望。大数据更新了人们对数据的认识。在技术层面，小数据时代的很多数据处理方法和工具已不再有效，需要一系列新的方法和工具。所幸，有大量平民化的开源软件可用，它们不需要特殊的硬件系统，也更适用于云计算环境。
本书正是一本介绍主流的大数据开源软件平台和工具的技术专著，侧重于大数据的实践性技术，帮助读者快速入门，通过具体深入的实践，体会大数据的技术本质特征，领略大数据技术带来的创新理念，更好地理解和把握信息技术的发展趋势。
本书定位
(1) 信息发展已步入大数据时代，当前对于大数据还缺乏面向公众的技术实践手册。
(2) 本书的创作团队有丰富的大数据规划、开发、运营等经验，多位作者成功地架构了教育部、科技部、互联网等大数据架构与分析项目。
(3) 本书的参与者均是部委信息一线工程师、著名外企架构师、国内企业资深高级工程师，所做的理论分析易于学习，实践具有可操作性。
(4) 本书重点介绍大数据的基础理论、关键技术，以及编程实践。利用本书，就可以完全搭建并能有效地管理好大数据平台。
本书特色
(1) 理念先进：均是国内外最新的大数据理念；方便读者全面了解国内外大数据研究与发展的情况。
(2) 技术领先：参与者均是国内IT人士；采用的平台均是业界主流开源平台，涉及大数据常用的HDFS、MapReduce、YARN、Zookeeper、HBase、Hive、Sqoop、Storm、Kafka等技术的介绍与编程使用。
(3) 案例丰富：提供翔实的实例与解决方法，供项目中参考。
(4) 资源齐备：本书涉及的配套下载资源可以从清华大学出版社的网站中下载。
全书关键字
大数据、分布式计算、数据仓库、数据分析、HDFS、MapReduce、YARN、Zookeeper、HBase、Hive、Sqoop、Storm、Kafka。
由于编者的水平有限，书中难免有疏漏和错误，希望业内专家和广大读者指正。
编 者
免费在线读
第2章 HDFS文件系统
本章介绍Hadoop的核心组成部分HDFS文件系统，包括其原理、安装与配置、管理及外部编程接口等。通过对本章内容的学习，使读者掌握分布式文件系统的主要结构、HDFS文件系统的内部运行原理和机制、HDFS的数据读写方式，同时，了解HDFS文件系统的数据传输和存储模式。
本章最后将详细介绍Hadoop的安装和基本配置。学习完本章后，读者可以搭建自己的Hadoop集群。
HDFS文件系统的结构与组成
HDFS系统的数据读写
HDFS系统的数据存储及数据完整性
Hadoop的安装及配置
2.1 HDFS概述
Hadoop实现了一个分布式文件系统(Hadoop Distributed File System，HDFS)，HDFS是ApacheHadoop Core项目的一部分，是Hadoop兼容性最好的标准级分布式文件系统。
2.1.1 分布式文件系统
当今的信息时代中，人们可以获取的数据成指数倍地增长。单纯通过增加硬盘个数来扩展计算机文件系统的存储容量的方式，在容量大小、容量增长速度、数据备份、数据安全等方面都不适用，对于数据量很大的应用系统来说尤其如此。分布式文件系统可以有效解决数据的存储和管理难题。
分布式文件系统(Distributed File System，DFS)指通过一套管理系统，能够将文件分散至不同的计算机进行存储，并通过规范的标准协议，方便客户机进行高效存取。
与单机的文件系统不同，分布式文件系统不是将数据放在一块磁盘上由上层操作系统来管理，而是存放在一个服务器集群上，由集群中的服务器通过各尽其责、通力合作的方式提供整个文件系统的服务。将固定于某个地点的某个文件系统，扩展到任意多个地点/多个文件系统，这些节点组成一个文件系统网络。每个节点可以分布在不同的地点，通过网络进行节点间的通信和数据传输。人们在使用分布式文件系统时，无须关心数据是存储在哪个节点上，或者是从哪个节点获取的，只需要像使用本地文件系统一样管理和存储文件系统中的数据即可。
分布式文件系统中，重要的服务器包括：主控服务器(Master/NameNode)、数据服务器(一般称为ChunkServer或DataNode)和客户服务器(Client)。分布式文件系统的典型架构如图2-1所示。
图2-1 典型分布式文件系统的结构
1. 分布式文件系统的特点
与传统文件系统相比，分布式文件系统具有以下主要特点。
(1) 可扩展性强。扩展能力是一个分布式文件系统最重要的特点。基本上，所有的分布式文件系统都支持随时随地对数据服务器进行扩展，提升存储容量和访问带宽等。有的系统还支持多个目录/主控服务器。
(2) 统一命名空间。采用统一命名空间，分布式文件系统对于客户端是完全透明的，客户端看到的是统一的全局命名空间，用户操作起来就像是管理本地文件系统。通过元数据管理，文件以块的方式采用多副本模式进行存放。
(3) 高性能。由于一个文件被分成多份，保存在不同的数据服务器上，访问时，可以同时读取，性能会达到最优。
(4) 高可用性。分布式文件系统必须具有高容错能力，即无论是客户端还是服务器出现故障，都不会影响整个系统的功能。为了做到这一点，单点失效是必须被避免的，例如使用资源冗余技术或者提供失效恢复服务。单个数据节点的故障并不会影响集群整体运转。
(5) 弹性存储。可以根据业务需要灵活地增加或缩减数据存储以及增删存储池中的资源，而不需要中断系统运行。弹性存储的最大挑战，是减小或增加资源时的数据震荡问题。
2. 常见的分布式文件系统
分布式文件系统既有开源软件平台解决方案，如Hadoop HDFS、Fast DFS等；也有非开源平台解决方案，如最为著名的Google FS、也有像Windows Server 2003/2008平台上的DFS组件等。
分布式文件系统在当前应用普遍，产品种类丰富。下面介绍几种典型的系统。
(1) Lustre。
Lustre最早是由HP、Cluster File System联合美国能源部共同开发的Linux平台下的分布式集群文件系统，后期由于Cluster File System公司被Sun收购，而Sun又被Oracle收购，因此，Lustre官方网站目前挂靠在Oracle公司(http://wiki.lustre.org/index.php/Main_Page)。
Lustre主要面向超级计算机，拥有超强可扩展性与可靠性，能够支持上万个节点、PB级存储、100GB/s的高速访问能力。
Lustre采用GPL许可协议，属于开放源代码的分布式集群文件系统，开发语言采用C/C ，使用平台为Linux；当前，除了Oracle公司外，有新成立的名为Whamcloud的公司专注于Lustre平台的开源研发，其官方网站为http://www.whamcloud.com/。
(2) Google FS。
Google FS(Google File System)是谷歌公司开发的一个分布式可扩展的文件系统，它主要用于大型、分布式、大数据量的互联网应用平台。
Google FS被设计运行在廉价普通的PC服务器上，提供多数据副本实现数据冗余，通过数据分块并行存取，满足互联网用户的海量数据存储需求。
Google FS最早是由Google工程师于2003年发表的一篇学术文章The Google File System而为世人所熟知的，Google FS提供了相似的访问接口，如read、write、create、delete、close等，使得开发者可以非常方便地使用。
Google FS运行于Linux平台上，开发语言是C/C ，本身并不开源，本章中所介绍的Hadoop平台，是在受到Google FS启发后，采用其理念重新用Java语言实现的一个开源平台。
(3) Fast DFS。
Fast DFS是一个类Google FS的开源分布式文件系统，它由C/C 语言开发，可运行于Linux、Unix、AIX平台。Fast DFS提供专用文件存取访问方式，不支持POSIX接口方式，在系统中也不能使用mount方式挂接。FastDFS在架构上充分考虑了冗余备份、负载均衡、可扩展等问题，平台本身具有高可用、高性能等优点。Fast DFS支持文件的高效存储、同步、上传、下载等，比较适合于互联网视频网站、文档分享网站、图片分享网站等应用。
2.1.2 HDFS介绍
HDFS是Hadoop的核心子项目，是整个Hadoop平台数据存储与访问的基础，在此之上，承载其他如MapReduce、HBase等子项目的运转。
HDFS是类似于Google FS的开源分布式文件系统，被设计成适合运行在通用硬件上的分布式文件系统。它与现有的分布式文件系统有很多共同点。但同时，它与其他的分布式文件系统的区别也是很明显的。
HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。
HDFS是易于使用与管理的分布式文件系统，主要特点和设计目标如下。
1. 硬件故障是常态
整个HDFS系统可以由数百或数千个存储着文件数据片段的服务器组成。实际上，它里面有非常巨大的组成部分，每一个组成部分都很可能出现故障，这就意味着HDFS里总是有一些部件是失效的，因此故障的检测和自动快速恢复是HDFS一个很核心的设计目标。
2. 流式数据访问
HDFS被设计成适合批量处理的，而不是用户交互式的。POSIX的很多硬性需求对于HDFS应用都是非必需的，HDFS放宽了POSIX的要求，这样，可以实现以流的形式访问(Streaming Access)文件系统中的数据。同时去掉POSIX一小部分关键语义，可以获得更好的数据吞吐率。
3. 简单的一致性模型
大部分HDFS程序对文件操作需要的是一次写、多次读取的操作模式。HDFS假定一个文件一旦创建、写入、关闭之后就不需要修改了。这简单化了数据一致的问题，并使高吞吐量的数据访问变得可能。
4. 名字节点(NameNode)和数据节点(DataNode)
HDFS是一个主从结构，一个HDFS集群包括一个名字节点(也叫名称节点)，它是一个管理文件命名空间和调节客户端访问文件的主服务器，当然，还有一些数据节点，通常是一个节点一个机器，它来管理对应节点的存储。HDFS对外开放文件命名空间，并允许用户数据以文件形式存储。内部机制是将一个文件分割成一个或多个块，这些块被存储在一组数据节点中。名字节点用来操作文件命名空间的文件或目录操作，如打开、关闭、重命名等。它同时确定块与数据节点的映射。数据节点负责来自文件系统客户的读写请求。数据节点同时还要执行块的创建、删除，以及来自名字节点的块复制指令。
5. 大规模数据集
HDFS被设计为PB级以上存储能力，单个的存储文件可以是GB或者TB级。因此，HDFS的一个设计原则是支持成千上万大数据文件的存储，即将单个文件分成若干标准数据块，分布存储于多个节点上，当用户访问整个文件时，由这些节点集群向用户传输所拥有的数据块，由此可以获得极高的并行数据传输速率。
6. 可移植性
HDFS在设计之初，就考虑到了异构软硬件平台间的可移植性，能够适应于主流硬件平台。它基于跨操作系统平台的Java语言进行编写，这有助于HDFS平台的大规模应用推广。
名字节点是整个HDFS的核心。一个标准的HDFS集群应由名字节点、备用名字节点、数据节点组成，HDFS的基本结构如图2-2所示。
图2-2 HDFS系统的基本结构
集群中，一台机器上只运行一个NameNode实例，而集群中其他机器分别运行一个DataNode实例。NameNode是一个中心服务器，负责管理文件系统的名字空间以及客户端对文件的访问，用户能够以文件的形式在上面进行名字空间操作，比如打开、关闭、重命名文件或目录，同时，NameNode还决定了数据块到数据节点的映射关系。NameNode也可以称为管理文件系统的元数据。集群中，每一个节点配置一个DataNode，每个DataNode负责管理它所在节点上的数据存储。从内部看，一个文件被分成一个或多个数据块，这些块存储在一组DataNode上。同时，DataNode负责处理文件系统客户端的读写请求，在NameNode的统一调度下进行数据块的创建、删除和复制。
HDFS的数据块：磁盘存储文件时，是按照数据块(block)来存储的，也就是说，数据块是磁盘读/写的最小单位。数据块也称磁盘块。在HDFS中也有块的概念，默认为64MB，每个块作为独立的存储单元。
基于数据块的存储方式非常适合用于备份，可提供数据容错能力和可用性(如图2-3所示)。HDFS提供给应用程序例如MapReduce数据服务。一般来说，MapReduce的Map任务通常一次处理一个块中的数据，如果任务数太少(少于集群中节点的数量)，就没有发挥多节点的优势，甚至作业的运行速度就会与单节点一样。
图2-3 HDFS块副本
2.2 HDFS的运行机制
本节将详细介绍HDFS的结构与运行原理。
2.2.1 HDFS的结构与组成
HDFS采用主/从(Master/Slave)结构，整个集群由一个名字节点和多个数据节点组成。
NameNode主要负责管理文件命名空间和客户端访问的主服务器，而DataNode则负责对存储进行管理。
HDFS的体系结构如图2-4所示。
图2-4 HDFS的体系结构
由图2-4可知，名字节点NameNode上保存着控制数据节点DataNode信息的元数据(Metadata)。客户端Client可以通过NameNode对元数据进行操作，也可以直接对DataNode进行读和写操作。
1. NameNode的主要功能
(1) 管理元数据信息。元数据信息包括名字空间、文件到文件块的映射、文件块到数据节点的映射三部分。管理文件块包括创建新文件块、文件复制、移除无效文件块以及回收孤立文件块等内容。
(2) 管理文件系统的命名空间。任何对文件系统元数据产生修改的操作，NameNode都会使用事务日志记录(下称EditLog)来表示；同样地，修改文件的副本系数也将往EditLog中插入一条记录，NameNode将EditLog存储在本地操作系统的文件系统中。同时，文件系统的命名空间被存储在一个称为映像文件(FsImage)的文件中，包括文件的属性、文件块到文件的映射以及文件块到数据节点的映射等内容，FsImage文件也是存放在NameNode所在的本地文件系统中。
(3) 监听请求。指监听客户端事件和DataNode事件。客户端事件包含名字空间的创建和删除，文件的创建、读写、重命名和删除，文件列表信息获取等信息。DataNode事件主要包括文件块信息、心跳响应、出错信息等。处理请求指处理上面的监听请求事件并返回结果。
(4) 心跳检测。DataNode会定期将自己的负载情况通过心跳信息向NameNode汇报。NameNode全权管理数据块的复制，它周期性地从集群中的每个DataNode接收心跳信号和块状态报告(Block Report)。接收到心跳信号意味着该DataNode节点工作正常。块状态报告包含了一个该DataNode上所有数据块的列表。
NameNode决定是否将文件映射到DataNode的复制块上。
对于最常见的三个复制块，第一个复制块存储在同一机架的不同节点上，最后一个复制块存储在不同机架的某个节点上。
实际的I/O事务并没有经过NameNode，只有表示DataNode和块的文件映射的元数据经过NameNode。当外部客户机发送请求，要求创建文件时，NameNode会以块标识和该块的第一个副本的DataNode IP地址作为响应。这个NameNode还会通知其他将要接收该块的副本的DataNode。
NameNode在FsImage文件中存储所有关于文件系统名称空间的信息，包含所有事务的记录文件EditLog存储在NameNode的本地文件系统上。FsImage和EditLog文件也需要复制副本，以防文件损坏或NameNode系统丢失。
2. DataNode的主要功能
(1) 数据块的读写。一般是文件系统客户端需要请求对指定的DataNode进行读写操作，DataNode通过DataNode的服务进程与文件系统客户端打交道。同时，DataNode进程与NameNode统一结合，对是否需要对文件块的创建、删除、复制等操作进行指挥与调度，当与NameNode交互过程中收到了可以执行文件块的创建、删除或复制操作的命令后，才开始让文件系统客户端执行指定的操作。具体文件的操作并不是DataNode来实际完成的，而是经过DataNode许可后，由文件系统客户端进程来执行实际操作。
(2) 向NameNode报告状态。每个DataNode节点会周期性地向NameNode发送心跳信号和文件块状态报告，以便NameNode获取到工作集群中DataNode节点状态的全局视图，从而掌握它们的状态。如果存在DataNode节点失效的情况，NameNode会调度其他DataNode执行失效节点上文件块的复制处理，保证文件块的副本数达到规定数量。
(3) 执行数据的流水线复制。当文件系统客户端从NameNode服务器进程中获取到要进行复制的数据块列表(列表中包含指定副本的存放位置，亦即某个DataNode节点)后，会首先将客户端缓存的文件块复制到第一个DataNode节点上，此时，并非整个块都复制到第一个DataNode完成以后才复制到第二个DataNode节点上，而是由第一个DataNode向第二个DataNode节点复制，如此反复进行下去，直到完成文件块及其块副本的流水线复制。
2.2.2 HDFS的数据操作
HDFS被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。它将每个文件存储成block(即数据块)序列，除了最后一个block，其他所有的block都是同样的大小。
1. 数据写入
在HDFS文件系统上创建并写一个文件的流程如图2-5所示。
图2-5 HDFS写入流程
具体流程描述如下。
(1) Client调用DistributedFileSystem对象的create方法，创建一个文件输出流(FSDataOutputStream)对象。
(2) 通过DistributedFileSystem对象与Hadoop集群的NameNode进行一次远程调用(RPC)，在HDFS的Namespace中创建一个文件条目(Entry)，该条目没有任何的数据块。
(3) 通过FSDataOutputStream对象，向DataNode写入数据，数据首先被写入FSDataOutputStream对象内部的Buffer中，然后数据被分割成一个个Packet数据包。
(4) 以Packet为最小单位，基于Socket连接发送到按特定算法选择的HDFS集群中的一组DataNode(正常是3个，可能大于等于1)中的一个节点上，在这组DataNode组成的Pipeline上依次传输Packet。
(5) 这组DataNode组成的Pipeline反方向上发送ack确认，最终由Pipeline中第一个DataNode节点将Pipelineack发送给Client。
(6) 完成向文件写入数据，Client在文件输出流(FSDataOutputStream)对象上调用close方法，关闭流。
(7) 调用DistributedFileSystem对象的complete方法，通知NameNode文件写入成功。
写文件过程中，Client/DataNode与NameNode进行的RPC调用。
① 写文件开始时创建文件：Client调用create，在NameNode节点的命名空间中创建
一个标识该文件的条目。
② 在Client连接Pipeline中第一个DataNode节点之前，Client调用addBlock分配一
个数据块。
③ 如果与Pipeline中第一个DataNode节点连接失败，Client调用abandonBlock放弃
一个已经分配的数据块。
④ 一个Block已经写入到DataNode节点磁盘，Client调用fsync让NameNode持久化
数据块的位置信息数据。
⑤ 文件写完以后，Client调用complete方法通知NameNode写入文件成功。
⑥ DataNode节点接收到并成功持久化一个数据块的数据后，调用blockReceived方法
通知NameNode已经接收到数据块。
2. 数据读取
相比于写入流程，HDFS文件的读取过程比较简单，如图2-6所示。
图2-6 HDFS读取数据
文件的读取操作流程如下。
(1) 客户端调用FileSystem的open()函数打开文件，DistributedFileSystem用RPC调用元数据节点，得到文件的数据块信息。
(2) 对于每一个数据块，元数据节点返回保存数据块的数据节点的地址。DistributedFileSystem返回FSDataInputStream给客户端，用来读取数据。
(3) 客户端调用stream的read()函数开始读取数据。
(4) DFSInputStream连接保存此文件第一个数据块的最近的数据节点。
(5) Data从数据节点读到客户端，当此数据块读取完毕时，DFSInputStream关闭与此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点。
(6) 当客户端读取数据完毕的时候，调用FSDataInputStream的close函数。
在读取数据的过程中，如果客户端在与数据节点通信时出现错误，则尝试连接包含此数据块的下一个数据节点。失败的数据节点将被记录下来，以后不再连接。
2.2.3 访问权限
HDFS实现了一个与POSIX类似的文件和目录的权限模型。有三类权限模式：只读权限(r)、写入权限(w)和可执行权限(x)。每个文件和目录都有所属用户(owner)、所属组(group)和模式(mode)。文件或目录对其所有者、同组的其他用户以及所有其他用户分别有着不同的权限。对文件而言，当读取这个文件时，需要有r权限，当写入或者追加到文件时，需要有w权限。对目录而言，当列出目录内容时，需要具有r权限，当新建或删除子文件或子目录时，需要有w权限，当访问目录的子节点时，需要有x权限。不同于POSIX模型，HDFS权限模型中的文件没有sticky、setuid或setgid位，因为这里没有可执行文件的概念。
每个访问HDFS的用户进程的标识分为两个部分，分别是用户名和组名列表。每次用户进程访问一个文件或home目录，HDFS都要对其进行权限检查：
* 如果用户是home的所有者，则检查所有者的访问权限。
* 如果home关联的组在组名列表中出现，则检查组用户的访问权限；否则检查home其他用户的访问权限。
* 如果权限检查失败，则客户的操作会失败。
在HDFS中，客户端用户身份是通过宿主操作系统给出的。
对类Unix系统来说：
* 用户名等于whoami。
* 组列表等于ash -c groups。
每次文件或目录操作都传递完整的路径名给NameNode，每一个操作都会对此路径做权限检查。客户框架会隐式地将用户身份和与NameNode的连接关联起来，从而减少改变现有客户端API的需求。经常会有这种情况：当对一个文件的某一操作成功后，之后同样的操作却会失败，这是因为文件或路径上的某些目录可能已经不复存在了。比如，客户端首先开始读一个文件，它向NameNode发出一个请求以获取文件第一个数据块的位置。但接下去获取其他数据块的第二个请求可能会失败。另一方面，删除一个文件并不会撤销客户端已经获得的对文件数据块的访问权限。而权限管理能使得客户端对一个文件的访问许可在两次请求之间被收回。重复一下，权限的改变并不会撤销当前客户端对文件数据块的访问许可。
如果权限检查失败，所有使用一个路径参数的方法都可能抛出AccessControlException异常。
2.2.4 通信协议簇
HDFS所有的通信协议都是构建在TCP/IP协议上的。客户端通过一个可配置的端口连接到NameNode，通过ClientProtocol与NameNode交互。而DataNode是使用DataNodeProtocol与NameNode交互的。从ClientProtocol和DataNodeProtocol抽象出一个远程调用，在设计上，NameNode不会主动发起RPC，而是响应来自客户端和DataNode的RPC请求。
HDFS中的主要通信协议见表2-1。
表2-1 HDFS的主要通信协议
名 称
功 能
ClientProtocol
用户进程(包括客户端进程与DataNode进程)与NameNode进程之间进行通信所使用的协议
DataNodeProtocol
DataNode进程与NameNode进程进行之间通信所使用的协议，例如发送心跳报告和块状态报告
ClientDatanodeProtocol
客户端进程和DataNode进程之间在通信过程中所使用的协议，用户通过ClientProtocol协议，可操纵HDFS的目录命名空间、打开与关闭文件流等
NameNodeProtocol
NameNode进程与SecondaryNameNode进程之间进行通信的协议
DataTransferProtocol
负责客户端与数据节点之间的数据传输
InterDatanodeProtocol
DataNode进程之间进行通信的协议，例如客户端进程启动复制数据块，此时可能需要在DataNode节点之间进行块副本的流水线复制操作
(1) ClientProtocol。
ClientProtocol协议是用户进程(包括客户端进程与DataNode进程)与NameNode进程之间进行通信所使用的协议。当客户端进程想要与NameNode进程进行通信的时候，需要通过org.apache.hadoop.hdfs.DistributedFileSystem类，基于ClientProtocol协议来实现交互过程。用户代码通过ClientProtocol协议，可以操纵HDFS的目录命名空间、打开与关闭文件流等。
该接口协议中定义的与文件内容相关的操作主要有：①文件管理，文件的增、删、改，权限控制、文件块管理等；②文件系统管理，查看文件系统状态和设置元数据信息，例如容量、块大小、副本因子数等；③持久会话类，如放弃对指定块的操作、客户端同步等。
协议位置如图2-7所示。
图2-7 HDFS协议示意
(2) DataNodeProtocol。
该协议是用于DataNode与NameNode进行通信的协议，例如发送心跳报告和块状态报告。一般来说，NameNode不直接对DataNode进行RPC调用，如果一个NameNode需要与DataNode通信，唯一的方式，就是通过调用该协议接口定义的方法。
(3) ClientDatanodeProtocol。
当客户端进程需要与DataNode进程进行通信的时候，需要基于该协议。该协议接口定义数据块恢复的方法。
(4) NameNodeProtocol。
该协议接口定义了备用NameNode(Secondary NameNode)与NameNode进行通信所需进行的操作。其中，Secondary NameNode是一个用来辅助NameNode的服务器端进程，主要是对映像文件执行特定的操作，另外，还包括获取指定DataNode上块的操作。
(5) DataTransferProtocol。
该协议用于客户端与DataNode之间通信，主要实现文件块的读写及验证等操作。
(6) InterDatanodeProtocol。
该协议是DataNode进程之间进行通信的协议，例如客户端进程启动复制数据块，此时可能需要在DataNode节点之间进行块副本的流水线复制操作。
2.2.5 HDFS的高可用性
在Hadoop 2.0之前的版本中，NameNode在HDFS集群中存在单点故障，每一个集群中存在一个NameNode，如果NameNode所在的机器出现了故障，那么，将导致整个集群无法利用，直到NameNode重启或者在另一台主机上启动NameNode守护线程。在可预知的情况下(比如NameNode所在的机器硬件或者软件需要升级)以及在不可预测的情况下，如果NameNode所在的服务器崩溃了，都将导致整个集群无法使用。
在Hadoop 2.0及以后的版本中，HDFS的高可用性(High Availability)通过在同一个集群中运行两个NameNode实现：活动节点(Active NameNode)和备用节点(Standby NameNode)，允许在服务器崩溃或者机器维护期间快速地启用一个新的NameNode来恢复故障。在典型的HA集群中，通常有两台不同的机器充当NameNode。在任何时间都只有一台机器处于活动(Active)状态；另一台处于待命(Standby)状态。Active NameNode负责集群中所有客户端的操作；而Standby NameNode主要用于备用，它维持足够的状态，在必要时提供快速的故障恢复。
图2-8展示了HDFS的高可用性实现原理，其中，NameNode简写为NN，DataNode简写为DN。由图中可以看出，两个NameNode都与一组称为JNs(JournalNodes)的互相独立的守护进程保持通信，实现Standby NN的状态和Active NN的状态同步，使元数据保持一致。当Active NN执行任何有关命名空间的修改时，需要发送到一半以上的JNs上(通过Edits log进行持久化存储)。当Standby NN观察到Edits log的变化时，它会从JNs中读取edits信息，并更新其内部的命名空间。一旦Active NN出现故障，Standby NN首先确保自己在发生故障之前从JNs中读出了全部的修改内容，然后切换到Active状态。
为了提供快速的故障恢复，Standby NN也需要保存集群中各个文件块的存储位置。为了达到这一目的，DataNodes上需要同时配置这两个NameNode的地址，同时，与它们都建立心跳连接，并把block位置等信息发送给它们。对于JNs而言，任何时候，只允许一个NameNode作为数据写入者。对于DataNodes，只执行Active NN发送过来的命令。
图2-8 HDFS高可用性的实现
2.2.6 集中缓存管理
HDFS采用集中式的缓存管理(HDFS centralized cache management)技术。
HDFS集中式缓存管理是一个明确的缓存机制，它允许用户指定缓存的HDFS路径。NameNode会与保存着所需块数据的所有DataNode通信，并指导它们把块数据放在堆外缓存(off-heap)中。HDFS集中式缓存管理的架构如图2-9所示。
图2-9 HDFS集中式缓存的架构
由图2-9可以看到，NameNode负责协调集群中所有DataNode的off-heap缓存。NameNode周期性地接收来自每个DataNode的缓存报告，缓存报告中描述了缓存在给定DataNode中的所有块的信息。
NameNode通过借助DataNode心跳上的缓存和非缓存命令，来管理DataNode缓存。缓存指令存储在fsimage和editlog中，可以通过Java和命令行API添加、移除或修改，NameNode查询自身的缓存指令集，来确定应该缓存哪个路径。NameNode还存储了一组缓存池(缓存池是一个管理实体，用于管理缓存指令组)。
NameNode周期性地重复扫描命名空间和活跃的缓存，以确定需要缓存或不缓存哪个块，并向DataNode分配缓存任务。重复扫描也可以由用户动作来触发，比如添加或删除一条缓存指令，或者删除一个缓存池。
HDFS集中化缓存管理具有许多优势。
(1) 用户可以根据自己的逻辑指定一些经常被使用的数据或者高优先级任务对应的数据，让它们常驻内存而不被淘汰到磁盘。当工作集的大小超过了主内存大小(这种情况对于许多HDFS负载都是常见的)时，这一点尤为重要。
(2) 由于DataNode缓存是由NameNode管理的，所以在分配任务时，应用程序可以通过查询一组缓存块的位置，把任务和缓存块副本放在同一位置上，提高读操作的性能。
(3) 当数据块已经被DataNode缓存时，客户端就可以使用一个新的更高效的零拷贝读操作API。因为缓存数据的校验和只需由DataNode执行一次，所以，使用零拷贝API时，客户端基本上不会有开销。
(4) 集中式的缓存可以提高整个集群的内存使用率。当依赖于单独的DataNode上操作系统的内存进行缓存时，重复读取一个块数据会导致该块的一个或多个副本全部被送入内存中缓存。使用集中化缓存管理，用户就能明确地只锁定这N个副本中的M个了，从而节省了(N-M)个内存的使用量。
(5) 即使出现缓存数据的DataNode节点宕机、数据块移动或集群重启等问题，缓存都不会受到影响。因为缓存被NameNode统一管理并被持久化到fsimage和editlog中，出现问题后，NameNode会调度其他存储了这个数据副本的DataNode，把它读取到内存。
零拷贝(zero-copy)是实现主机或路由器等设备高速网络接口的主要技术。零拷贝技术通过减少或消除关键通信路径影响速率的操作，降低数据传输的操作系统开销和协议处理开销，从而有效提高通信性能，实现高速数据传输。
零拷贝技术可以减少数据拷贝和共享总线操作的次数，消除通信数据在存储器之间不必要的中间拷贝过程，有效地提高通信效率，是设计高速接口通道、实现高速服务器和路由器的关键技术之一。数据拷贝受制于传统的操作系统或通信协议，限制了通信性能。采用零拷贝技术，通过减少数据拷贝次数，简化协议处理的层次，在应用和网络间提供更快的数据通路，可以有效地降低通信延迟，增加网络的吞吐率。
2.2.7 日志和检查点
Hadoop中有两个非常重要的文件fsimage和edits，前面已经粗略地介绍了一些，这里做一个详细的讲解。它们位于NameNode的$dfs.namenode.name.dir/current/文件夹中。在current目录中，我们可以看到存在大量的以edits开头的文件和少量的以fsimage开头的文件，如图2-10所示。
图2-10 current目录
对edits和fsimage文件的概念说明如下。
(1) edits文件存放的是Hadoop文件系统的所有更新操作的日志，HDFS文件系统客户端执行的所有写操作首先会被记录到edits文件中。
(2) fsimage文件是Hadoop文件系统元数据的一个永久性检查点，其中包含Hadoop文件系统中的所有目录和文件的索引节点序列化信息。对于文件来说，包含的信息有修改时间、访问时间、块大小信息等；对于目录来说，包含的信息主要有修改时间、访问控制权限等信息。fsimage并不包含DataNode的信息，而是包含DataNode上块的映射信息，并存放到内存中，当一个新的DataNode加入到集群中时，DataNode都会向NameNode提供块的信息，而NameNode会定期地索取块的信息，以使得NameNode拥有最新的块映射。
其中，edits负责保存自最新检查点后命名空间的变化，起到日志的作用；而fsimage则保存了最新的元数据检查点信息。
fsimage和edits文件都是经过序列化的。在NameNode启动的时候，会将fsimage文件中的内容加载到内存中，然后再执行edits文件中的各项操作，使得内存中的元数据与实际的同步。存在于内存中的元数据支持客户端的读操作。
NameNode启动后，HDFS中的更新操作会重新写到edits文件中。对于一个文件来说，当所有的写操作完成以后，在向客户端发送成功代码之前，将同步更新edits文件。在NameNode运行期间，由于HDFS的所有更新操作都是直接写到edits中的，时间长了会导致edits文件变得很大。
在Hadoop 1.x中，通过SecondaryName合并fsimage和edits，以此来减小edits文件的大小，从而减少了NameNode重启的时间。在Hadoop 2.x中，已经不用SecondaryName，通过配置HA机制实现，即在standby NameNode节点上运行一个叫作CheckpointerThread的线程，这个线程调用StandbyCheckpointer类的doWork()函数，每隔一定的时间(可配置)做一次合并操作。
edits和fsimage文件中的内容使用普通文本编辑器是无法直接查看的，为此，Hadoop准备了专门的工具，用于查看文件的内容，分别为oev和oiv。
oev是offline edits viewer(离线edits查看器)的缩写，该工具只操作文件，并不需要Hadoop集群处于运行状态。oev提供了几个输出处理器，用于将输入文件转换为相关格式的输出文件，可以使用参数-p指定。目前支持的输出格式有binary(Hadoop使用的二进制格式)、xml(在不使用参数p时的默认输出格式)和stats(输出edits文件的统计信息)。由于没有与stats格式对应的输入文件，所以，一旦输出为stats格式，将不能再转换为原有格式。比如输入格式为binary，输出格式为xml，可以通过将输入文件指定为原来的输出文件，将输出文件指定为原来的输入文件，实现binary和xml的转换，而stats则不可以。
oev的具体语法可以通过在命令行输入"hdfs oev"来查看，如图2-11所示。
图2-11 oev的具体语法
oiv是offline image viewer的缩写，用于将fsimage文件的内容转储到指定文件中，以便于阅读，该工具还提供了只读的WebHDFS API，以允许离线分析和检查Hadoop集群的命名空间。oiv在处理非常大的fsimage文件时是相当快的，如果不能够处理fsimage，它会直接退出。oiv不具备向后兼容性，比如使用Hadoop 2.4版本的oiv不能处理hadoop 2.3版本的fsimage，只能使用Hadoop 2.3版本的oiv。与oev一样，oiv也不需要Hadoop集群处于运行状态。oiv的具体语法可以通过在命令行输入"hdfs oiv"来查看。
如果fsimage丢失或者损坏了，我们将失去文件到块的映射关系，也就无法使用DataNode上的所有数据了。因此，定期及时地备份fsimage和edits文件非常重要。
fsimage和edit log是HDFS的核心数据结构。这些文件的损坏会导致整个集群的失效。因此，NameNode可以配置成支持多个fsimage和edit log的副本。任何fsimage和edit log的更新都会同步到每一份副本中。同步更新多个edit log副本会降低NameNode的命名空间事务处理速率。但是这种降低是可以接受的，因为HDFS程序中大量产生的是数据请求，而不是元数据请求。NameNode重新启动时，会选择最新一致的fsimage和edit log。
2.2.8 HDFS快照
在Hadoop 2.x版本中，HDFS提供了支持元数据快照的解决方案。
快照(Snapshot)支持存储在某个时间的数据复制，当HDFS数据损坏时，可以回滚到过去一个已知正确的时间点。
快照分为两种：一种是建立文件系统的索引，每次更新文件不会真正改变文件，而是新开辟一个空间用来保存更改的文件；一种是复制所有的文件系统。HDFS把元数据和数据分离，元数据被存储在单独的NameNode上，实际的数据被复制并扩散到整个集群。使用单个节点来管理元数据，使我们能够使用一个单一的逻辑时钟，建立元数据快照。
HDFS的快照是在某一时间点对指定文件系统复制，可以是整个文件系统的，也可以是文件系统的一部分。快照采用只读模式，对重要数据进行恢复、防止用户错误性的操作。HDFS的快照有以下特征。
(1) 快照的创建是瞬间的，代价为O(1)，取决于子节点扫描文件目录的时间。
(2) 当且仅当快照的文件目录下有文件更新时，才会占用小部分内存，占用内存的大小为O(M)，其中，M为更改文件或者目录的数量。
(3) 新建快照时，DataNode中的block不会被复制，快照中只是记录了文件块的列表和大小等信息。
(4) 快照不会影响正常文件系统的读写等操作。对做快照之后的数据进行的更改将会按照时间顺序逆序记录下来，用户访问的还是当前最新的数据，快照里的内容为快照创建的时间点时文件的内容减去当前文件的内容。
2.3 HDFS的数据存储
前面主要介绍了HDFS系统的运行机制和原理，本节将介绍HDFS系统中的文件数据是如何存储和管理的。
2.3.1 数据完整性
I/O操作过程中，难免会出现数据丢失或脏数据，数据传输的量越大，出错的概率越高。校验错误最常用的办法，就是传输前计算一个校验和，传输后计算一个校验和，两个校验和如果不相同，就说明数据存在错误。为了保证数据的完整性，一般采用下列数据校验技术：①奇偶校验技术；②MD5、SHA1等校验技术；③CRC-32循环冗余校验技术；④ECC内存纠错校验技术。其中，比较常用的错误校验码是CRC-32。
HDFS将一个文件分割成一个或多个数据块，这些数据块被编号后，由名字节点保存，通常需要记录的信息包括文件的名称、文件被分成多少块、每块有多少个副本、每个数据块存放在哪个数据节点上、其副本存放于哪些节点上，这些信息被称为元数据。
HDFS为了保证数据的完整性，采用校验和(checksum)检测数据是否损坏。当数据第一次引入系统时计算校验和，并且在一个不可靠的通道中传输的时候，再次检验校验和。但是，这种技术并不能修复数据(注意：校验和也可能损坏，但是，由于校验和小得多，所以可能性非常小)。数据校验和采用的是CRC-32，任何大小的数据输入都可以通过计算，得出一个32位的整数校验和。
DataNode在接收到数据后存储该数据及其校验和，或者将数据和校验和复制到其他的DataNode上。当客户端写数据时，会将数据及其DataNode发送到DataNode组成的管线，最后一个DataNode负责验证校验和，如果有损坏，则抛出ChecksumException，这个异常属于IOException的子类。客户端读取数据的时候，也会检验校验和，会与DataNode上的校验和进行比较。每个DataNode上面都会有一个用于记录校验和的日志。客户端验证完之后，会告诉DataNode，然后更新这个日志。
不仅客户端在读写数据的时候验证校验和，每个DataNode也会在后台运行一个DataBlockScanner，从而定期检查存储在该DataNode上面的数据块。
如果客户端发现有block坏掉，按照以下步骤进行恢复。
(1) 客户端在抛出ChecksumException之前，会把坏的block和block所在的DataNode报告给NameNode。
(2) NameNode把这个block标记为已损坏，这样，NameNode就不会把客户端指向这个block，也不会复制这个block到其他的DataNode。
(3) NameNode会把一个好的block复制到另外一个DataNode。
(4) NameNode把坏的block删除。
HDFS会存储每个数据块的副本，可以通过数据副本来修复损坏的数据块。客户端在读取数据块时，如果检测到错误，首先向NameNode报告已损坏的数据块及其正在尝试读取操作的这个DataNode。NameNode会将这个数据块标记为已损坏，对这个数据块的请求会被NameNode安排到另一个副本上。之后，它安排这个数据块的另一个副本复制到另一个 DataNode上，如此，数据块的副本因子又回到期望水平。此后，已损坏的数据块副本会被删除。
Hadoop的LocalFileSystem执行客户端的校验和验证。当写入一个名为filename的文件时，文件系统客户端会明确地在包含每个文件块校验和的同一个目录内建立一个名为filename.crc的隐藏文件。
2.3.2 数据压缩
Hadoop作为一个较通用的海量数据处理平台，每次运算都会需要处理大量的数据。使用文件和数据压缩技术有明显的优点：①节省数据占用的磁盘空间；②加快数据在磁盘和网络中的传输速度，从而提高系统的处理速度。我们来了解一下Hadoop中的文件压缩。
Hadoop支持多种压缩格式。我们可以把数据文件压缩后再存入HDFS，以节省存储空间。在表2-2中，列出了几种压缩格式。
表2-2 Hadoop中的压缩格式
压缩格式
Unix工具
算 法
文件扩展名
多文件支持
可分 割
Deflate
无
Deflate
.deflate
No
No
Gzip
gzip
Deflate
.gz
No
No
Zip
zip
Deflate
.zip
Yes
Yes
Bzip
bzip2
Bzip2
.bz2
No
Yes
LZO
lzop
LZO
.lzo
No
No
所有的压缩算法都存在空间与时间的权衡：更快的压缩速率和解压速率是以牺牲压缩率为代价的。Deflate算法是同时使用了LZ77与哈夫曼编码的一个无损数据压缩算法，源代码可以在zlib库中找到。Gzip算法是以Deflate算法为基础扩展出来的一种算法。Gzip在时间和空间上比较适中，Bzip2算法压缩比Gzip更有效，但速度更慢。Bzip2的解压速度比它的压缩速度要快，但与其他压缩格式相比，又是最慢的，但压缩效果明显是最好的。
使用压缩，有两个比较麻烦的地方：第一，有些压缩格式不能被分块、并行地处理，比如Gzip；第二，另外的一些压缩格式虽然支持分块处理，但解压的过程非常缓慢，使作业瓶颈转移到了CPU上，例如Bzip2。LZO是一种既能够被分块并且并行处理速度也非常快的压缩算法。在Hadoop中，使用LZO压缩算法可以减小数据的大小并缩短数据的磁盘读写时间，在HDFS中存储压缩数据，可以使集群能保存更多的数据，延长集群的使用寿命。不仅如此，由于MapReduce作业通常瓶颈都在I/O上，存储压缩数据就意味着更少的I/O操作，作业运行更加高效。例如，将压缩文件直接作为入口参数交给MapReduce处理，MapReduce会自动根据压缩文件的扩展名来自动选择合适的解压器处理数据。处理流程如图2-12所示。
图2-12 MapReduce的压缩框架
LZO的压缩文件是由许多小的blocks组成(约256KB)，使得Hadoop的作业可以根据block的划分来分块工作(split job)。不仅如此，LZO在设计时就考虑到了效率问题，它的解压速度是Gzip的两倍，这就让它能够节省很多的磁盘读写，它的压缩比不如Gzip，大约压缩出来的文件比Gzip压缩的大一半，但是，这仍然比没有经过压缩的文件要节省20%~50%的存储空间，这样，就可以在效率上大大地提高作业执行的速度。
在考虑如何压缩由MapReduce程序将要处理的数据时，压缩格式是否支持分割是很重要的。比如，存储在HDFS中的未压缩的文件大小为1GB，HDFS的块大小为64MB，所以该文件将被存储为16块，将此文件用作输入的MapReduce作业，会创建1个输入分片(split，也称为"分块"。对应block，我们统一称为"块")，每个分片都被作为一个独立map任务的输入，单独进行处理。
现在假设该文件是一个Gzip格式的压缩文件，压缩后的大小为1GB。与前面一样，HDFS将此文件存储为16块。然而，针对每一块创建一个分块是没有用的，因为不可能从Gzip数据流中的任意点开始读取，map任务也不可能独立于其他分块只读取一个分块中的数据。Gzip格式使用Deflate算法来存储压缩过的数据，Deflate将数据作为一系列压缩过的块进行存储。但是，每块的开始没有指定用户在数据流中任意点定位到下一个块的起始位置，而是其自身与数据流同步。因此，Gzip不支持分割(块)机制。
在这种情况下，MapReduce不分割Gzip格式的文件，因为它知道输入是Gzip压缩格式的(通过文件扩展名得知)，而Gzip压缩机制不支持分割机制。这样是以牺牲本地化为代价的：一个map任务将处理16个HDFS块。大都不是map的本地数据。与此同时，因为map任务少，所以作业分割的粒度不够细，从而导致运行时间变长。
在我们假设的例子中，如果是一个LZO格式的文件，我们会遇到同样的问题，因为基本压缩格式不为reader提供方法使其与流同步。但是，Bzip2格式的压缩文件确实提供了块与块之间的同步标记(一个48位的PI近似值)，因此它支持分割机制。
对于文件的收集，这些问题会稍有不同。Zip是存档格式，因此，它可以将多个文件合并为一个Zip文件。每个文件单独压缩，所有文档的存储位置存储在Zip文件的尾部。这个属性表明Zip文件支持文件边界处分割，每个分片中包括Zip压缩文件中的一个或多个文件。
2.3.3 序列化
序列化是指将结构化对象转换成字节流，以便于进行网络传输，或写入持久存储的过程。与之相对的反序列化，就是将字节流转化为一系列结构化对象的过程。
(1) 序列化有以下特征。
* 紧凑：可以充分利用稀缺的带宽资源。
* 快速：通信时大量使用序列化机制，因此，需要减少序列化和反序列化的开销。
* 可扩展：随着通信协议的升级而可升级。
* 互操作：支持不同开发语言的通信。
(2) 序列化的主要作用如下：
* 作为一种持久化格式。
* 作为一种通信的数据格式，支持不同开发语言的通信。
* 作为一种数据拷贝机制。
Hadoop的序列化机制与Java的序列化机制不同，它实现了自己的序列化机制，将对象序列化到流中，值得一提的是，Java的序列化机制是不断地创建对象，但在Hadoop的序列化机制中，用户可以复用对象，减少了Java对象的分配和回收，提高了应用效率。
在分布式系统中，进程将对象序列化为字节流，通过网络传输到另一进程，另一进程接收到字节流，通过反序列化，转回到结构化对象，以实现进程间通信。在Hadoop中，Mapper、Combiner、Reducer等阶段之间的通信都需要使用序列化与反序列化技术。举例来说，Mapper产生的中间结果
需要写入到本地硬盘，这是序列化过程(将结构化对象转化为字节流，并写入硬盘)，而Reducer阶段，读取Mapper的中间结果的过程则是一个反序列化过程(读取硬盘上存储的字节流文件，并转回为结构化对象)。需要注意的是，能够在网络上传输的只能是字节流，Mapper的中间结果在不同主机间洗牌时，对象将经历序列化和反序列化两个过程。
序列化是Hadoop核心的一部分，在Hadoop中，位于org.apache.hadoop.io包中的Writable接口是Hadoop序列化格式的实现，Writable接口提供两个方法：
public interface Writable {
void write(DataOutput out) throws IOException;
void readFields(DataInput in) throws IOException;
}
不过，没有提供比较功能，需要进行比较的话，要实现WritableComparable接口：
public interfaceWritableComparable
extends Writable, Comparable
{ }
Hadoop的Writable接口是基于DataInput和DataOutput实现的序列化协议，紧凑(高效使用存储空间)、快速(读写数据、序列化与反序列化的开销小)。
Hadoop中的键(key)和值(value)必须是实现了Writable接口的对象(键还必须实现 WritableComparable，以便进行排序)。
Hadoop自身提供了多种具体的Writable类，包含了常见的Java基本类型(boolean、byte、short、int、float、long和double等)和集合类型(BytesWritable、ArrayWritable和MapWritable等)，如图2-13所示。
图2-13 Writable接口
Text：Text是UTF-8的Writable，可以理解为与java.lang.String相类似的Writable。
Text类替代了UTF-8类。Text是可变的，其值可以通过调用set()方法来改变。最大可以存储2GB的大小。
NullWritable：NullWritable是一种特殊的Writable类型，它的序列化长度为零，可以用作占位符。
BytesWritable：BytesWritable是一个二进制数据数组封装，序列化格式是一个int字段。BytesWritable是可变的，其值可以通过调用set()方法来改变。
ObjectWritable：ObjectWritable适用于字段使用多种类型时。
ArrayWritable和TwoDArrayWritable是针对数组和二维数组的。
MapWritable和SortedMapWritable是针对Map和SortMap的。
虽然Hadoop内建了多种Writable类供用户选择，Hadoop对Java基本类型的包装Writable类实现的RawComparable接口，使得这些对象不需要反序列化过程，便可以在字节流层面进行排序，从而大大缩短了比较的时间开销。但是，当我们需要更加复杂的对象时，Hadoop的内建Writable类就不能满足我们的需求了(需要注意的是Hadoop提供的Writable集合类型并没有实现RawComparable接口，因此也不满足我们的需要)，这时，我们就需要定制自己的Writable类，特别在将其作为键(key)的时候更应该如此，以求实现更高效的存储和快速的比较。
2.4 HDFS的安装和配置
HDFS通过一个NameNode作为master来统筹管理多个作为slaves的DataNode，是Hadoop的核心功能组件。安装完Hadoop后，即完成了HDFS的安装。HDFS为分布式计算存储提供了底层支持，功能及用法类似于本地文件系统。
2.4.1 Hadoop的安装
HDFS是Hadoop的核心项目，安装程序已经包含在Hadoop核心程序包中，从一定意义上讲，HDFS的安装配置与Hadoop是一致的。
Hadoop集群安装主要有以下工作。
1. 准备工作
(1) 首先从官网下载一个Hadoop程序包。一般Hadoop分为两个压缩文件，一个是源代码，一个是编译好的程序包。用户可根据需要选择不同的版本下载安装。
(2) 安装Linux服务器和必要的软件。Hadoop既可以支持单台服务器的伪分布式部署，也可以多台集群配置部署。必需的软件主要有Java、SSH等。
(3) 对Linux进行必要的系统配置。如主机名、DNS、环境变量等。
2. 安装Java并配置SSH无密码访问
通过配置SSH实现基于公钥方式的无密码登录，具体操作步骤为：创建一个新的hadoop账户，生成这个账户的SSH公钥，配置公钥授权文件及设置SSH服务登录方式等。
3. 解压安装Hadoop安装包
将安装软件解压到集群内的所有机器上。
通常，安装路径要一致，一般用HADOOP_HOME指代安装的根路径，集群里的所有机器的HADOOP_HOME路径相同。
如果集群内机器的环境完全一样，可以在一台机器上配置好，然后将整个文件夹拷贝到其他机器的相同位置即可。
4. 配置hadoop-env.sh文件
包含Hadoop启动的时候配置的环境变量，包括Hadoop自身配置、JDK等的设置。
5. 配置core-site.xml、hdfs-site.xml、mapred-site.xml等文件
配置信息将在后面详细介绍。
6. 格式化HDFS文件系统
这类似于Windows文件系统使用前需要格式化。
7. 启动所有节点并测试
本章中，我们将下载使用Hadoop 2.6.0版本，在CentOS 6.5上分别搭建伪分布式环境(即在单独的一台服务器上安装运行所有的Hadoop功能组件)和集群环境作为实验平台。
(1) 伪分布式部署。
① 安装CentOS 6.5操作系统，如图2-14所示。
图2-14 安装CentOS操作系统
② 检查Java安装情况，如图2-15所示。如未安装，可用rpm包或者yum等方式安装Java。这里，我们使用Java1.7版本。
图2-15 Java安装包
③ 修改hosts文件，设置主机名。在hosts文件最后，加入一行主机名与IP地址，如图2-16所示。
图2-16 hosts文件
④ 使用useradd命令创建"hadoop"用户，登录并配置SSH无密码登录，如图2-17所示。
图2-17 配置SSH
进入.ssh目录，将id_rsa.pub复制，并且命名为"authorized_keys"，然后设置文件权限，如图2-18所示。
图2-18 设置文件权限
⑤ 将Hadoop安装包解压到要安装的路径中。这里，将Hadoop安装在/home/hadoop/用户目录下。
⑥ 配置环境变量。在/etc/profile文件中配置Java及Hadoop相关的环境变量，并使之生效。如图2-19所示。
图2-19 配置环境变量
⑦ 配置Hadoop安装文件中的环境变量。
配置etc/hadoop/hadoop-env.sh文件，如图2-20所示。
图2-20 etc/hadoop/hadoop-env.sh文件
配置etc/hadoop/core-site.xml文件，加入如图2-21所示的内容。
图2-21 配置etc/hadoop/core-site.xml文件
配置etc/hadoop/hdfs-site.xml文件，加入如图2-22所示的内容。
图2-22 配置etc/hadoop/hdfs-site.xml文件
配置etc/hadoop/slaves，加入DataNode节点，即当前主机名，如图2-23所示。
图2-23 配置etc/hadoop/slaves
⑧ 在服务器上创建目录/home/hadoop/hadoop/tmp、/home/hadoop/hadoop/dfs/name、/home/hadoop/hadoop/dfs/data，并赋予读写权限。
至此，基于单台服务器的Hadoop伪集群安装部署完成，启动运行即可。
(2) 集群部署。
分布式集群部署与单机Hadoop类似，流程上稍微复杂一些。我们以安装包括1个NameNode和3个DataNode的Hadoop集群为例。配置见表2-3。
表2-3 Hadoop集群配置
节点名称
IP
说 明
h.master
192.168.150.129
NameNode
h.slave1
192.168.150.130
DataNode
h.slave2
192.168.150.131
DataNode
h.slave3
192.168.150.132
DataNode
① 在各个节点安装CentOS6.5操作系统，安装Java、SSH等软件，配置允许SSH通过防火墙或者直接关闭各个主机的防火墙；添加名为"hadoop"的Linux用户；修改"/etc/sysconfig/network"中的hostname设置。
② 配置各个主机的IP，并修改"/etc/hosts"文件，将每个节点的主机名写入到hosts文件中进行解析，如图2-24所示。
图2-24 修改"/etc/hosts"文件
③ 配置SSH无密码登录。首先在各个节点的hadoop用户下创建密钥，然后将4个节点的公钥文件id_rsa.pub的内容放到authorized_keys文件里，并设置文件权限。最后测试节点之间是否能够通过SSH互相连通，如图2-25所示。
④ 将Hadoop安装包解压到要安装的路径中。这里，我们将Hadoop安装在用户目录"/home/hadoop/"下面。
⑤ 配置环境变量。在所有节点的"/etc/profile"文件中配置Java及Hadoop相关的环境变量，并使之生效，如图2-26所示。
图2-25 SSH无密码登录配置
图2-26 profile文件的配置
⑥ 在NameNode节点中，修改Hadoop安装目录中的配置文件。
配置etc/hadoop/hadoop-env.sh文件，增加Java接口设置，如图2-27所示。
图2-27 配置etc/hadoop/hadoop-env.sh文件
配置etc/hadoop/core-site.xml，加入如图2-28所示的内容。
图2-28 配置etc/hadoop/core-site.xml
配置etc/hadoop/hdfs-site.xml，加入如图2-29所示的内容。
图2-29 配置etc/hadoop/hdfs-site.xml
配置etc/hadoop/slaves，加入DataNode节点，如图2-30所示。
图2-30 配置etc/hadoop/slaves
⑦ 创建Hadoop数据目录：/home/hadoop/hadoop/tmp、/home/hadoop/hadoop/dfs/name、/home/hadoop/hadoop/dfs/data，并赋予读写权限。
⑧ 将目录"/home/hadoop/Hadoop"整体复制到其他三个节点，如图2-31所示。
图2-31 复制目录"/home/hadoop/Hadoop"
至此，Hadoop集群安装完成。
主要区别在于：
* SSH无密码登录配置。需要在每一台Hadoop的节点上都配置SSH无密码登录，使节点之间能够相互访问。
* 系统配置文件。在每台服务器上进行系统配置及网络主机名配置。
* Hadoop配置。在Hadoop安装包的etc/hadoop/slaves中加入所有数据节点。其他配置，如文件副本数量等，可按实际情况设置。
2.4.2 HDFS的配置
Hadoop与HDFS相关的配置文件主要是core-site.xml、hdfs-site.xml、mapred-site.xml等三个配置文件，默认情况下，这些配置文件都是空的。
1. core-site.xml的配置
core-site.xml是Hadoop的核心配置项，是全局配置，包括HDFS和MapReduce常用的I/O设置等。其中，涉及HDFS的主要配置选项见表2-4。
表2-4 core-site.xml的主要配置选项
属性名称
属性 值
说 明
hadoop.tmp.dir
/tmp/hadoop
临时文件夹，指定后需将使用到的所有子级文件夹都要手动创建出来，否则无法正常启动服务
hadoop.http.authentication.
type
simple | kerberos
验证方式，默认为简单，也可自己定义Class，需配置所有节点
hadoop.http.authentication.
token.validity
36000
验证令牌的有效时间，需配置所有节点
hadoop.http.authentication.cookie.domain
domian.tld
HTTP验证所使用的Cookie的域名，IP地址访问则该项无效，必须给所有节点都配置域名
hadoop.http.authentication.simple.anonymous.allowed
true | false
简单验证专用。默认true，允许匿名访问
hadoop.http.authentication.kerberos.keytab
/home/xianglei/hadoop.keytab
Kerberos验证专用，密钥文件存放位置
hadoop.security.
authorization
true | false
Hadoop服务层级验证安全验证，需配合hadoop-policy.xml使用，配置好以后用dfsadmin,mradmin -refreshServiceAcl刷新生效
hadoop.security.
authentication
simple | kerberos
Hadoop本身的权限验证，非HTTP访问，simple或者kerberos
hadoop.logfile.size
1000000000
设置日志文件大小，超过则滚动新日志
hadoop.logfile.count
20
最大日志数
fs.default.name
hdfs://master:9000
定义NameNode节点的URI和端口设定
fs.checkpoint.dir
${hadoop.tmp.dir}(默认)
/dfs/namesecondary
备份元数据节点目录，一般这些目录是不同的块设备，不存在的目录会被忽略掉
fs.trash.interval
10800
HDFS垃圾箱设置，可以恢复误删除，单位是分钟数，0为禁用
io.bytes.per.checksum
1024
每校验码所校验的字节数，不大于io.file.buffer.size
io.skip.checksum.errors
true | false
处理序列化文件时跳过校验码错误，不抛出异常。默认是false 续表
属性名称
属性 值
说 明
io.serializations
org.apache.hadoop.io.serializer.
WritableSerialization
序列化的编解码器
io.seqfile.compress.
blocksize
1024000
块压缩的序列化文件的最小块大小，字节
io.compression.codecs
org.apache.hadoop.io.compress.
DefaultCodec,
com.hadoop.compression.lzo.
LzoCodec,
com.hadoop.compression.lzo.
LzopCodec,
org.apache.hadoop.io.compress.
GzipCodec,
org.apache.hadoop.io.compress.
BZip2Codec,
org.apache.hadoop.io.compress.
SnappyCodec
Hadoop所使用的编解码器，Gzip、Bzip2为自带，LZO需安装hadoopgpl或者kevinweil，逗号分隔。
snappy需要单独安装并修改hadoop-env.sh
配置LD_LIBRARY_PATH=snappy类库位置
io.compression.codec.
lzo.class
com.hadoop.compression.lzo.
LzoCodec
LZO所使用的压缩编码器
io.file.buffer.size
131072
用作序列化文件处理时读写buffer的大小
webinterface.private.actions
true | false
Web交互的行为设定。设为true，则JobTracker和NameNode的tracker网页会出现杀任务删文件等操作连接，默认是false
topology.script.file.name
/hadoop/bin/RackAware.py
机架感知位置脚本
topology.script.number.args
1000
机架感知脚本管理的主机数，IP地址
分布式集群部署模式时，核心配置文件core-site.xml的参考配置格式如下：
fs.defaultFS
hdfs://master:9000
io.file.buffer.size
131072
hadoop.tmp.dir
file:/home/hadoop/tmp
hadoop.proxyuser.hduser.hosts
*
hadoop.proxyuser.hduser.groups
*
2. hdfs-site.xml配置
hdfs-site.xml是HDFS的局部配置文件，主要配置选项见表2-5。
表2-5 hdfs-site.xml的主要配置选项
属性名称
属性 值
说 明
dfs.namenode.handler.count
10
NameNode启动后开启的线程数
dfs.datanode.http.address
0.0.0.0:50075
DataNode的tracker页面监听地址和端口
dfs.datanode.ipc.address
0.0.0.0:50020
DataNode的IPC监听端口，为0的话会在随机端口监听，通过心跳通知NameNode
dfs.datanode.address
0.0.0.0:50010
DataNode服务端口，为0则随机监听
dfs.datanode.max.xcievers
256
Linux下的打开文件最大数量，当出现
DataXceiver报错的时候，需要调大
dfs.datanode.data.dir.perm
755
DataNode所使用的本地文件夹的路径权限，默认755
dfs.datanode.failed.
volumes.tolerated
0
DataNode磁盘卷出错次数。0次则任何卷出错都要停止DataNode
dfs.name.dir
${hadoop.tmp.dir}/dfs
/name
存储在本地的NN数据镜像的目录，作为NameNode的冗余备份
dfs.data.dir
/var/data/hadoop/hdfs/data1,
/var/data/hadoop/hdfs/data2,
/var/data/hadoop/hdfs/data3
真正的DataNode数据保存路径，可以多分区，逗号分隔
dfs.heartbeat.interval
3
DataNode心跳检测时间间隔，单位为秒
dfs.client.block.write.retries
3
数据块写入最多重试次数，在此次数之前不会捕获失败
dfs.max.objects
0
dfs最大并发对象数，HDFS中的目录块都会被认为是一个对象，0表示不限制
dfs.safemode.extension
30
指定系统退出安全模式时需要的延迟时间，单位为秒，默认为30
dfs.http.address
0.0.0.0:50070
NameNode的Web管理端口
dfs.https.enable
true | false(默认)
NameNode的tracker是否支持HTTPS协议
dfs.https.address
0.0.0.0:50470
NameNode的tracker页面监听访问地址
dfs.permissions
true | false
dfs权限是否打开，一般设置为false
dfs.permissions.supergroup
supergroup(默认)
设置hdfs超级权限组
dfs.replication
3
hdfs数据块的副本数，默认3，理论上数量越大速度越快，但需要的存储空间也更多
续表
属性名称
属性 值
说 明
dfs.replication.max
512
DataNode数据块的最大副本数量。
DataNode故障临时恢复时会导致数据超过默认副本数，此属性通常不用配置
dfs.replication.min
1
DataNode数据块的最小副本数量
dfs.replication.interval
3
NameNode计算复制DataNode节点的工作周期数，单位为秒。一般情况下不用指定
dfs.hosts
/usr/local/hadoop/conf
/dfs.hosts.allow
DataNode的白名单。仅在dfs.hosts文件中指定的DataNode有权限连接到NameNode上。如果该参数不指定，那么默认所有的DataNode都可以连接到NameNode
dfs.hosts.exclude
/usr/local/hadoop/conf
/dfs.hosts.deny
DataNode黑名单
3. mapred-site.xml配置
mapred-site.xml用于配置MapReduce使用的框架，与HDFS的关联主要是文件和I/O操作。这里简单介绍一下mapred-site.xml的相关配置项，见表2-6。
表2-6 mapred-site.xml的相关配置项
属性名称
属性 值
说 明
mapred.local.dir
/data1/hdfs/mapred/local,
/data2/hdfs/mapred/local,
...
mapred是做本地计算所使用的文件夹，可以配置多块硬盘，以逗号分隔
mapred.system.dir
/data1/hdfs/mapred/system,
/data2/hdfs/mapred/system,
...
mapred存放控制文件所使用的文件夹，可配置多块硬盘，逗号分隔
mapred.temp.dir
/data1/hdfs/mapred/temp,
/data2/hdfs/mapred/temp,
...
mapred是共享的临时文件夹路径，可配置多块硬盘，以逗号分隔
mapred.local.dir.minspacestart
1073741824
本地运算文件夹剩余空间低于该值则不在本地做计算。单位是字节数，默认为0
mapred.local.dir.minspacekill
1073741824
本地计算文件夹剩余空间低于该值则不再申请新任务，单位是字节数，默认为0
hadoop.job.history.location
-
job历史文件保存路径，无可配置参数，也不用写在配置文件中，默认在logs的history文件夹下
hadoop.job.history.user.location
用户历史文件的存放位置
io.sort.factor
30
处理流合并时的文件排序数
io.sort.mb
600
排序所使用的内存数量，单位是兆，默认为1
2.4.3 启动HDFS
配置完成后，需要先在NameNode中格式化HDFS系统，然后再启动。
1. HDFS的格式化
如图2-32所示，我们使用"hdfs namenode -format"命令格式化Hadoop 2.6.0的HDFS系统。
......
图2-32 HDFS的格式化
2. HDFS的启动
通过执行脚本start-dfs.sh或start-all.sh启动Hadoop文件系统，如图2-33所示。
图2-33 启动Hadoop
3. 验证
可以使用Java自带的小工具jps查看进程，如图2-34所示；也可以用"hdfs dfsadmin -report"命令查看Hadoop集群的状态，如图2-35所示。
图2-34 jps命令 图2-35 查看集群状态
打开浏览器，输入"http://localhost:50070"，页面显示正常内容，说明Hadoop安装成功并在运行中，如图2-36所示。
图2-36 Hadoop Web的状态
2.5 小 结
本章介绍了分布式文件系统及HDFS，并重点介绍了HDFS的结构组成、运行原理，以及数据操作、数据完整性、压缩存储、序列化等诸多优点和特性。
通过学习本章的内容，读者应能够对HDFS分布式文件系统有一定的认识，掌握HDFS的内部运行机制，为下一章的操作打下基础。
当然，HDFS也有其自身的缺陷和不足，比如不适合存储大量的小文件、不适合大量的随机读文件操作等，有兴趣的读者不妨扩展一下。
本章最后详细介绍了Hadoop的安装配置，读者要熟练掌握并实际完成Hadoop集群配置，后续学习实践也将在本章安装的环境的基础上进行。
大数据：从基础理论到最佳实践 pdf下载声明
本pdf资料下载仅供个人学习和研究使用，不能用于商业用途，请在下载后24小时内删除。如果喜欢，请购买正版
