HDFS简介
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优点
- 高容错性
- 数据自动保存多个副本
- 副本丢失后，自动恢复
- 适合批处理
- 移动计算而非数据
- 数据位置暴露给计算框架
- 适合大数据处理
- GB\TB甚至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的时候，会先进入一个安全模式，此模式下只可进行读操作。
