Hadoop - HDFS学习笔记（详细）

第1章 HDFS概述

• hdfs背景意义
  • hdfs是一个分布式文件系统
  • 使用场景：适合一次写入，多次读出的场景，且不支持文件的修改。
• 优缺点
  • 高容错性，适合处理大数据（数据PB级别，百万规模文件），可部署在廉价机器上
  • 不适合低时延数据访问，无法高效存储大量小文件，不支持并发写入、随机修改（仅追加）
• hdfs组成架构
  • namenode，管理hdfs命名空间，配置副本策略，管理数据块的映射信息，处理客户端读写请求
  • datanode，存储实际的数据块，执行数据块的读写操作
  • Client客户端，文件切分，与namenode交互获取文件位置，与datanode交互读写数据，提供一些命令管理hdfs
  • secondary namenode，辅助namenode，分担其工作量，定期合并镜像Fsimage和编辑日志Edits并推送给namenode，紧急情况下可恢复namenode
• 文件块block（面试重点）
  • 分块存储，hadoop2.x 128M，1.x 64M
  • 寻址时间为传输时间1%，为最佳状态，寻址10ms左右，传输100M/s左右，那么传输为1s左右，块为100M左右
  • 思考：块为什么不能设置太小，也不能太大？块太小，会增加寻址时间，增加namenode元数据，占用内存；快太大，磁盘传输时间会明显大于寻址时间，导致处理数据时非常慢，块大小的设置主要取决于磁盘传输速率
  • 一个文件块的元数据150byte左右
  • hdfs块中默认是3份

第2章 HDFS的shell操作（开发重点）

• 基本语法：hadoop fs -具体命令 或者 hdfs dfs -具体命令，dfs是fs的实现类。hadoop fs：显示所有命令
• 常用命令：hadoop fs -命令
  • -help：输出命令的参数，hadoop fs -help rm
  • -ls dir: 显示目录信息，-r递归显示
    • -mkdir dir：在HDFS上创建目录，-p创建多级目录
    • -moveFromLocal file1/dir1 dir2：从本地剪切粘贴到HDFS
    • -copyFromLocal file1/dir1 dir2：从本地文件系统中拷贝文件到HDFS路径去
    • -copyToLocal file1/dir1 dir2：从HDFS拷贝到本地
    • -mv file1/dir1 dir2：在HDFS目录中移动文件
    • -cp file1/dir1 dir2：从HDFS的一个路径拷贝到HDFS的另一个路径
    • -get file1/dir1 dir2：等同于copyToLocal，就是从HDFS下载文件到本地
    • -put file1/dir1 dir2：等同于copyFromLocal
    • -getmerge file1 file2 ... fileMerge：合并下载多个文件，比如HDFS的目录 下有多个文件:log.1, log.2,log.3,...
    • -appendToFile file1 file2：追加一个文件到已经存在的文件末尾
    • -rm file/dir：删除文件或文件夹，-r递归删除
    • -rmdir dir：删除空目录
    • -du dir：统计文件夹的大小信息，-h单位可读，-s总大小
    • -cat：显示文件内容
    • -tail：显示一个文件的末尾
    • -chgrp 、-chmod、-chown xxx file/dir：Linux文件系统中的用法一样，修改文件所属权限
    • -setrep file：设置HDFS中文件的副本数量

第3章 HDFS客户端操作（开发重点）

HDFS客户端环境准备

• 配置HADOOP_HOME环境变量，copywin7下编译的hadoop-27.2
• 配置MAVEN_HOME环境变量（安装，配置环境变量）
• 创建maven工程，导入依赖
• 如果Eclipse/Idea 打印不出日志，在项目的src/main/resources 目录下，新建一个文件，命名为“log4j.properties”
• 创建包，写一个HDFSClient程序上传文件，测试

HDFS的API操作

• HDFS文件上传：copyFromLocalFile（测试参数优先级）：客户端代码中设置的值>resources下的site>集群上的site>服务器的默认配置
• HDFS文件下载：copyToLocalFile
• HDFS 文件夹删除：delete
• HDFS 文件名更改：rename
• HDFS 文件详情查看：listFiles，返回迭代器，内容是LocatedFileStatus
• HDFS 文件和文件夹判断：listStatus，返回FileStatus[]，isFile()判断

