【HDFS】hdfs知识整理

1. HDFS前言

HDFS:Hadoop Distributed File System Hadoop 分布式文件系统，主要用来解决海量数据的存储问题

• 设计思想
  分而治之:将大文件，大批量文件，分布式的存放于大量服务器上。以便于采取分而治 之的方式对海量数据进行运算分析
• 在大数据系统架构中的应用 为各类分布式运算框架(MapReduce，Spark，Tez，Flink，…)提供数据存储服务
• 重点概念:数据块/副本，负载均衡，心跳机制，副本存放策略，元数据/元数据管理， 安全模式，机架感知…

2. HDFS相关概念和特性

2.1 HDFS设计思路

HDFS 被设计成用来使用低廉的服务器来进行海量数据的存储，那是怎么做到的呢?

• 大文件被切割成小文件，使用分而治之的思想让很多服务器对同一个文件进行联合管理
• 每个小文件做冗余备份，并且分散存到不同的服务器，做到高可靠不丢失
  

HDFS 数据存储单元(block)

• 文件被切分成固定大小的数据块
  基本的读写单位，类似于磁盘的页，每次都是读写一个块
  默认数据块大小为128MB (hadoop2.x)，可配置
  若文件大小不到128MB，则单独存成一个block
  配置大的块主要是因为：
  1）减少搜寻时间，一般硬盘传输速率比寻道时间要快，大的块可以减少寻道时间；
  2）减少管理块的数据开销，每个块都需要在NameNode上有对应的记录；
  3）对数据块进行读写，减少建立网络的连接成本
• 一个文件存储方式
  按大小被切分成若干个block，存储到不同节点上
  默认情况下每个block都有三个副本
• Block大小和副本数通过Client端上传文件时设置，文件上传成功后副本 数可以变更，Block Size不可变更

2.2 HDFS 架构

• 主节点 Namenode:集群老大，掌管文件系统目录树，处理客户端读且请求
• SecondaryNamenode:严格说并不是 namenode 备份节点，主要给 namenode 分担压力之用
• 从节点 Datanode:存储整个集群所有数据块，处理真正数据读写
  

2.2.1 namenode工作机制

namenode职责

• 存储文件的metadata，运行时所有数据都保存到内存，整个HDFS可存储的文件数受限于NameNode的内存大小
• 一个Block在NameNode中对应一条记录（一般一个block占用150字节），如果是大量的小文件，会消耗大量内存。同时map task的数量是由splits来决定的，所以用MapReduce处理大量的小文件时，就会产生过多的map task，线程管理开销将会增加作业时间。处理大量小文件的速度远远小于处理同等大小的大文件的速度。因此Hadoop建议存储大文件
• 数据会定时保存到本地磁盘，但不保存block的位置信息，而是由DataNode注册时上报和运行时维护（NameNode中与DataNode相关的信息并不保存到NameNode的文件系统中，而是NameNode每次重启后，动态重建）
• NameNode失效则整个HDFS都失效了，所以要保证NameNode的可用性

namenode元数据管理
WAL(Write ahead Log): 每做一次操作之前，都会先记录到日志中，然后再做操作，日志会对这次操作做一个成功或者失败的标记，下次执行时，直接从WAL中拿出来执（WAL主要记录 增删改），这里的日志就是edits.log
namenode对元数据的管理，采用了二存储形式：内存和磁盘

• 内存中有一份完整的元数据(内存 metadata)
• 磁盘有一个“准完整”的元数据镜像（ fsimage）文件(在 namenode 的工作目录中)
• 用于衔接内存 metadata 和持久化元数据镜像 fsimage 之间的操作日志（ edits 文件）
  当客户端对 hdfs 中的文件进行增删改操作，操作记录首先被记入 edits 日志 文件中，当客户端操作成功后，相应的元数据会更新到内存 metadata 中 （这就是WAL）

namenode元数据的checkpoint

第一阶段： namenode 启动
1）第一次启动 namenode 格式化后， 创建 fsimage 和 edits 文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
2） 客户端对元数据进行增删改的请求。
3） namenode 记录操作日志，更新滚动日志。
4） namenode 在内存中对数据进行增删改查。

第二阶段： Secondary NameNode 工作
1） Secondary NameNode 询问 namenode 是否需要 checkpoint。 直接带回 namenode 是否检查结果。
2） Secondary NameNode 请求执行 checkpoint。
3） namenode 滚动正在写的 edits 日志。
4）将滚动前的编辑日志和镜像文件拷贝到 Secondary NameNode。
5） Secondary NameNode 加载编辑日志和镜像文件到内存，并合并。
6） 生成新的镜像文件 fsimage.chkpoint。
7） 拷贝 fsimage.chkpoint 到 namenode。
8） namenode 将 fsimage.chkpoint 重新命名成 fsimage。

