Hadoop总结——HDFS

一、HDFS概述

1.1 HDFS产生背景

随着数据量越来越大，在一个操作系统管辖的范围内存不下了，那么就分配到更多的操作系统管理的磁盘中，但是不方便管理和维护，迫切需要一种系统来管理多台机器上的文件，这就是分布式文件管理系统。HDFS只是分布式文件管理系统中的一种。

1.2 HDFS概念

1）HDFS，它是一个文件系统，用于存储文件，通过目录树来定位文件；其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。

2）HDFS的设计适合一次写入，多次读出的场景，且不支持文件的修改。适合用来做数据分析，并不适合用来做网盘应用。

二、HDFS优缺点

2.1 优点

1、高容错性

• 数据自动保存多个副本。它通过增加副本的形式，提高容错性
• 某一个副本丢失以后，它可以自动恢复

• Block元数据信息+心跳
• 多副本，提供容错机制，副本丢失或宕机自动恢复，默认存三份

2、适合批处理

• 移动计算而非数据
• 数据位置暴露给计算框架（Block偏移量）

3、适合大数据处理

• 数据规模：能够处理数据规模达到 GB、TB、甚至PB级别的数据
• 文件规模：能够处理百万规模以上的文件数量，数量相当之大

4、可构建在廉价机器上，通过多副本机制提高可靠性，提供容错和恢复机制

2.2 缺点

1、不适合低延时数据访问，比如毫秒级的存储数据，是做不到的

2、无法高效的对大量小文件进行存储

• 存储大量小文件的话，它会占用NameNode大量的内存来存储文件、目录和块信息。这样是不可取的，因为NameNode的内存总是有限的
• 小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标

3、并发写入、文件随机修改

• 一个文件只能有一个写，不允许多个线程同时写
• 一个文件只有一个写者，仅支持数据 append（追加），不支持文件的随机修改

• 问：如何使用append实现数据的增删改查 答：追加+标记+删除更改

三、HDFS存储模型：字节

3.1 HDFS存储模型：Block

3.2 分布式关键：Block

1、Block的副本数

• 数据的备份数
• 可以体现计算的并行度：数据本地化计算

2、区别主从副本

• 主从副本：副本数=主副本+从副本
• HDFS的副本不是主从副本，3个副本都是一样的地位

3、Block是按字节切分存储

3.3 存储模型：字节

• 文件线性切割成块（Block）：偏移量offset（byte）
• Block分散存储在集群节点中
• 单一文件Block大小一致，文件与文件可以不一致
• Block可以设置副本数，副本分散在不同节点

• 副本数不要超过节点数

• 文件上传可以设置Block大小和副本数
• 已上传的文件Block副本数可以调整，大小不变
• 只支持一次写入多次读取，同一时间只有一个写入者
• 可以append追加数据

四、HDFS架构

4.1 Hadoop 1.x HDFS架构：未做高可用时

1、Master/Slave架构

HDFS-1.0架构

2、存在的问题

1）HDFS存在的问题

• NameNode单点故障，难以应用于在线场景
• NameNode压力过大，且内存受限，影响系统扩展性

2）MapReduce存在的问题

• JobTracker访问压力过大，影响系统扩展性
• 难以支持除MapReduce之外的计算框架，比如Spark等

4.2 Hadoop 2.x HDFS架构：高可用

架构解析：

1、主备NameNode

1）解决单点故障

• 主NameNode对外提供服务，备NameNode同步主NameNode元数据，以待切换
• 所有DataNode同时向两个NameNode汇报数据块信息

2）两种切换选择

• 手动切换

• 通过命令实现主备之间的切换，可以用HDFS升级等场合

• 自动切换：基于Zookeeper实现

• Zookeeper Failover Controller：监控NameNode健康状态
• 向Zookeepe注册NameNode
• NameNode挂掉后，ZKFC为NameNode竞争锁，获得ZKFC锁的NameNode变为Active

2、JN

3、ZKFC

4.3 架构组件

1、Client：客户端

• 文件切分。文件上传 HDFS 的时候，Client 将文件切分成一个一个的Block，然后进行存储
• 与NameNode交互，获取文件的位置信息
• 与DataNode交互，读取或者写入数据
• Client提供一些命令来管理HDFS，比如NameNode格式化
• Client可以通过一些命令来访问HDFS，比如对HDFS增删查改操作

2、NameNode

1）Master节点：主管，管理者

• 管理HDFS的名称空间
• 配置副本策略
• 管理数据块（Block）映射信息
• 处理客户端的读写请求

2）NameNode有一个虚拟的文件系统，类似Linux的根目录

3、DataNode

1）Slave节点

• 存储实际的数据块
• 执行数据块的读/写操作

2）NameNode下达命令，DataNode执行实际的操作

4、SecondaryNameNode

1）SecondaryNameNode是NameNode的冷备份

• 合并FsImage和Edits并发回给NameNode

• FsImage：元数据镜像文件（文件系统的目录树）
• Edits：元数据操作日志（针对文件系统做的修改操作记录）

2）SecondaryNameNode的合并流程解析

合并图解

合并流程

• NameNode将元数据镜像文件FsImage落成磁盘文件，新的操作日志会写入到Edits文件中， 当达到Checkpoint出发的条件时，SecondaryNameNode开始工作
• 当触发一个Checkpoint操作时，NameNode会生成一个新的Edits，即图中的edits.new文件， 同时SecondaryNameNode会将edits（日志滚动前的edits）和fsimage复制到本地
• SecondaryNameNode加载编辑日志和镜像文件到内存，并合并成Fsimage.ckpt
• 拷贝fsimage.ckpt到NameNode，NameNode将fsimage.ckpt重新命名成fsimage
• 等待下一次Checkpoint触发SecondaryNameNode进行工作，一直这样循环操作

