p.p1 { margin: 0; text-align: center; font: 12px Helvetica; color: rgba(69, 69, 69, 1) }
p.p2 { margin: 0 0 2px; text-align: justify; font: 14px Helvetica; color: rgba(69, 69, 69, 1) }
p.p3 { margin: 0; text-align: justify; font: 12px Helvetica; color: rgba(69, 69, 69, 1) }
p.p4 { margin: 0; font: 12px Helvetica; color: rgba(69, 69, 69, 1) }
p.p5 { margin: 0; font: 12px “PingFang SC”; color: rgba(69, 69, 69, 1) }
p.p6 { margin: 0; text-align: justify; font: 12px Helvetica; color: rgba(69, 69, 69, 1); min-height: 14px }
p.p7 { margin: 0 0 0 46px; text-align: justify; font: 12px Helvetica; color: rgba(69, 69, 69, 1); min-height: 14px }
p.p8 { margin: 0; text-align: justify; font: 12px “PingFang SC”; color: rgba(69, 69, 69, 1) }
p.p9 { margin: 0 0 0 46px; text-align: justify; font: 12px “PingFang SC”; color: rgba(69, 69, 69, 1) }
li.li4 { margin: 0; font: 12px Helvetica; color: rgba(69, 69, 69, 1) }
li.li5 { margin: 0; font: 12px “PingFang SC”; color: rgba(69, 69, 69, 1) }
span.s1 { font: 14px “PingFang SC” }
span.s2 { font: 12px “PingFang SC” }
span.s3 { font: 12px Helvetica }
span.Apple-tab-span { white-space: pre }
ul.ul1 { list-style-type: disc }

1.HDFS介绍

HDFS 为了做到可靠性( reliability ) 创建了多份数据块（data blocks）的复制（replicas），并将它们放置在服务器群的计算节点中（compute nodes），MapReduce就可以在它们所在的节点上处理这些数据了。

1.1.HDFS结构

NameNode DataNode

存储元数据（文件名，文件属性）存储文件内容

元数据保存在内存中（磁盘中也会有一份），工作过程中在内存中读数据文件内容保存在磁盘

保存文件，block，datanode之间的映射关系维护了block id到datanode本地文件的映射关系

1.2 HDFS运行机制

一个名字节点和多个数据节点
数据复制（冗余机制）

存放的位置（机架感知策略）
故障检测
数据节点

心跳包（检测是否宕机）
块报告（安全模式下检测）
数据完整性检测（校验和比较）

名字节点（日志文件，镜像文件）
空间回收机制

1.3.HDFS优点

高容错性
数据自动保存多个副本
副本丢失后，自动恢复
适合批处理
移动计算而非数据
数据位置暴露给计算框架
适合大数据处理
GBTB甚至PB级数据
百万规模以上的文件数量
10k+节点
可构建在廉价机器上
通过多副本提高可靠性
提供了容错和恢复机制

1.4 HDFS缺点

低延迟数据访问
比如毫秒级
低延迟与高吞吐率
小文件存取
占用NameNode大量内存
寻道时间超过读取时间
并发写入、文件随即修改
一个文件只能有一个写者
仅支持append

NameNode存储的是元数据，元数据的多少取决于文件的多少，元数据是存储在内存中的。

不适合大量的小文件存储

国内大部分网盘是用的HDFS

1.5 HDFS架构

HDFS客户端请求的是NameNode, NameNode负责处理任务的请求，NameNode再将请求转发给DataNode,请求DataNode实际是HDFS客户端请求，图有问题。

DataNode把所有数据都存储在磁盘上

1.5.1 HDFS数据存储单元（block）

文件被切分成固定大小的数据块
默认数据块大小为64mb，可配置
若文件大小不到64mb，则单独存成一个block
一个文件存储方式
按大小被切分成若干个block，存储到不同节点上
默认情况下每个block都有三个副本
block大小和副本数通过client端上传文件时设置，文件上传成功后副本数可以变更，Block Size 不可变更

一个块只可能存一个文件中的数据。只是一个逻辑结构，若不满64mb的，磁盘上存储的是文件的实际大小。

三个副本存储在不同机器上

1.6节点

1.6.1 NameNode（NN）

NameNode主要功能：接受客户端的读写服务
NameNode保存metadata（元数据）信息包括
文件owership 和 permissions
文件包含哪些块
block保存在哪个DataNode上（由DataNode启动时上报，存在内存中）
NameNode的metadate信息在启动后会加载到内存
metadata存储到磁盘文件名为 fsimage
block的位置信息不会保存到 fsimage
edits记录对metadata的操作日志

