Hadoop原理-优快云博客

本文详细介绍了HDFS的分布式存储原理，包括其架构、分块存储机制、Namenode和SecondaryNameNode的角色、元数据管理、写和读数据流程，以及安全模式和归档、垃圾桶机制的运用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

HDFS原理--分布式介绍

为什么要用分布式存储? 答案: 分布式存储解决了单机存储容量有限的问题, 且带来了比较高的性能提升. 例如: 3台服务器, 就是3倍的传输效率, 读写效率...

HDFS原理--架构图

述HDFS的架构及各节点的角色?
答案:
namenode: 主节点.
1. 管理整个HDFS集群.
2. 维护和管理元数据.
SecondaryNameNode: 辅助节点.
辅助namenode维护和管理元数据的.
datanode: 从节点.
1. 存储具体的数据.
2. 负责源文件的读写操作.
3. 定时和namenode发送心跳包.

HDFS原理--分块存储

简述你对HDFS的分块存储机制的理解.
答案:
1. 分块存储是为了方便统一管理的, 默认的块大小为: 128MB. 细节: Hadoop2.X开始才是128MB, Hadoop1.X是: 64MB.
2. 副本机制是为了提高容错率, 副本数越多, 容错率越高. 带来的弊端是: 磁盘利用率下降了.
3. 实际开发中, 建议副本数为: 2 ~ 5
4. 如果要修改block块的大小和默认的副本数, 可以去: Hadoop的配置文件中修改.
路径为:
/export/server/hadoop/etc/hadoop/hdfs-site.xml
官方配置文档路径为:
https://hadoop.apache.org/docs/r3.3.0
https://hadoop.apache.org/docs/r3.3.0/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml
参考配置信息如下:


<property>
<name>dfs.replication</name>
<value>3</value>
</property>


<property>
<name>dfs.blocksize</name>
<value>134217728</value>
<description>设置HDFS块大小，单位是b</description>
</property>

HDFS原理--namenode如何管理元数据

namenode是如何维护和管理元数据的?
答案:
1. namenode是通过一批Edits(小) 和 1个FSImage(大)两类文件来维护和管理元数据的.
2. Edits文件相对较小, 操作起来速度相对较快, 它只记录HDFS最近一段状态的元数据信息.
阈值: 1个小时或者 100W次
3. FSImage文件相对较大, 操作起来速度相对较慢, 它记录的是HDFS集群除最近状态外, 其它所有的元数据信息.
4. HDFS集群启动的时候, 会自动加载FSImage文件和最新的Edits文件进内存, 用于记录元数据.
整个过程称为HDFS的自检动作, 此状态下, HDFS集群会强制进入到安全模式, 只能读, 不能写.
5. 我们HDFS集群的Edits文件和FSImage文件存储在: /export/data/hadoop/dfs/name/current

HDFS原理--SecondaryNameNode如何辅助namenode管理元数据

SecondaryNameNode是如何辅助namenode管理元数据的?
1. SecondaryNameNode会间隔60s(秒), 询问一次namenode, edits文件是否满足了阈值(1个小时, 或者100W次)
2. 如果满足条件, 就通知namenode创建新的Edits文件, 继续往里写入元数据信息.
3. 根据http协议, 从namenode上把要合并的edits文件和 fsimage文件拉取到本地进行合并.
4. 将合并后的新的FSImage文件推送给namenode, 用来替换之前旧的FsImage文件.
细节: 旧的FSImage文件并不会被立即删除, 而是达到一定的阈值后, 才会被删除.
5. 对于Edits文件和FSImage文件的合并操作, 是由SecondaryNameNode独立完成的, 全程namenode不参与.
6. 实际开发中, namenode 和 SecondaryNameNode会被部署到不同的服务器上, 配置几乎一致, 只不过SecondaryNameNode的内存要稍大一些.
7. 在紧急情况下, SecondaryNameNode可以用来恢复namenode的元数据.

HDFS原理--三大机制详解

三大机制指的是: 副本机制, 负载均衡, 心跳机制

三个副本是如何存储的?

HDFS的三大机制及副本存储?
三大机制:
副本机制: 默认是3, 可以提高容错率, 但是磁盘的利用率降低.
负载均衡: namenode尽量保证多台datanode资源使用率一致.
心跳机制: 3秒, 630秒, 6个小时.
副本如何存储:
根据副本机制, 负载均衡, 机架感知原理, 网络拓扑图(寻找最近机架)进行计算, 并存储, 结论如下:
第1副本: 优先本机, 否则就近随机.
第2副本: 第1副本所在机架, 就近的某个机架的随机的服务器上.
第3副本: 和第2副本同一机架的不同服务器上.
如果不满足, 则: 随机存储.

