HDFS学习笔记

HDFS：Hadoop Distributed File System Hadoop 分布式文件系统

 

将大文件，大批量文件，分布式的存放于大量服务器上。以便于采取分而治

之的方式对海量数据进行运算分析；

 

HDFS  设计思路：

1.大文件被切割成小文件，使用分而治之的思想让很多服务器对同一个文件进行联合管理

2.每个小文件做冗余备份，并且分散存到不同的服务器，做到高可靠不丢失

 

HDFS  架构：

主节点 Namenode：集群老大，掌管文件系统目录树，处理客户端读且请求

SecondaryNamenode：严格 说并不是 namenode  备份节点，主要给 namenode  分担压力之用

从节点 Datanode ：存储整个集群所有数据块，处理真正数据读写

 

重要特性如下：

1、HDFS 中的文件在物理上是分块存储（block），块的大小可以通过配置参数(dfs.blocksize)

来规定，默认大小在 hadoop2.x 版本中是 128M，老版本中是 64M

2、HDFS 文件系统会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件，形

如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data

hdfs://hadoop02:9000/soft/hadoop-2.6.5-centos-6.7.tar.gz

3、目录结构及文件分块位置信息(元数据)的管理由 namenode 节点承担

namenode 是 HDFS 集群主节点，负责维护整个 hdfs 文件系统的目录树，以及每一个路径（文

件）所对应的 block 块信息（block 的 id，及所在的 datanode 服务器）

4、文件的各个 block 的存储管理由 datanode 节点承担

datanode 是 HDFS 集群从节点，每一个 block 都可以在多个 datanode 上存储多个副本（副本

数量也可以通过参数设置 dfs.replication，默认是 3）

1. HDFS 是设计成适应一次写入，多次读出的场景，且不支持文件的修改

 

HDFS的优点：

可构建在廉价机器上

通过多副本提高可靠性，提供了容错和恢复机制

高容错性

数据自动保存多个副本，副本丢失后，自动恢复

适合批处理

移动计算而非数据，数据位置暴露给计算框架

适合大数据处理

GB、TB、甚至 PB 级数据，百万规模以上的文件数量，10K+节点规模

流式文件访问

一次性写入，多次读取，保证数据一致性

 

HDFS缺点：

不适于以下操作：

低延迟数据访问

比如毫秒级

低延迟与高吞吐率

小文件存取

占用 NameNode 大量内存 150b* 1000W = 15E,1.5G

寻道时间超过读取时间

并发写入、文件随机修改

一个文件只能有一个写者

仅支持 append

 

JAVA API:

Hadoop心跳机制：

Hadoop 是 Master/Slave 结构，Master 中有 NameNode 和 ResourceManager，Slave 中有

Datanode 和 NodeManager，NameNode 通过心跳得知 Datanode 的状态

ResourceManager 通过心跳得知 NodeManager 的状态

 

Namenode  感知到 Datanode  掉线死亡的时长计算：

HDFS 默认的超时时间为 10 分钟+30 秒。

这里暂且定义超时时间为 timeout

计算公式为：

timeout = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval

而默认的 heartbeat.recheck.interval 大小为 5 分钟，dfs.heartbeat.interval 默认的大小为 3 秒。

需要注意的是 hdfs-site.xml 配置文件中的 heartbeat.recheck.interval 的单位为毫秒，

dfs.heartbeat.interval 的单位为秒

 

HDFS  安全模式：

namenode 发现集群中的 block 丢失率达到一定比例时（0.1%），namenode 就会进入

安全模式，在安全模式下，客户端不能对任何数据进行操作，只能查看元数据信息（比

Stay hungry Stay foolish -- http://blog.csdn.net/zhongqi2513

如 ls/mkdir）

 

正常启动的时候进入安全的原理：

(原理：namenode 的内存元数据中，包含文件路径、副本数、blockid，及每一个 block 所在datanode 的信息，而 fsimage 中，不包含 block 所在的 datanode 信息，那么，当 namenode冷启动时，此时内存中的元数据只能从 fsimage 中加载而来，从而就没有 block 所在的datanode 信息——>就会导致 namenode 认为所有的 block 都已经丢失——>进入安全模式——>datanode 启动后，会定期向 namenode 汇报自身所持有的 blockid 信息，——>随着datanode 陆续启动，从而陆续汇报 block 信息，namenode 就会将内存元数据中的 block 所在 datanode 信息补全更新——>找到了所有 block 的位置，从而自动退出安全模式)

 