更多操作

2.2.2 SecondaryNamenode工作机制

• 它不是NN的备份(但可以做备份)，它的主要工作是帮助NN合并edits
  log，减少NN启动时间。
• SNN执行合并时机（任一条件都会触发）
  根据配置文件设置的时间间隔fs.checkpoint.period 默认3600秒即1小时
  两次checkpoint之间edits操作记录是否达到100万条

2.2.3 datanode工作机制

• 存储数据(Block)
• 启动DN线程的时候会向NN汇报block信息
• 通过向NN发送心跳保持与其联系(3秒一次)，如果NN10分钟没有收
  到DN的心跳，则认为其已经lost，并copy其上的block到其它DN
  数据完整性校验参考链接

2.3 概念和特性

首先，它是一个文件系统，用于存储文件，通过统一的命名空间——目录树来定位文件 其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器都有各自清晰的 角色定位
重要特性如下:

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)
5. HDFS 是设计成适应一次写入，多次读出的场景，且不支持文件的修改 (PS:适合用来做数据分析，并不适合用来做网盘应用，因为，不便修改，延迟大，网络开
   销大，成本太高)

3. HDFS优缺点

3.1 HDFS优点

• 可构建在廉价机器上
  通过多副本提高可靠性，提供了容错和恢复机制
• 高容错性
  数据自动保存多个副本，副本丢失后，自动恢复
• 适合批处理
  移动计算而非数据，数据位置暴露给计算框架
• 适合大数据处理
  GB、TB、甚至 PB 级数据，百万规模以上的文件数量，10K+节点规模
• 流式文件访问
  一次性写入，多次读取，保证数据一致性

3.2 HDFS缺点

不适于以下操作：

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

HDFS 不适合存储小文件：

• 元信息存储在 NameNode 内存中
  一个节点的内存是有限的
• 存取大量小文件消耗大量的寻道时间
  类比拷贝大量小文件与拷贝同等大小的一个大文件
• NameNode 存储 block 数目是有限的
  一个 block 元信息消耗大约 150 byte 内存
  存储 1 亿个 block，大约需要 20GB 内存
  如果一个文件大小为 10K，则 1 亿个文件大小仅为 1TB(但要消耗掉 NameNode 20GB
  内存)

4. HDFS 核心设计

4.1 HADOOP心跳机制

• Hadoop 是 Master/Slave 结构，Master 中有 NameNode 和 ResourceManager，Slave 中有 Datanode 和 NodeManager
• Master 启动的时候会启动一个 IPC(Inter-Process Comunication，进程间通信)server 服 务，等待 slave 的链接
• Slave 启动时，会主动链接 master 的 ipc server 服务，并且每隔 3 秒链接一次 master，这 个间隔时间是可以调整的，参数为 dfs.heartbeat.interval，这个每隔一段时间去连接一次 的机制，我们形象的称为心跳。Slave 通过心跳汇报自己的信息给 master，master 也通 过心跳给 slave 下达命令
• NameNode 通过心跳得知 Datanode 的状态 ResourceManager 通过心跳得知 NodeManager 的状态
• 如果 master 长时间都没有收到 slave 的心跳，就认为该 slave 挂掉了。!!!

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 的单位为秒
所以，举个例子，如果 heartbeat.recheck.interval 设置为 5000(毫秒)，dfs.heartbeat.interval 设置为 3(秒，默认)，则总的超时时间为 40 秒

<property> 
	<name>heartbeat.recheck.intervalname>
	<value>5000value>
property> 
<property>
	<name>dfs.heartbeat.intervalname>
	<value>3value> 
property>

4.2 HDFS安全模式

问题引出:集群启动后，可以查看目录，但是上传文件时报错，打开 web 页面可看到 namenode正处于 safemode 状态，怎么处理?
解释:safemode 是 namenode 的一种状态(active/standby/safemode 安全模式)

4.2.1 namenode 进入安全模式的原理

• namenode 发现集群中的 block 丢失率达到一定比例时(0.1%)，namenode 就会进入
  安全模式
  在安全模式下，客户端不能对任何数据进行操作，只能查看元数据信息(比如 ls/mkdir)
  这个丢失率是可以手动配置的，默认是 dfs.safemode.threshold.pct=0.999f
• 如何退出安全模式?
  找到问题所在，进行修复(比如修复宕机的 datanode)
  或者可以手动强行退出安全模式(但是并没有真正解决问题)

在 hdfs 集群正常冷启动时，namenode 也会在 safemode 状态下维持相当长的一段时间，此 时你不需要去理会，等待它自动退出安全模式即可

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

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

