Hadoop个人心得笔记之HDFS

阳光穿透心脏的1/2处 2021-12-20 04:41 524阅读 0赞

#                                               HDFS总结 #

**目录**

HDFS总结

一、概述

二、Block

1.文件上传失败：

2.解决方案：

2、删除在hdfs中配置的元数据目录

3、重新格式化namenode(切换到hadoop目录下的bin目录下)

4、重新启动hadoop集群（切换到hadoop目录下的sbin目录下）

5.上传成功

6.使用hadoop dfsadmin -report查看使用情况

7.查看

三、NameNode

一.创建一个文件夹

二.删除文件夹

三.元数据

四、DataNode

五、SecondaryNameNode

六、复本放置策略

七、机架感知策略

八.特点

--------------------

# 一、概述 #

1.  在HDFS中，存在两类主要的节点：NameNode 和DataNode 
2.  NameNode负责管理DataNode，DataNode负责存储数据
3.  在存储数据的时候会将数据进行切块
4.  为了防止产生数据丢失，会将数据进行备份，备份称之为复本 - replication。在Hadoop中，默认复本数量为3  备份两次+之前的

![20190628190844213.png][]

1.指定NameNode的地址

2.指定DataNode的数据存放目录

![20190628191014145.png][]

伪分布式配置副本数遍必须为1

# 二、Block #

1.  在存储数据的时候会将数据进行切块，每一个块称之为是一个Block  一个文件切割多个Block
2.  Block是HDFS的基本存储单位
3.  在Hadoop2.0版本中，每一个Block默认是128M。可以通过**dfs.blocksize**来更改块的大小，在更改的时候，单位是字节
4.  如果一个文件的大小不足128M，那么这个文件是多大在HDFS上就占多大的地方
5.  在HDFS中，会对Block进行编号 - BlockID
6.  将数据切块的意义：
    
    1.  便于存储超大文件
    2.  便于进行快速的备份

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xpdVk1MjE_size_16_color_FFFFFF_t_70][]

## 1.文件上传失败： ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xpdVk1MjE_size_16_color_FFFFFF_t_70 1][]

## 2.解决方案：  ##

**PS：因为之前安装分布式的时候，挖了个坑，爬出来之后忘记，埋上了，又掉进去了**

**    查阅资料发现造成这个问题的原因可能是使用hadoop namenode -format格式化时格式化了多次造成那么spaceID不一致，解决方案：**

**1、停止集群（切换到/sbin目录下）  
$./stop-all.sh**

### **2、删除在hdfs中配置的元数据目录** ###

**（即在core-site.xml中配置的hadoop.tmp.dir对应文件件）下面的所有数据;**

*  **$ rm -rf /home/hadoop/tmp/\***

![20190628192911855.png][]

### **3、重新格式化namenode(切换到hadoop目录下的bin目录下)** ###

*  **$ ./hadoop namenode -format**

![20190628193608221.png][]

### **4、重新启动hadoop集群（切换到hadoop目录下的sbin目录下）** ###

*  **$./start-all.sh**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xpdVk1MjE_size_16_color_FFFFFF_t_70 2][]

### **5.上传成功** ###

![2019062819365961.png][]

### **6.使用hadoop dfsadmin -report查看使用情况** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xpdVk1MjE_size_16_color_FFFFFF_t_70 3][]

### 7.查看 ###

![20190628194305967.png][]

# 三、NameNode #

1.  管理DataNode和记录元数据Meta
2.  元数据包含：
    
    1.  记录数据的虚拟存储路径  不存在的路径
    2.  记录文件的切块数量         不同的文件切块数量不同
    3.  记录数据块的存储位置      
    4.  记录数据块的复本数量     不同文件备份数量不同
    5.  记录文件权限                   校验权限