HDFS原理--HDFS写数据流程

请简述你对HDFS的写数据流程的理解?
答案:
1. Client(客户端)请求namenode, 上传文件.
2. namenode接收到客户端请求后, 会校验权限, 并告知客户端是否可以上传.
校验: 客户端是否有写的权限, 及文件是否存在.
3. 如果可以上传, 客户端会按照128MB(默认)对文件进行切块.
4. Client(客户端)再次请求namenode, 第1个Block块的上传位置.
5. namenode会根据副本机制, 负载均衡, 机架感知原理及网络拓扑图, 返回给客户端存储该Block块的DataNode列表.
例如: node1, node2, node3
6. Client(客户端)会先连接就近的datanode机器, 然后依次和其他的datanode进行连接, 形成: 传输管道(Pipeline)
7. 采用数据报包(DataPacket)的形式传输数据, 每个包的大小不超过: 64KB, 并建立: 反向应答机制(ACK机制)
8. 具体的上传动作: node1 -> node2 -> node3, ACK反向应答机制: node3 => node2 => node1
9. 重复上述的步骤, 直至第1个Block块上传完毕.
10. 返回第4步, 客户端(Client)重新请求第2个Block的上传位置, 重复上述动作, 直至所有的Block块传输完毕.
至此, HDFS写数据流程结束.
核心词: 请求, 校验权限, 切块, Pipeline(传输管道), ACK反向应答机制(ACK确认机制), 数据报包(64KB), 重复至完成.

HDFS原理--HDFS读数据流程

请简述你对HDFS的读数据流程的理解?
答案:
1. Client(客户端)请求namenode, 读取文件.
2. namenode校验该客户端是否有读权限, 及该文件是否存在, 校验成功后, 会返回给客户端该文件的块信息.
例如:
block1: node1, node2, node5
block2: node3, node6, node8
block3: node2, node5, node6 这些地址都是鲜活的.
......
3. Client(客户端)会连接上述的机器(节点), 并行的从中读取块的数据.
4. Client(客户端)读取完毕后, 会循环namenode获取剩下所有的(或者部分的块信息), 并行读取, 直至所有数据读取完毕.
5. Client(客户端)根据Block块编号, 把多个Block块数据合并成最终文件即可.

HDFS原理--安全模式介绍

HDFS的安全模式解释:
概述:
安全模式是HDFS自带的有一种保护机制, 在安全模式下, 只能读, 不能写.
进入安全模式的方式:
1. 启动Hadoop集群的时候, 会自动进入到安全模式, 进行自检. 自检没问题后, 会自动关闭安全模式.
2. 当活跃的节点数 < 默认的副本数时, 会强制进入到安全模式.
3. 手动进入.
格式:
hdfs dfsadmin -safemode get | enter | leave 获取 | 进入 | 离开

HDFS原理--归档操作

背景:
   HDFS适用于操作海量的大文件, 如果小文件过多, 就会占用多个Block块, 且也有多份元数据, 资源消耗比较大.
   针对于这种该情况, 我们可以用归档包来解决它.
概述:
   归档包类似于压缩包, 但是只有压, 没有缩, 相当于把多个文件合并成1个文件, 这样元数据就只有1份儿了.
格式:
   hadoop archive -archiveName 归档包的名字 -p 要被归档的文件名存储归档包的路径
演示步骤:
   1. 在Linux中创建 1.txt, 2.txt, 3.txt三个文件.
       echo 'hello world 1' >> 1.txt
       echo 'hello world 2' >> 2.txt
       echo 'hello world 3' >> 3.txt
   2. 在HDFS中创建data目录, 然后将上述的3个文件分别上传过来.
       hadoop fs -put *.txt /data
   3. 通过上述的命令, 把上述的3个txt文件压成归档包.
   需求: 把/data/所有的txt文件这三个记事本, 创建归档包, 并将归档包存储到: /output目录下.
   格式如下:
       hadoop archive -archiveName myTest.har -p /data/ /output
   4. 查看归档包的内容