小结

生成新的edits文件->复制fsimage和edits文件到SecondaryNameNode ->将编辑日志和镜像文件合并成Fsimage.ckpt->拷贝fsimage.ckpt到NameNode，重新命名为fsimage ->达到触发条件SecondaryNameNode再次开始运行

Checkpoint触发条件

• fs.checkpoint.period：指定连续两次检查点的最大时间间隔，默认1h
• fs.checkpoint.size：默认128M，edit日志文件大于这个值则强制触发
• 配置文件：core-site.xml

3）辅助NameNode，分担其工作量，比如定期合并Fsimage和Edits，并推送给NameNode

4）在紧急情况下，可辅助恢复NameNode

5）SecondaryNameNode是Hadoop 1.x中HDFS HA的一个解决方案

6）冷备份和热备份的区别

• 热备份能随时顶替挂掉的节点工作
• 冷备份在节点挂掉后，只是节点挂掉之前的部分元数据

4.4 HDSF 1.x与HDFS 2.x的区别

五、HDFS工作原理

5.1 简易版本

1、HDFS写数据流程

1）客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。

2）NameNode返回是否可以上传。

3）客户端请求第一个 block上传到哪几个datanode服务器上。

4）NameNode返回3个datanode节点，分别为dn1、dn2、dn3。

5）客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。

6）dn1、dn2、dn3逐级应答客户端。

7）客户端开始往dn1上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位，dn1收到一个packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。

8）当一个block传输完成之后，客户端再次请求NameNode上传第二个block的服务器。（重复执行3-7步）。

2、HDFS读数据流程

1）客户端通过Distributed FileSystem向NameNode请求下载文件，NameNode通过查询元数据，找到文件块所在的DataNode地址。

2）挑选一台DataNode（就近原则，然后随机）服务器，请求读取数据。

3）DataNode开始传输数据给客户端（从磁盘里面读取数据输入流，以packet为单位来做校验）。

4）客户端以packet为单位接收，先在本地缓存，然后写入目标文件。

5.2 详细版本

1、HDFS写数据流程

1）Client将FileA按128M分块。分成两块，block1和Block2;

2）Client向nameNode发送写数据请求，如图蓝色虚线①------>。

3）NameNode节点，记录block信息。并返回可用的DataNode，如粉色虚线②------->。

• Block1: host2,host1,host6 Block2: host7,host3,host4

4）client向DataNode发送block1；发送过程是以流式写入。

流式写入过程

（1）将64M的block1按64k的package划分;

（2）然后将第一个package发送给host2;

（3）host2接收完后，将第一个package发送给host1，同时client向host2发送第二个package；

（4）host1接收完第一个package后，发送给host6，同时接收host2发来的第二个package。

（5）以此类推，如图红线实线所示，直到将block1发送完毕。

（6）host2，host1，host6向NameNode，host2向Client发送通知，说“消息发送完了”。如图粉红颜色实线所示。

（7）client收到host2发来的消息后，向namenode发送消息，说我写完了。这样就完成了。如图黄色粗实线。

（8）发送完block1后，再向host7，host3，host4发送block2，如图蓝色实线所示。

（9）发送完block2后，host7，host3，host4向NameNode，host7向Client发送通知，如图浅绿色实线所示。

（10）client向NameNode发送消息，说我写完了，如图黄色粗实线。。。这样就完毕了。

2、HDFS读数据流程

1）client向namenode发送读请求。

2）namenode查看Metadata信息，返回fileA的block的位置。

• block1：host2，host1，host6 block2：host7，host3，host4

3）block的位置是有先后顺序的，先读block1，再读block2。而且block1去host2上读取；然后block2，去host7上读取。

5.3 HDFS副本存放机制

1、配备了机架感知

Hadoop的副本放置策略在可靠性（副本在不同机架）和带宽（只需跨越一个机架）中做了一个很好的平衡

Hadoop3.x副本结点选择：

由上图可知，第一个副本在Client所处的节点上。如果客户端在集群外，随机选一个。

第二个副本在另一个机架的随机一个节点。

第三个副本在第二个副本所在机架的随机节点。

更多副本：随机节点

2、未配备机架感知

三个DataNode机器的选择完全是随机的

5.4 HDFS的机架感知技术

1、确定节点所在的机架？

原理如下：

• 当DataNode注册时和heartbeat时，会把DataNode的IP作为参数传入，返回信息为此DataNode的机架信息。
• 如果没有参数配置，DataNode统一为默认的机架/default-rack

2、默认关闭

3、hadoop-site.xml配置：topology.script.file.name

配置选项的value指定为一个可执行脚本程序

• 脚本的编写需要充分了解真实的网络拓扑和机架信息

通过该脚本能够将机器的IP地址正确的映射到相应的机架上去

5.5 HDFS安全模式

namenode启动的时候，首先将映像文件(fsimage)或入内存，并执行编相日志(edits)中的各项操作。

一旦在内存中成功建立文件系统元数据的映时，则创建一个新的fsimage文件(这个操作不需要SecondaryNameNode)和一个空的编辑日志。

此刻namenode运行在安全模式，即namenode的文件系统对于客服端来说是只读的。(显示目录，显示文件内容等。写、制除、重命名都会失败)

在此阶段Nameode收集各个datanode的报告，当数据块达到最小副本数以上时，会被认为是“安全”的，在一定比例(可设置)的故据块被确定为“安全”后，再过若干时间，安全模式结束

当检测到副本故不足的故据块时，该块会被复制直到达到最小副本故，系统中数据块的位置并不是由nanenode维护的，而是以块列表形式存铑在datanode中。