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  备份两次+之前的

hadoop基础学习心得 hadoop心得体会_hadoop基础学习心得

1.指定NameNode的地址

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

hadoop基础学习心得 hadoop心得体会_hadoop_02

伪分布式配置副本数遍必须为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. 便于进行快速的备份

hadoop基础学习心得 hadoop心得体会_hadoop_03

1.文件上传失败：

hadoop基础学习心得 hadoop心得体会_hadoop_04

2.解决方案： 

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

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

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

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

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

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

hadoop基础学习心得 hadoop心得体会_hadoop_05

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

  • $ ./hadoop namenode -format

hadoop基础学习心得 hadoop心得体会_HDFS_06

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

  • $./start-all.sh

hadoop基础学习心得 hadoop心得体会_HDFS_07

5.上传成功

hadoop基础学习心得 hadoop心得体会_hadoop基础学习心得_08

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

hadoop基础学习心得 hadoop心得体会_hadoop基础学习心得_09

7.查看

hadoop基础学习心得 hadoop心得体会_HDFS_10

三、NameNode

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

一.创建一个文件夹

hadoop基础学习心得 hadoop心得体会_元数据_11

hadoop基础学习心得 hadoop心得体会_hadoop_12

二.删除文件夹

hadoop基础学习心得 hadoop心得体会_元数据_13

hadoop基础学习心得 hadoop心得体会_HDFS_14

三.元数据

hadoop基础学习心得 hadoop心得体会_元数据_15

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

四、DataNode

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

hadoop基础学习心得 hadoop心得体会_hadoop_16

五、SecondaryNameNode

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

六、复本放置策略

  1. 在HDFS中，默认是多复本策略，默认复本数量为3
  2. 复本放置策略：
  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. 不支持事务