HDFS  副本存放策略：

将每个文件的数据进行分块存储，每一个数据块又保存有多个副本，这些数据块副本分

布在不同的机器节点上。

在多数情况下，HDFS 默认的副本系数是 3，第一个block副本放在和client所在的node里（如果client不在集群范围内，则这第一个node是随机选取的，系统会尝试不选择哪些太满或者太忙的 node）。

第二个副本放置在与第一个节点不同的机架中的 node 中（近乎随机选择，系统会尝试不选择哪些太满或者太忙的 node）。第三个副本和第二个在同一个机架，随机放在不同的 node 中。

 

修改副本数：

第一种方式：修改集群文件 hdfs-site.xml

<property>

<name>dfs.replication</name>

<value>1</value>

</property>

第二种方式：命令设置

bin/hadoop fs -setrep -R 1 /

 

负载均衡：

机器与机器之间磁盘利用率不平衡是 HDFS 集群非常容易出现的情况

尤其是在 DataNode 节点出现故障或在现有的集群上增添新的 DataNode 的时候分析数据块分布和重新均衡 DataNode 上的数据分布的工具，自动进行均衡非常慢，一天能移动的数据量在 10G-10T 的级别，很难满足超大集群的需求原因：HDFS 集群默认不允许 balance 操作占用很大的网络带宽，这个带宽是可以调整的

 

NAMENODE和DATANODE:

1、负责客户端请求（读写数据请求）的响应

2、维护目录树结构（元数据的管理：查询，修改）

3、配置和应用副本存放策略

4、管理集群数据块负载均衡问题

datanode 负责管理用户的文件数据块，并且通过心跳机制汇报给 namenode

datanode 会定期向 namenode 汇报自身所保存的文件 block 信息，而 namenode 则会负责保持文件的副本数量

 

HDFS 的内部工作机制对客户端保持透明，客户端请求访问 HDFS 都是通过向 namenode

申请来进行

 

HDFS  写数据流程：

1、 client 发写数据请求

2、 namenode 响应请求，然后做一系列校验，如果能上传该数据，则返回该文件的所有切

块应该被存在哪些 datanode 上的 datanodes 列表:

blk-001:hadoop02 hadoop03

blk-002:hadoop03 hadoop04

3、 client 拿到 datanode 列表之后，开始传数据

4、 首先传第一块 blk-001，datanode 列表就是 hadoop02,hadoop03, client 就把 blk-001 传到hadoop02 和 hadoop03 上

5、 ……… 用传第一个数据块同样的方式传其他的数据块

6、 当所有的数据块都传完之后，client 会给 namenode 返回一个状态信息，表示数据已全部写入成功，或者是失败的信息

7、 namenode 接收到 client 返回的状态信息来判断当次写入数据的请求是否成功，如果成功，就需要更新元数据信息

 

namenode做的检查操作：

1. 对client的请求进行合理性检查（是否上传的文件已存在等）
2. Client的权限是否符合

 

详细步骤文字说明

1、使用 HDFS 提供的客户端 Client，向远程的 namenode 发起 RPC 请求

2、namenode 会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会

为文件创建一个记录，否则会让客户端抛出异常；

3、当客户端开始写入文件的时候，客户端会将文件切分成多个 packets，并在内部以数据队列“data queue（数据队列）”的形式管理这些 packets，并向 namenode 申请 blocks，获取用来存储 replicas 的合适的 datanode 列表，列表的大小根据 namenode 中 replication的设定而定；

4、开始以 pipeline（管道）的形式将 packet 写入所有的 replicas 中。客户端把 packet 以流的方式写入第一个 datanode，该 datanode 把该 packet 存储之后，再将其传递给在此 pipeline中的下一个 datanode，直到最后一个 datanode，这种写数据的方式呈流水线的形式。

