HDFS 的深入了解,深入浅出,面试必备(Hadoop的三部曲——上)

1. HDFS 介绍

HDFS(Hadoop Distribute File System)意为:Hadoop 分布式文件系统
分布式文件系统解决的问题就是大数据存储。它们是横跨在多台计算机上的存储系统。

2. HDFS 重要特性

2.1 主从架构(master/slave 架构)

HDFS采用master/slave架构。一般一个HDFS集群是有一个Namenode和一定数目的Datanode组成。Namenode是HDFS主节点(也叫名称节点),Datanode是HDFS从节点(也叫数据节点),两种角色各司其职,共同协调完成分布式的文件存储服务。

2.2 分块存储

HDFS中的文件在物理上是分块存储(block)的,数据块是磁盘进行数据读写的最小单位,一般是512byte的整数倍,
块的大小可以通过配置参数来规定,参数位于hdfs-default.xml中:dfs.blocksize。默认大小是128M
在这里插入图片描述

2.3 命名空间(namespace)

HDFS支持传统的层次型文件组织结构。用户可以创建目录,然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似:用户可以创建、删除、移动或重命名文件。
Namenode负责维护文件系统的namespace名称空间,任何对文件系统名称空间或属性的修改都将被Namenode记录下来。
HDFS会给客户端提供一个统一的抽象目录树,客户端通过路径来访问文件,形如:hdfs://namenode:port/data/text/A.txt。

2.4 Namenode元数据管理

在HDFS中,NameNode 负责维护整个文件系统元数据,NameNode管理的元数据具有两种类型:

  1. 文件自身属性信息
    文件名称、权限,修改时间,文件大小,复制因子,数据块大小。
  2. 文件块位置映射信息
    记录文件块和DataNode之间的映射信息,即哪个块位于哪个节点上。

2.5 Datanode 数据存储

文件的各个block的具体存储管理由DataNode节点承担。每一个block都可以在多个DataNode上存储。Datanode 需要定时向 Namenode 汇报自己持有的 block 信息。

2.6 副本机制!

为了容错,文件的所有block都会有副本。每个文件的block大小(dfs.blocksize)和副本系数(dfs.replication)都是可配置的。副本系数可以在文件创建的时候指定,也可以在之后通过命令改变。默认dfs.replication的值是3,也就是会额外再复制2份,连同本身总共3份副本。
在这里插入图片描述
三副本放置策略(BlockPlacementPolicyDefault)
写请求方所在机器是其中一个Datanode,则第一份副本直接存放在本地,否则随机在集群中选择一个Datanode,第二个副本存放于不同第一个副本的所在的机架,第三个副本存放于第二个副本所在的机架,但是属于不同的节点。
其余的副本在遵循以下限制的前提下随机放置,一个节点最多放置一个副本,如果副本数少于两倍机架数,同一机架不能放置超过两个副本。

在这里插入图片描述

2.7 一次写入,多次读出

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

正因为如此,HDFS适合用来做大数据分析的底层存储服务,并不适合用来做网盘等应用。因为,修改不方便,延迟大,网络开销大,成本太高。

2.8 负载均衡机制

将存储占比大的Datanode节点上的数据移动到存储占比小的Datanode节点上,从而使每一个Datanode存储的数据占比相当。
Namenode会定期检查集群的负载,如果发现集群中Datanode节点的负载不平衡,则自动启动负载均衡。
手动平衡:表示节点最大占用率与节点的最小的占用率之间的差值当超过10%时(不会立刻进行负载均衡,而在集群不忙的时候进行)start-balancer.sh -t 10%

2.9 HDFS心跳机制

Datenode以固定周期向Namenode发送心跳,如果在一段时间内Namenode没有收到心跳,就会标记Datenode为宕机。
Datanode每隔3秒就会向Namenode发送心跳,携带状态信息。
一旦超过timeout时间还没有感知到Datanode,则Namenode认为该Datanode节点不可用。

计算公式:
在这里插入图片描述

3. HDFS 命令操作

3.1 hadoop的shell操作介绍

hdfs dfs、 hadoop fs 二者区别
hdfs dfs 只能操作HDFS文件系统相关(包括与Local FS间的操作),常用
hadoop fs 可操作任意文件系统,不仅仅是hdfs文件系统,使用范围更广