4.2.3安全模式常用操作命令

hdfs dfsadmin -safemode leave //强制 NameNode 退出安全模式
hdfs dfsadmin -safemode enter //进入安全模式
hdfs dfsadmin -safemode get //查看安全模式状态
hdfs dfsadmin -safemode wait //等待，一直到安全模式结束

如果你使用的版本是 2.X 之前的版本，那么这个 hdfs 命令可以替换成 hadoop，它们都在 bin 目录下

4.3 HDFS副本存放策略

4.3.1 作用

数据分块存储和副本的存放，是保证可靠性和高性能的关键

4.3.2 方法

将每个文件的数据进行分块存储，每一个数据块又保存有多个副本，这些数据块副本分 布在不同的机器节点上

4.3.3 存放说明

在多数情况下，HDFS 默认的副本系数是 3
Hadoop 默认对 3 个副本的存放策略如下图:其中 Block1，Block2，Block3 分别表示 Block 的三个副本:

• 第一个 block 副本放在和 client 所在的 node 里(如果 client 不在集群范围内，则这第一个 node 是随机选取的，系统会尝试不选择哪些太满或者太忙的 node)。
• 第二个副本放置在与第一个节点不同的机架中的 node 中(近乎随机选择，系统会尝试不选 择哪些太满或者太忙的 node)。
• 第三个副本和第二个在同一个机架，随机放在不同的 node 中。
• 更多副本:随机节点

4.3.3 修改副本数

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

<property> 
	<name>dfs.replicationname> 
	<value>1value>
property>

第二种方式:命令设置

bin/hadoop fs -setrep -R 1 /

4.4 负载均衡

机器与机器之间磁盘利用率不平衡是 HDFS 集群非常容易出现的情况
尤其是在 DataNode 节点出现故障或在现有的集群上增添新的 DataNode 的时候分析数据块 分布和重新均衡 DataNode 上的数据分布的工具
命令:

sbin/start-balancer.sh 
sbin/start-balancer.sh -threshold 5

自动进行均衡非常慢，一天能移动的数据量在 10G-10T 的级别，很难满足超大集群的需求 原因:HDFS 集群默认不允许 balance 操作占用很大的网络带宽，这个带宽是可以调整的

hdfs dfsadmin -setBalanacerBandwidth newbandwidth
hdfs dfsadmin -setBalanacerBandwidth 10485760

该数值的单位是字节，上面的配置是 10M/s，默认是 1M/s 另外，也可以在 hdfs-site.xml 配置文件中进行设置:

<property>
	<name>dfs.balance.bandwidthPerSecname>
	<value>10485760value>
	<description> Specifies the maximum bandwidth that each datanode can utilize for the balancing purpose in term of the number of bytes per second. 	description> 
property>

sbin/start-balancer.sh -t 10%

机器容量最高的那个值 和 最低的那个值得差距 不能超过 10%

5. HDFS 读写流程

5.1 写流程

客户端要向HDFS写数据，首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode，然后，客户端按顺序将文件逐个block传递给相应datanode，并由接收到block的datanode负责向其他datanode复制block的副本

1）跟NN通信请求上传文件，NN检查目标文件是否存在，父目录是否存在

2）NN返回是否可以上传

3）client会先对文件进行切分，比如一个block块128M，文件300M就会被切分成3个块，两个128M，一个44M。请求第一个block该传输到哪些DN服务器上。

4）NN返回DN的服务器。

5）client请求一个台DN上传数据（RPC调用，建立pipeline），第一个DN收到请求会继续调用第二个DN，然后第二个调用第三个DN,将整个pipeline建立完成，逐级返回客户端。

6）client开始传输block(先从磁盘读取数据存储到一个本地内存缓存)，以packet为单位（一个packet为64kb）,写入数据的时候datanode会进行数据校验，并不是通过packet为单位校验，而是以chunk为单位校验（512byte）,第一个DN收到第一个packet就会传给第二台，第二台传给第三台；第一台每传一个packet就会放入一个应答队列等待应答。

7）当一个block传输完成时，client再次请求NN上传第二个block的服务器。

转自

5.2 读流程

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

1）跟NN通信查询元数据(block所在的DN的节点)，找到文件块所在的DN的服务器。

2）挑选一台DN（就近原则，然后随机）服务器，请求建立socket流。

3）DN开始发送数据（从磁盘里读取数据放入流，一packet为单位做校验）

4）客户端以packet为单位接收，现在本地缓存，然后写入目标文件中，后面的block块就相当于append到前面的block块，最后合成最终需要的文件。

---

以上内容来自网络，仅供个人复习。