5、最后一个 datanode 成功存储之后会返回一个 ack packet（确认队列），在 pipeline 里传递至客户端，在客户端的开发库内部维护着"ack queue"，成功收到 datanode 返回的 ack

packet 后会从"data queue"移除相应的 packet。

6、如果传输过程中，有某个 datanode 出现了故障，那么当前的 pipeline 会被关闭，出现故障的 datanode 会从当前的 pipeline 中移除，剩余的 block 会继续剩下的 datanode 中继续以 pipeline 的形式传输，同时 namenode 会分配一个新的 datanode，保持 replicas 设定的数量。

7、客户端完成数据的写入后，会对数据流调用 close()方法，关闭数据流；

8、只要写入了 dfs.replication.min（最小写入成功的副本数）的复本数（默认为 1），写操作就会成功，并且这个块可以在集群中异步复制，直到达到其目标复本数（dfs.replication

的默认值为 3），因为 namenode 已经知道文件由哪些块组成，所以它在返回成功前只需

要等待数据块进行最小量的复制。

 

HDFS  读数据流程：

客户端将要读取的文件路径发送给 namenode，namenode 获取文件的元信息（主要是 block的存放位置信息）返回给客户端，客户端根据返回的信息找到相应 datanode 逐个获取文件的 block 并在客户端本地进行数据追加合并从而获得整个文件。

详细文字说明

1、使用 HDFS 提供的客户端 Client，向远程的 namenode 发起 RPC 请求；

2、namenode 会视情况返回文件的全部 block 列表，对于每个 block，namenode 都会返回有该 block 拷贝的 datanode 地址；

3、客户端Client会选取离客户端最近的datanode来读取block；如果客户端本身就是datanode，那么将从本地直接获取数据；

4、读取完当前 block 的数据后，关闭当前的 datanode 链接，并为读取下一个 block 寻找最佳的 datanode；

5、当读完列表 block 后，且文件读取还没有结束，客户端会继续向 namenode 获取下一批的block 列表；

6、读取完一个 block 都会进行 checksum 验证，如果读取 datanode 时出现错误，客户端会通知 namenode，然后再从下一个拥有该 block 拷贝的 datanode 继续读。

 

NameNode  元数据管理：

NameNode 对数据的管理采用了 两 种存储形式：内存和磁盘

首先是 内存中存储了一份完整的元数据，包括目录树结构，以及文件和数据块和副本存储地的映射关系；

1 、 内存元数据 metadata（全部存在内存中）

其次是在 磁盘中也存储了一份完整的元数据。有三种格式：

2 、 磁盘元数据镜像文件 fsimage_0000000000000000555  fsimage_0000000000000000555

等价于

edits_0000000000000000001-0000000000000000018

……

edits_0000000000000000444-0000000000000000555

合并之和

3 、 数据 历史 操作日志文件 edits ：edits_0000000000000000001-0000000000000000018

（可通过日志运算出元数据，全部存在磁盘中）

4 、数据预写操作日志文件 edits_inprogress_0000000000000000556

（存储在磁盘中）

metadata = 最新 fsimage_0000000000000000555 + edits_inprogress_0000000000000000556

metadata = 所有的 edits 之和（edits_001_002 + …… + edits_444_555 + edits_inprogress_556）

 

核心：

HDFS中的namenode每次在进行元数据的修改相关操作时，都会记录日志到最新的edist_inprogress中。当edist_inprogress超过了某个标准时，就进行滚动生成新的 edist_x_y这种格式的日志文件。当edist_x_y这种格式的日志文件变多时，那么又会被合并成fsimage_xx这种格式的文件。由于fsimage是被序列化了之后的一个镜像文件，所以它是能够被快速加载到内存中的最合理的存储格式。元数据的 CheckPoint每隔一段时间，会由 secondary namenode 将 namenode 上积累的所有 edits 和一个最新的fsimage 下载到本地，并加载到内存进行 merge（这个过程称为 checkpoint）

 

SecondaryNamenode  工作机制

把最新的fsimage文件和最新的edists进行合并，分担 namenode 的合并元数据的压力。所以在配置

SecondaryNamenode 的工作节点时，一定切记，不要和 namenode 处于同一节点。