HDFS的IO操作

• HDFS 文件上传：FileInputStream创建输入流，fs.create创建输出流，拷贝IOUtils.copyBytes，关闭资源
• HDFS 文件下载：fs.open创建输入流，ileOutputStream创建输出流，拷贝，关闭资源
• 定位文件读取：fs.open创建输入流，seek()定位输入数据位置，ileOutputStream创建输出流，拷贝，关闭资源；第一块使用byte[]读取一定长度，剩下的使用seek()

第4章 HDFS的数据流（面试重点）

HDFS写数据流程

• 1，客户端向namenode请求上传文件，namenode检查父目录，上传文件是否存在
• 2，namenode返回是否可以上传
• 3，客户端请求上传到哪些datanode服务器
• 4，返回3个datanode节点，dn1，dn2，dn3，（根据距离，负载情况）
• 5，客户端请求向第一个dn1上传数据，dn1收到后调用dn2，dn2调用dn3，将这个通信管道建立
• 6，dn1，dn2，dn3逐级应答客户端
• 7，客户端开始上传第一个block，以package为单位，dn1收到会传给dn2，dn2收到传给dn3；dn1每传一个package会放入一个应答队列等待应答
• 8，传完一个block之后，再次向namenode请求上传第2个block，重复3-7
• 网络拓扑-节点距离计算：节点距离：两个节点到达最近的共同祖先的距离总和
• 机架感知（副本存储节点选择）：第一个在Client所在的机架上随机选一个，第二个在同机架其他随机节点，第三个在其他机架上

HDFS读数据流程

• 1，客户端向namenode请求下载文件，namenode通过查询元数据找到文件所在datanode
• 2，挑选一个最近的datanode，请求读取数据
• 3，datanode开始传输数据给客户端
• 4，客户端缓存后写入目标文件
• 5，请求读取其他块，重复2-4，然后将读取的块拼接起来

第5章 NameNode和SecondaryNameNode（面试开发重点）

namenode和secondary namenode工作机制

• namenode
  • 元数据存储在内存中
  • 防止断电，数据丢失，在磁盘中存储镜像文件
  • 有元数据的操作请求时，改镜像文件，效率低
  • 引入编辑日志（只追加，效率很高），先追加到编辑日志，在修改内存中的元数据（这样编辑日志和镜像文件中就保留了所有的元数据）
  • namenode启动时，加载镜像文件和编辑日志
• secondary namenode
  • 询问namenode是否CheckPoint（定时时间到、Edits满了），带回结果
  • secondary namenode请求执行CheckPoint
  • 滚动正在写的Edits编辑日志
  • 将滚动前的编辑日志和镜像文件加载到内存，合并
  • 生成新的镜像文件，拷贝到namenode
  • namenode重命名镜像文件，下次启动时只需要使用镜像文件和新编辑日志

Fsimage和Edits解析

• oiv 查看Fsimage 文件：hdfs oiv -p 文件类型-i 镜像文件-o 转换后文件输出路径
• oev 查看Edits 文件：hdfs oev -p 文件类型-i 编辑日志-o 转换后文件输出路径
• Fsimage不记录块对应的datanode，datanode主动上报数据块信息

思考：可以看出，Fsimage 中没有记录块所对应DataNode，为什么？
在集群启动后，要求DataNode 上报数据块信息，并间隔一段时间后再次上报。
思考：NameNode 如何确定下次开机启动的时候合并哪些Edits？
seen_txid记录了最新的编辑日志

CheckPoint时间设置

• hdfs-site.xml
  • dfs.namenode.checkpoint.period：3600，通常情况下，SecondaryNameNode 每隔一小时执行一次
  • dfs.namenode.checkpoint.txns：1000000，当操作次数达到1 百万时
    dfs.namenode.checkpoint.check.period：60，1 分钟检查一次操作次数

NameNode故障处理