3.  元数据的大小是在150B左右
4.  NameNode将元数据维系在内存以及磁盘中
5.  元数据维系在内存中的目的是为了**快速查询**
6.  元数据维系在磁盘中的目的是为了**崩溃恢复**
7.  元数据的存储位置是由hadoop.tmp.dir属性决定，如果不配置则默认使用/tmp
8.  元数据在磁盘中是以edits文件和fsimage文件的形式存在
    
    1.  edits：记录写操作
    2.  fsimage：记录元数据。fsimage中的元数据和内存中的元数据并不是同步的
9.  当NameNode接收到写请求之后，会先将该请求记录到edits\_inprogess文件中，如果记录成功，则将该请求同步更新到内存中，修改内存中的元数据，内存修改完成之后会给客户端返回一个ack表示成功
10. 在HDFS中，会给每一次的写操作分配一个编号 - 事务id - txid
11. 当edits文件达到条件的时候会将操作更新到fsimage文件中，即修改fsimage文件中的元数据：
    
    1.  空间维度：当edits\_inprogress文件达到指定大小的时候就会触发更新，默认是64M，大小可以由fs.checkpoint.size（**core-site.xml**）来指定，默认单位是字节
    2.  时间维度：当距离上一次更新达到指定间隔时候的时候就会触发更新，默认是1H，大小可以由fs.checkpoint.period来指定，默认单位是秒 3600S
    3.  重启更新：NameNode重启之后，会自动的将edits\_inprogress中的操作更新到fsimage中
    4.  强制更新：hadoop dfsadmin -rollEdits
12. 在更新的时候，会将edits\_inprogress重命名为edits\_XXXXXX-XXXXXX，同时产生一个新的edits\_inprogress
13. 在Hadoop中，如果存在SecondaryNameNode，则更新过程是发生在SecondaryNameNode
14. 在HDFS中，最核心的节点是NameNode。但是在Hadoop1.0版本中只能有1个NameNode，在Hadoop2.0版本中，进行了改变，允许多设置一个NameNode，代价是丢掉SecondaryNameNode
15. NameNode通过心跳机制来管理DataNode：DataNode每隔定长时间会给NameNode发送心跳信息
16. 默认情况下，DataNode每隔3s给NameNode发送一条信息
17. 如果NameNode长时间（默认是10min）没有收到某个DataNode的心跳信息，则认为这个DataNode已经lost（丢失），此时NameNode会将这个DataNode中的数据再次备份，保证复本数量
18. 心跳信息包含：
    
    1.  当前节点的状态
    2.  当前节点中所存储的数据块信息
19. NameNode重新启动的时候，将edits中的操作更新到fsimage中，将fsimage中的元数据加载到内存中，等待DataNode的心跳（如果DataNode没有心跳过来则要重新备份保证复本数量，校验数据总量），这个过程称之为是安全模式(safe mode)。如果所有的校验都成功，则HDFS会自动退出安全模式   
20. 四千个节点 半个小时会退出安全模式  如果退不出去可以强制退出安全模式  hadoop dfsadmin -safemode leave
21. 因为安全模式的问题，所以在伪分布式下，复本数量必须为1 - 如果复本数量不为1，则重启NameNode的时候，会导致HDFS一直处于安全模式

## 一.创建一个文件夹 ##

![20190628194849185.png][]

![20190628195512589.png][]

## 二.删除文件夹 ##

![20190628195601538.png][]

![20190628195618882.png][]

## 三.元数据 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xpdVk1MjE_size_16_color_FFFFFF_t_70 4][]

1.  edits：记录写操作
2.  fsimage：记录元数据。fsimage中的元数据和内存中的元数据并不是同步的

# 四、DataNode #

1.  用于存储数据，注意数据是以Block形式存储
2.  数据在DataNode上的存储位置由hadoop.tmp.dir属性决定，存储目录是dfs/data/current/块池/current/finalized/subdir0/subdir0
3.  DataNode会通过心跳机制（RPC方式）来向NameNode发送心跳信息

![20190629092538997.png][]