在HDFS Shell 中支持操作多种文件系统,包括本地文件系统(file:///)、分布式文件系统(hdfs://namenode:8020)等,操作的是什么文件系统取决于URL中的前缀协议。如果没有指定前缀,则将会读取环境变量中的fs.defaultFS属性,以该属性值作为默认文件系统。
在这里插入图片描述

3.2 hdfs的常见shell命令

在这里插入图片描述

3.3 hdfs的常见shell命令

3.3.1 创建目录(mkdir)

在这里插入图片描述

3.3.2 查看HDFS中的目录(ls)

在这里插入图片描述

3.3.3 上传文件(put & moveFromLocal)

在这里插入图片描述
在这里插入图片描述

3.3.4 查看文件(cat & head & tail)

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

3.3.5 下载文件(get)

在这里插入图片描述
在这里插入图片描述

3.3.6 拷贝文件(cp)

在这里插入图片描述

3.3.7 追加数据到文件(appendToFile)

在这里插入图片描述

3.3.8 查看使用空间(df & du)

在这里插入图片描述

3.3.9 移动文件(mv)

在这里插入图片描述

3.3.10 修改文件副本数(setrep)

在这里插入图片描述

3.4 更多命令

想了解全部命令,可以查询官网。 官网链接

4. HDFS 基本原理

4.1 NameNode 概述

NameNode 也称为 Master,存储 HDFS 的元数据,它不存储实际数据,数据本身实际存储在 DataNodes 中。NameNode 知道 HDFS 中任何给定文件的块列表及其位置。NameNode 并不持久化存储每个文件中各个所在的 DataNode 的位置信息,这些信息会在系统启动时从数据节点重建。NameNode 对于 HDFS 至关重要,当 NameNode 关闭时,HDFS / Hadoop 集群无法访问。

4.2 DataNode 概述

DataNode 也称为 Slave,负责存储实际数据到 HDFS 中。DataNode 和 NameNode 会一直保持通信(心跳机制)。DataNode 启动时,它将自己发布到 NameNode 并汇报自己负责持有的块列表。当某个 DataNode 宕机不影响数据或群集的可用性,NameNode 将安排由其他 DataNode 管理的块进行副本复制

4.3 HDFS的工作机制(重要)

NameNode 负责管理整个文件系统元数据;DataNode 负责管理具体文件数据块存储;Secondary NameNode 协助 NameNode 进行元数据的备份。
HDFS 的内部工作机制对客户端保持透明,客户端请求访问 HDFS 都是通过向NameNode 申请来进行。

HDFS 写流程!

请添加图片描述

ACK的3种情况
ack=0客户端发送到DataNode,不管DataNode是否收到数据,继续发送下一个packet。数据不安全,效率高。
ack=1客户端发送到DataNode,只管第一个DataNode是否收到数据,第一个DataNode返回给客户端一个ack告知成功写入,客户端就开始发送下一个packet。只能保证第一个DataNode的副本是完整的,至于其他的DataNode不关心。(如果没有配置ack机制,则默认为1)
ack=-1客户端发送到DataNode,只有DataNode都返回给客户端一个ack告知成功写入后,客户端才会发送下一个packet。数据都是完整的,安全性高,效率最低。
HDFS 读流程!

在这里插入图片描述

在第二步中,返回的DN地址,会按照集群拓扑结构得出DataNode与客户端的距离进行排序。

排序规则:
1.网络拓扑结构中距离client近的排靠前
2.心跳机制中超时汇报的DN状态为stale,这样的排靠后

5. HDFS 其他功能

5.1 集群数据拷贝

#  集群内部文件拷贝 scp ( scp -r 当前文件 目标目录 )
scp -r jdk-8u141-linux-x64.tar.gz root@node2:/export/

#  跨集群之间的数据拷贝 distcp ( distcp -r 当前文件 目标目录 )
distcp hdfs://node1:8020/jdk-8u141-linux-x64.tar.gz  hdfs://cluster2:9000/

5.2 Archive 处理小文件

5.2.1 Archive 介绍

HDFS 并不擅长存储小文件,因为每个文件最少一个 block,每个 block 的元数据都会在 NameNode 占用内存,如果存在大量的小文件,它们会吃掉 NameNode 节点的大量内存。
Hadoop Archives 可以有效的处理以上问题,它可以把多个文件归档成为一个文件,归档成一个文件后还可以透明的访问每一个文件。

5.2.2 创建 Archive

在这里插入图片描述

准备例子:

在这里插入图片描述
在这里插入图片描述

5.2.3 查看 Archive

在这里插入图片描述
part 文件是原来的多个文件的集合,1~9.txt共九个小文件归档到zimo.har的part-0一个文件里。

在这里插入图片描述
在这里插入图片描述

5.2.4 解压 Archive

在这里插入图片描述
在这里插入图片描述

5.2.5 Archive 特点
  1. Hadoop archives 是特殊的档案格式,一个 Hadoop archive 对应一个文件系统目录,其扩展名为*.har
  2. 创建 archives 本质是运行一个 Map/Reduce 任务,所以应该在 Hadoop集群上运行创建档案的命令
  3. 创建 archive 时,源文件不会被更改或删除,同时要消耗和原文件一样多的硬盘空间
  4. archive 文件不支持压缩,且一旦创建就无法改变,要修改的话,需要创建新的archive 文件

5.3 HDFS的垃圾桶机制

每一个文件系统都会有垃圾桶机制,便于将删除的数据回收到垃圾桶里面去,避免某些误操作删除一些重要文件。回收到垃圾桶里里面的资料数据,都可以进行恢复。
默认情况下,该机制未开启,在删除文件的时候,就是彻底删除数据

开启垃圾桶机制
在这里插入图片描述
其中,1440 表示 1440分钟,也就是 24小时

<property>
    <name>fs.trash.interval</name>
    <value>1440</value>
</property>

启用垃圾箱配置,dfs命令删除的文件不会立即从HDFS中删除。相反,HDFS将其移动到垃圾目录(每个用户在/user//.Trash下都有自己的垃圾目录)。只要文件保留在垃圾箱中,文件可以快速恢复。

注意在hadoop的web-ui上删除的文件是不会发送到垃圾桶的,而是从HDFS中完全删除。

命令hdfs dfs -expunge 清空回收站

6. HDFS 元数据管理机制

6.1 fsimage 镜像文件

fsimage 文件是 Hadoop 文件系统元数据的一个永久性的检查点,包含 Hadoop 文件系统中的所有目录和文件元数据信息,但不包含文件块位置的信息文件块位置信息只存储在内存中,是在 datanode 加入集群的时候,namenode 询问 datanode 得到的,并且间断的更新。
包含的信息有修改时间、访问时间、块大小和组成一个文件块信息等;而对于目录来说,包含的信息主要有修改时间、访问控制权限等信息。

6.2 edits 编辑日志

edits 文件存放的是 Hadoop 文件系统的所有更改操作(文件创建,删除或修改)的日志,客户端执行的更改操作首先会被记录到 edits 文件中。
如果一个文件比较大,使得写操作需要向多台机器进行操作,只有当所有的写操作都执行完成之后,写操作才会返回成功,这样的好处是任何的操作都不会因为机器的故障而导致元数据的不同步。

6.3 元数据查看

在这里插入图片描述
在这里插入图片描述

7. Secondary NameNode

SecondaryNameNode 的职责是合并 NameNode 的 edit logs 到 fsimage 文件中。作用是减小edit logs文件的大小和得到一个最新的fsimage文件

7.1 CheckPoint

每达到触发条件,会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地,并加载到内存进行merge(这个过程称为checkpoint)。
在这里插入图片描述

  1. NameNode 管理着元数据信息,其中有两类持久化元数据文件:edits和fsimage 文件。新的操作日志不会立即与 fsimage 进行合并,也不会刷到NameNode 的内存中,而是会先写到 edits 中(因为合并需要消耗大量的资源),操作成功之后更新至内存
  2. 有 dfs.namenode.checkpoint.period 和 dfs.namenode.checkpoint.txns 两个配置,只要达到这两个条件任何一个,SecondaryNameNode就会执行 checkpoint 的操作
  3. 当触发 checkpoint 操作时,NameNode 会生成一个新的 edits 即上图中的 edits.new 文件,同时 SecondaryNameNode 会将 edits 文件和 fsimage 复制到本地(http get 方式)
  4. SecondaryNameNode将下载下来的 fsimage 载入到内存,然后一条一条地执行 edits 文件中的各项更新操作,使得内存中的 fsimage 保存最新,这个过程就是 edits 和 fsimage文件合并,生成一个新的 fsimage 文件即上图中的 Fsimage.ckpt 文件。
  5. SecondaryNameNode将新生成的 fsimage.ckpt 文件复制到 NameNode 节点。
  6. 在 NameNode 节点的 edits.new 文件和 fsimage.ckpt 文件会替换掉原来的 edits 文件和 fsimage 文件,至此刚好是一个轮回,即在 NameNode 中又是 edits 和 fsimage 文件。
  7. 等待下一次 checkpoint 触发

7.2 Checkpoint 触发条件

SecondaryNamenode本质不是 Namenode的一个热备 (热备是指与目标设备共同运转,当目标设备发生故障或停机时,热备设备立即承担起故障设备的工作任务)
SecondaryNamenode只是将fsimage和edits合并,它拥有的fsimage不是最新的,因为在他从NameNode下载fsimage和edits文件时候,新的更新操作已经写到NameNode的edit.new文件中去了。而这些更新在SecondaryNamenode是没有同步到的!当然,如果NameNode中的fsimage真的出问题了,还是可以用SecondaryNamenode中的fsimage替换一下NameNode上的fsimage,虽然已经不是最新的fsimage,但是我们可以将损失减小到最少!
在这里插入图片描述

8. HDFS 安全模式

安全模式是 HDFS 所处的一种特殊状态,在这种状态下,文件系统只接受 数据请求,而不接受删除、修改等变更请求,是一种保护机制,用于保证集群中的数据块的安全性。
在 NameNode 主节点启动时,HDFS 首先进入安全模式,集群会开始检查数据块的完整性DataNode 在启动的时候会向 namenode 汇报可用的 block 信息,当整个系统达到安全标准时,HDFS 自动离开安全模式。

安全标准: 假设我们设置的副本数(即参数 dfs.replication)是 5,那么在 Datanode 上就应该有5 个副本存在,假设只存在 3 个副本,那么比例就是 3/5=0.6。在配置文件 hdfs-default.xml中定义了一个最小的副本的副本率(即参数 dfs.namenode.safemode.threshold-pct)0.999。我们的副本率 0.6 明显小于 0.99,因此系统会自动的复制副本到其他的 DataNode,使得副本率不小于 0.999.如果系统中有 8 个副本,超过我们设定的 5 个副本,那么系统也会删除多余的 3 个副本。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值