• 杀死进程：kill - 9 ID
• NameNode 故障后，可以采用如下两种方法恢复数据
  • 方法一：将SecondaryNameNode 中数据拷贝到NameNode 存储数据的目录，重新启动NameNode
  • 方法二：使用-importCheckpoint 启动NameNode ， 从而将SecondaryNameNode 中数据拷贝到NameNode 目录中
    - 如果SecondaryNameNode 不和NameNode 在一个主机节点上，需要将SecondaryNameNode 存储数据的目录拷贝到NameNode 存储数据的平级目录，并删除in_use.lock 文件
    - 需要配置hdfs-site.xml中namenode的准确地址：dfs.namenode.name.dir，默认是${hadoop.tmp.dir}/dfs/name
    - hdfs namenode -importCheckpoint

集群安全模式

• NameNode启动时，加载镜像文件和编辑日志，此时处于安全模式，NameNode的文件系统对于客户端是只读的
• DataNode启动时，（系统中的数据块不是由NameNode维护的，而是以块列表的形式存在DataNode中），在系统的正常操作期间，NameNode会在内存中保留所有块的位置信息。在安全模式下，个DataNode会向NameNode发送最新的块列表信息，NameNode了解到足够多的块信息后，即可运行文件系统
• 安全模式退出判断：满足最小副本条件，NameNode会在30秒之后退出安全模式。最小副本条件是指：在整个文件系统中99.9%的块满足最小副本级别（默认值dis.replication.min=1）。在启动一个刚刚格式化的集群时，因为系统中没有任何块，所以NameNode不会进入安全模式。（99.9%的块都至少有一份！）
• （1）bin/hdfs dfsadmin -safemode get （功能描述：查看安全模式状态）
  （2）bin/hdfs dfsadmin -safemode enter （功能描述：进入安全模式状态）
  （3）bin/hdfs dfsadmin -safemode leave （功能描述：离开安全模式状态）
  （4）bin/hdfs dfsadmin -safemode wait （功能描述：等待安全模式状态）等待安全模式结束后执行之后的命令

NameNode多目录设置

• NameNode 的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性
• 配置hdfs-site.xml：fs.namenode.name.dir为多个地址file:///${hadoop.tmp.dir}/dfs/name1,file:///${hadoop.tmp.dir}/dfs/name2

第6章 DataNode（面试开发重点）

DataNode工作机制

• 1，一个数据块在datanode上以文件形式存储在磁盘上，包括两个文件，一个是数据块，一个是元数据（长度，校验和）
• 2，datanode启动后向namenode注册，通过后，周期性（1小时）上报所有块的信息
• 3，心跳每3秒一次，带回namenode给datanode的命令，超过十分钟没有收到datanode的心跳，认为该节点不可用
• 4，集群运行中可以加入和退出一些机器

数据完整性

• crc校验

掉线时限参数设置

• datanode进程死亡或网络故障无法与namenode通信，namenode不会立即判定该节点死亡，默认（10分钟+30秒）
• 超时时间：timeout=2*dfs.namenode.heartbeat.recheck-interval + 10*dfs.heartbeat.interval；默认值（5分钟，3秒）

服役新datanode

• 直接启动datanode即可关联到集群（必须有相同的配置信息，其中包含namenode节点地址等等，必须删除data/和logs/）
• 如果数据不均衡，可以用命令实现集群的再平衡：start-balancer.sh

退役旧datanode

• 添加到白名单的主机节点，都允许访问NameNode，不在白名单的主机节点，都会被退出。
  • etc/hadoop/dfs.hosts，添加主机名称（无空格空行）
  • hdfs-site.xml配置白名单路径：dfs.hosts，分发hdfs-site.xml，路径地址末尾不能换行，否则读取不到
  • 刷新节点：hdfs dfsadmin -refreshNodes

注意：不在白名单上的节点的数据不会拷贝到其他节点，下载数据会报错

• 黑名单退役，在黑名单上的主机都会被强制退出
  • etc/haoop/dfs.hosts.exclude，添加主机名称或IP地址
  • hdfs-site.xml配置dfs.hosts.exclude路径，分发hdfs-site.xml，路径地址末尾不能换行，否则读取不到
  • 刷新NameNode：hdfs dfsadmin -refreshNodes
  • 刷新RM：yarn rmadmin -refreshNodes

