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的时候，会先进入一个安全模式，此模式下只可进行读操作。

HDFS简介

原文：http://www.cnblogs.com/EnzoDin/p/7203487.html