# 五、SecondaryNameNode #

1.  SecondaryNameNode只是辅助NameNode进行元数据的合并
2.  SecondaryNameNode能起到一定的备份作用，但是不能做到和NameNode之间进行实时热备 - 在实际开发中，一旦利用到SecondaryNameNode进行了备份，往往意味着数据已经产生了丢失
3.  在HDFS中，最核心节点一定是NameNode，也因此在Hadoop2.0的完全分布式中，为了做到NameNode的热备，舍弃了SecondaryNameNode

# 六、复本放置策略 #

1.  在HDFS中，默认是多复本策略，默认复本数量为3

1.  复本放置策略：
    
    1.  第一个复本：如果是外部客户端上传数据，则此时NameNode会选择一个相对空闲的节点存放第一个复本；如果是内部上传，则第一个复本放在本节点上
    2.  第二个复本：在Hadoop2.7以前，第二个复本要放在和第一个复本不同机架的节点上；从Hadoop2.7开始，第二个复本放在和第一个复本相同机架的节点上
    3.  第三个复本：在Hadoop2.7以前，第三个复本是放在和第二个复本相同机架的节点上；从Hadoop2.7开始，第三个复本放在和第二个复本不同机架的节点上
    4.  更多复本：随机挑选空闲节点存放

# 七、机架感知策略 #

1.  在Hadoop所指的机架并不是物理结构而是逻辑结构
2.  可以通过映射关系来指定节点对应的机架，也就意味着同一个物理机架上的节点可以映射到不同的逻辑机架上
3.  实际使用中，一般会将一个或者几个物理机架上的节点放在一个逻辑机架上

# 八.特点 #

1.  能够存储超大文件 - 切块
2.  快速的应对和检测故障 - 心跳
3.  保证数据的高可靠 - 复本
4.  简易的一致性模型 - 一次写入多次读取，在Hadoop2.0开始，允许追加
5.  能够利用低廉的设备来进行横向扩展
6.  不建议存储大量小文件
7.  不支持低延迟访问
8.  不支持事务

[20190628190844213.png]: /images/20211220/d0ba78f5703a467bb19a3e36cb1047df.png
[20190628191014145.png]: /images/20211220/ebe3561d3824444e83edf3b35f0d8e52.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xpdVk1MjE_size_16_color_FFFFFF_t_70]: /images/20211220/c235cf004ee64691828d58608f6c557e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xpdVk1MjE_size_16_color_FFFFFF_t_70 1]: /images/20211220/2cac372f200844e89de10f0fc8138e57.png
[20190628192911855.png]: /images/20211220/d96f7d53de4d425b905daafb746d788c.png
[20190628193608221.png]: /images/20211220/0d4c98469f244280a20d7e7b556f7482.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xpdVk1MjE_size_16_color_FFFFFF_t_70 2]: /images/20211220/68f8a6188cb44237b2b619e00790b9c2.png
[2019062819365961.png]: /images/20211220/20803e32a5424cc4871bd10df0ed71e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xpdVk1MjE_size_16_color_FFFFFF_t_70 3]: /images/20211220/436396731b884cb295ea4a195f999f90.png
[20190628194305967.png]: /images/20211220/6fcdac91a3bc44ee9babba417d0487e9.png
[20190628194849185.png]: /images/20211220/6b2e5ed31f6d45a295ab557de94f7b85.png
[20190628195512589.png]: /images/20211220/08b1147946b4436c9a14965aaab60771.png
[20190628195601538.png]: /images/20211220/12c086853f8f4de6a97d233bf883cf30.png
[20190628195618882.png]: /images/20211220/e1e0f846f03c401893a40d29f34b8234.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xpdVk1MjE_size_16_color_FFFFFF_t_70 4]: /images/20211220/b1894bc6736d4087bc5c3fa1582df298.png
[20190629092538997.png]: /images/20211220/1d5827d216224a509742eb8dbbef527c.png