整个过程中，metadata记录的信息，磁盘中有一份，内容中也会有一份。（block位置信息不会保存在磁盘中）

如果启动后进行了新添加文件的操作，那么这个操作就会记录到edits日志文件中，并不会马上修改fsimage文件，后期会进行合并操作。

NameNode工作的数据都在内存上

1.6.2 SecondaryNameNode(SNN)

它不是NN的备份（但可以做备份），它的主要工作是帮助NN合并edits log,减少NN启动时间
SNN执行合并时机
根据配置文件设置的时间间隔fs.checkpoint.period 默认是3600秒
根据配置文件设置edits log大小 fs.checkpoint.size规定edits文件的最大值，默认是64mb

合并会有大量的IO操作，如果合并操作由NameNode自己做的话，那么计算机将会分配大量的内存空间给NameNode来做合并，会影响用户的使用，NameNode主要是用来接收用户的请求操作的，合并由SecondaryNameNode来做的话，可保证NameNode工作的专一性，提供性能。

SecondaryNameNode合并后会生成一个新的fsimage,会将该文件传送给NameNode,替换原来的fsimage

合并流程:

fsimage: 磁盘中的元数据文件

edits: 日志记录文件

在将 edits、fsimage拷贝到SecondaryNameNode的同时，NameNode会新建一个edits文件，来记录用户的操作，edits文件为上次合并的时候产生的新的edits 文件。

在SecondaryNameNode将edits 和 fsimage合并成一个新的fsimage文件，合并之后，将fsimage推送给NameNode, NameNode将之前的fsimage替换掉

不是热备，如果NameNode挂掉，那么将会损失edits.new中的文件操作。

1.6.3 DataNode(DN)

存储数据（block）
启动DN线程的时候会向NN汇报block信息
通过向NN发送心跳保持与其联系（3秒一次），如果NN10分钟没有收到DN的心跳，则认为其已经lost，并copy其上的block到其它DN

1.6.3.1 Block的副本放置策略

第一个副本：放置在上传文件的DN

如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点

第二个副本：放置在于第一个副本不同的机架的节点上
第三个副本：与第二个副本相同机架的节点。
更多副本：随机节点。

机架：在节点的配置文件中会标明属于哪个机架。

1.7 HDFS读流程

在客户端调用api请求NameNode,NameNode返回给数据块的位置信息

客户端拿到数据块的位置信息后，通过另一个API并发的去读各个block，拿到block之后合并为一个文件。（一般是读小的文件）

1.8 HDFS写流程

1.客户端调用 Distributed FileSystem API ，参数包括文件信息，文件的拥有者2.NameNode拿到文件信息后，就可以计算出需要切几个block，block分别存储在哪些DataNode上，返回给客户端

3.客户端获取之后，通过接口FSData CutputStream API 先将一个block写入到DataNode中，其余的副本由DataNode开启新的线程根据副本放置规则，往其它DataNode上进行复制。

4.复制完成后会返回一个回馈信息，然后再将该信息汇报给NameNode

注：DataNode中的副本，是由第一个接收到block的DataNode复制产生的。

1.9 HDFS文件权限

与Linux文件权限类似

r : read
w : write
x : execute,权限x对于文件忽略，对于文件夹表示是否允许访问其内容。

如果Linux系统用户zhangsan使用hadoop命令创建一个文件，那么这个文件在HDFS 中 owner 就是zhangsan
HDFS的权限目的：阻止好人做错事，而不是阻止坏人做坏事。HDFS相信，你告诉我你是谁，我就认为你是谁。

注：现在好像加密码认证了。

1.10 安全模式

NameNode启动的时候，首先将映射文件（fsimage）载入内存，并执行编辑日志（edits）中的各项操作
一旦在内存中成功建立文件系统元数据的映射，则创建一个新的fsimage文件（这个操作不需要SecondaryNameNode）和一个空的编辑日志
此刻NameNode运行在安全模式。即NameNode的文件系统对于客户端来说是只读的。（显示目录，显示文件内容等。写、删除、重命名都会失败）
在此阶段NameNode收集各个DataNode的报告，当数据块达到最小副本数以上时，会被认为是安全的，在一定比例（可设置）的数据块被确定为安全后，再过若干时间，安全模式结束。
当检测到副本数不足的数据块时，该快会被复制知道达到最小副本数，系统中数据块的位置并不是由NameNode维护的，而是以块列表形式存储在DataNode中。

在刚启动HDFS的时候，会先进入一个安全模式，此模式下只可进行读操作。

HDFS简介

1.HDFS介绍

1.1.HDFS结构

1.2 HDFS运行机制

1.3.HDFS优点

1.4 HDFS缺点