注意：黑名单上的节点的数据会拷贝到其他节点，此时显示为（Decommission in progress）。也即是副本数小于设定值的话是不能退役的，当节点上的块全部在别的节点上都增加了相应的副本就退役（Decommission）。

• 刷新节点在任何一个节点都可以进行，此时是通知NameNode节点刷新，NameNode会读取所在节点的相应配置文件，也即是dfs.hosts和dfs.hosts.exclude文件在其他节点上无效，hdfs-site.xml中对应的路径配置也无效。
• 不允许白名单和黑名单中同时出现同一个主机名称。

DataNode多目录设置

• DataNode 也可以配置成多个目录，每个目录存储的数据不一样，只是多个目录用于存储数据，不是备份数据，可以用于数据太多，存储到不同磁盘。
• 配置hdfs-site.xml，dfs.datanode.data.dir下设置多个目录，file:///${hadoop.tmp.dir}/dfs/data1,file:///${hadoop.tmp.dir}/dfs/data2

第7章 HDFS 2.x新特性

• 集群间数据拷贝
  • scp 实现两个远程主机之间的文件复制：scp -r src dst
  • hadoop distcp 命令实现两个 集群之间的递归数据复制（并行）：
    hadoop distcp hdfs://haoop102:9000/user/atguigu/hello.txt hdfs://hadoop103:9000/user/atguigu/hello.txt
• 小文件存档，需要启动YARN运行MR
  • hadoop archive -archiveName  input.har -p src ds，将多个小文件存档成har文件（实际是一个文件夹），dst必须不存在，实际上是运行了一个MapReduce任务
• 回收站：开启回收站功能，可以将删除的文件在不超时的情况下，恢复原数据，起到防止误删除、备份等作用。
  • 配置core-site.xml，fs.trash.interval=0，单位分支，默认0表示关闭，时间到就删除
  • fs.trash.checkpoint.interval=0，检查间隔，必须小于保留时间，每次检测，会创建新的checkpoint文件夹
  • 修改访问垃圾回收站用户名称：设置hadoop.http.staticuser.user，默认是dr.who
  • 恢复回收站数据：hadoop fs -mv回来就可以了
  • 清空回收站：hadoop fs -expunge，结果跟checkpoint一样，创建一个新的checkpoint文件夹

注意：通过程序删除的文件不会经过回收站，需要调用moveToTrash()才进入回收站，Trash trash = New Trash(conf);
trash.moveToTrash(path)

• 快照管理：相当于对目录做备份，不会备份文件，而是记录文件变化。建立文件系统的索引，每次更新文件不会真正的改变文件，而是新开辟一个空间用来保存更改的文件，
  • 快照是瞬时的代价为O(1)，取决于子节点扫描文件目录的时间
  • 当做快照的文件目录下有文件更新时才会占用小部分内存，大小为O(M)，其中M为更改文件或者目录的数量；
  • 新建快照的时候，Datanode中的block不会被复制，快照中只是记录了文件块的列表和大小信息。
  • 每个快照最高限额为65536个文件或者文件夹，在快照的子文件夹中不允许在创建新的快照。

 

• hdfs dfsadmin -allowSnopshot 路径 （开启指定目录的快照功能）
• hdfs dfsadmin -disallowSnopshot 路径 （禁用指定目录的快照功能，默认禁用）
• hdfs dfs -createSnapshot 路径（对目录创建快照）
• hdfs dfs -createSnapshot 路径 名称（对目录创建快照，指定名称）
• hdfs dfs -renameSnapshot 路径 旧名称 新名称（重命名快照名称）
• hdfs dfs -lsSnopshottableDir（列出当前用户所有可快照目录）
• hdfs dfs snapshotDiff 快照路径 名称1 名称2（比较两个快照不同之处，.表示当前状态，.snapshot可以省略）
• hdfs dfs -deleteSnapshot 路径 名称（删除快照）

第8章 HDFS高可用

https://blog.csdn.net/weixin_37680513/article/details/107397114