[root@node1 ~]# hadoop fs -ls /output/myTest.har -- HDFS路径默认前缀是: hdfs://node1:8020/
       Found 4 items
       -rw-r--r-- 3 root supergroup 0 2024-01-17 15:09 /output/myTest.har/_SUCCESS
       -rw-r--r-- 3 root supergroup 250 2024-01-17 15:09 /output/myTest.har/_index
       -rw-r--r-- 3 root supergroup 23 2024-01-17 15:09 /output/myTest.har/_masterindex
       -rw-r--r-- 3 root supergroup 43 2024-01-17 15:09 /output/myTest.har/part-0

       遇到的问题: 发现, 上述的代码不能直接看到归档包具体归档了哪些文件, 那如何查看呢?
       解决方案: 把前缀换成归档包的前缀即可, 用什么前缀, 说明用什么规则来解析按归档包.
           hadoop fs -ls har:///output/myTest.har

           [root@node1 ~]# hadoop fs -ls har:///output/myTest.har
           Found 3 items
           -rw-r--r-- 3 root supergroup 15 2024-01-17 15:05 har:///output/myTest.har/1.txt
           -rw-r--r-- 3 root supergroup 14 2024-01-17 15:05 har:///output/myTest.har/2.txt
           -rw-r--r-- 3 root supergroup 14 2024-01-17 15:05 har:///output/myTest.har/3.txt
           [root@node1 ~]#
           [root@node1 ~]# hadoop fs -ls har://hdfs-node1:8020/output/myTest.har
           Found 3 items
           -rw-r--r-- 3 root supergroup 15 2024-01-17 15:05 har://hdfs-node1:8020/output/myTest.har/1.txt
           -rw-r--r-- 3 root supergroup 14 2024-01-17 15:05 har://hdfs-node1:8020/output/myTest.har/2.txt
           -rw-r--r-- 3 root supergroup 14 2024-01-17 15:05 har://hdfs-node1:8020/output/myTest.har/3.txt

   5. 从 /data目录中, 删除 1.txt, 2.txt, 3.txt这三个文件. 然后解压归档包, 获取到源文件.
   hadoop fs -cp /output/myTest.har/ /data 实现不了想要的效果, 只是把归档包下所有的内容拷贝过去了.
   hadoop fs -cp har:///output/myTest.har/* /data 这个才是我们要的语句.

细节:
   1. 归档包名的后缀必须是: *.har
   2. 存储归档包的路径必须是: hdfs文件的路径
   3. 归档包路径的前缀要写成: har://hdfs-node1:8020/
   4. 实际开发中, 大多数公司可以每年, 每季度, 每月, 甚至是每周归档一次, 既可以降低元数据, 也可以提高磁盘利用率(否则1个小文件就要占1个Block块)
   当我们需要使用源文件的时候, 可以很方便的从归档包中提取出我们要的内容.

HDFS原理--垃圾桶机制

概述:
   目前我们搭建的Hadoop集群, 默认没有开启垃圾桶机制, 每次删除文件, 都是永久删除的, 找不回来了.
   这样做比较危险, 我们可以开启垃圾桶机制, 这样删除数据的时候, 就会自动放到垃圾桶中, 保存一定的时间, 超出时间后, 才会自动删除.
配置垃圾桶的步骤:
   1. 去 /export/server/hadoop/etc/hadoop 的core-site.xml文件中, 加入如下的内容:
       
       <property>
           <name>fs.trash.interval</name>
           <value>1440</value>
       </property>
   2. 注意: 三台虚拟机都要去修改上述的 core-site.xml文件.
       方式1: 逐个修改.
       方式2: 远程分发, 即: 把node1中修改后的文件, 直接拷贝给node2, node3即可.
           格式:
               scp 数据源文件路径目的地主机名或者ip:要存储该文件的目录路径
           示例:
               scp core-site.xml node2:/export/server/hadoop/etc/hadoop
               scp core-site.xml node3:$PWD 如果数据源文件所在目录和另一台机器的存储目录一致, 可以写成: $PWD
   3. 三台虚拟机都修改完毕后, 记得重启: Hadoop集群.
       stop-all.sh
       start-all.sh
开启垃圾桶机制之后, 代码写法如下:
   1. 删除某个文件, 例如:
       [root@node1 hadoop]# hadoop fs -rm /data/2.txt
       2024-01-17 16:03:29,657 INFO fs.TrashPolicyDefault: Moved: 'hdfs://node1.itcast.cn:8020/data/2.txt' to trash
       at: hdfs://node1.itcast.cn:8020/user/root/.Trash/Current/data/2.txt
   2. 现在就可以从垃圾桶中恢复数据了.
       [root@node1 hadoop]# hadoop fs -mv /user/root/.Trash/Current/data/2.txt /data
   3. 如果明确要删除某个文件, 且不走垃圾桶, 删除方式如下.
       [root@node1 hadoop]# hadoop fs -rm -skipTrash /data/1.txt -- skipTrash意思是: 跳过垃圾桶