大数据课程————HDFS
HDFS基本概念
是一个文件系统，用于存储文件，通过目录树来定位文件；是分布式的，由多个服务器联合起来实现其功。
适合场景：一次写入，多次读出，不可更改。文件写入后就不需要再改变
HDFS特征
优点
- 高容错，文件报错多个副本
- 适合处理大数据，数据规模到GB、TB甚至TP；文件数量多到百万级以上均可处理
- 可建构廉价机器上
缺点
- 不适合低延迟数据访问，实时场景不合适
- 无法高效对大量小文件进行存储（占用大量NN内存来存储目录和块信息，且小文件的寻址时间超过读取时间，违反了HDFS的设计目标）
- 不支持并发写入、文件随机修改，不允许多线程写入
- 仅支持数据追加，不允许文件修改
组成架构
-
NameNode：即NN，Master，是整个HDFS的管理者，
-
- 管理HDFS的NmaeSpeace
- 配置副本策略
- 管理Block的映射信息
- 处理客户端读写请求
-
DataNode：即DN，Slave，NN下达的命令由DN执行实际的操作
-
- 存储实际的数据块
- 执行数据块的读写操作
-
Secondary NameNode：NN的冷备份，当NN挂掉后并不会立刻替换NN
-
- 辅助NN，定期合并Fsimage和Edits，并推送给NN
- 紧急情况下可辅助恢复NN
-
Client：客户端
-
- 文件切分。
- 与NameNode交互，读取文件位置信息
- 与DataNode交互，读取或写入数据
- 提供命令管理HDFS，如HDFS格式化
- 通过命令访问HDFS，如HDFS增删改查
HDFS的块大小
HDFS是分块存储，块大小通过配置参数dfs.blocksize来规定，默认大小在Hadoop2/3版本是128M，1.x版本是64M。
HDFS是块大小主要取决于磁盘传输的速率，普通机械硬盘一般8090MB/s，固态200300MB/s
- HDFS块设置太小，会增加寻址时间
- HDFS块设置太大，传输时间会明显大于寻址时间，导致程序处理这块数据会非常慢
准则：寻址时间为传输时间的1%为最佳状态。
HDFS的Shell操作
-
上传
-
- -moveFromLocal：从本地剪切粘贴到HDFS
- -copyFromLocal 或 -put：从本地文件系统中拷贝文件到HDFS路径去
- -appendToFile：追加一个文件到已经存在的文件末尾
-
下载、直接操作
-
- -copyToLocal 或 -get ：从HDFS 拷贝到本地
- -ls: 显示目录信息
- -cat：显示文件内容
- -chgrp、-chmod、-chown：Linux文件系统中的用法一样，修改文件所属权限
- -mkdir：创建路径
- -cp：从HDFS的一个路径拷贝到HDFS的另一个路径
- -mv：在HDFS目录中移动文件
- -tail：显示一个文件的末尾1kb的数据
- -rm：删除文件或文件夹
- -rm -r：递归删除目录及目录里面内容
- -du -h -s ：统计文件夹的大小信息
- -setrep：设置HDFS中文件的副本数量，最大副本数取决于节点数
HDFS的API操作
环境搭建：
- 资料包中打开windows依赖，将文件夹拷贝到本地文件，并对其添加环境变量（windows上不需要安装hadoop服务器，只需安装此文件中的winutils即可）
- 创建maven项目，添加hadoop等相关依赖
- 添加日志打印等级，创建包、类，干代码
- 注意：IDEA的jar包依赖问题困扰了很久才解决。猜测是可能本地仓库的问题，下次如果还会出现的话，把仓库删了重新换回原始的.m2试试。还有环境变量一定要注意，如果有参数不对可以优先打桩出来看看是否正确
都是代码实现，在IDEA中
HDFS的读写数据流程：面试重点
HDFS读数据流程
节点距离计算
在HDFS写数据的过程中，NN会选择距离上离带上传数据最近的DN接收数据。
节点距离：两个节点到达最近共同祖先的距离总和。
解释：将网络分层，数出节点到达共同祖先的另一节点即可
副本存储节点选择——机架感知
NameNode和DataNode的工作机制
注意的点：
secondary NameNode向NameNode checkpoint时的条件：
-
定时时间到
-
- hdfs-default.xml中有所描述，即 dfs.namenode.checkpoint.period字段，默认设置为3600s。即每个小时2NN会向NN请求checkpoint
-
Edits中的数据满了
-
- hdfs-default.xml中有所描述，即 dfs.namenode.checkpoint.txns字段，当操作次数到达100w次时，2NN执行checkpoint，检查次数的时间由 dfs.namenode.checkpoint.check.period设置，默认为60s即每分钟检查一次操作次数
Fsimage和Edits解析
NameNode被格式化之后，将会在$HADOOP_HOME/data/tmp/dfs/name/cirrent目录下产生如下文件
Fsimage：HDFS文件系统元数据的一个永久性的检查点，包含HDFS文件系统的所有目录和文件inode的序列化信息
Edits：存放HDFS文件系统的所有更新操作，客户端执行的写操作会首先被记录到Edits文件中（追加操作）
seen_txid：保存的是一个数字，最后一个edits_的数字
- oiv查看Fsimage文件
语法：hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径
1 | |
fsimage.xml文件中，记录了HDFS中的文件树，并使用inode来作为元数据中的目录管理节点，与文件一一对应。
- oev查看Edits
语法：hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径
1 | |
edits.xml中记录了写入追加的操作。
NN和2NN最大的区别就是2NN没有edits_inprogress这个记录最新操作的文件，因此如果发生数据丢失，最有可能丢失的是最近一次操作，而往期操作被存放在2NN中
DataNode 的工作机制
服务及开机之后，DN会主动向NN发送当前节点的所有块信息（活动的块，非死亡块）（注册）
块信息——数据、数据长度、校验和、时间戳
在开机之后：
- DN会自己自我检查块信息（每6小时，字段：dfs.datanode.directoryscan.interval）查询之后立即向NN汇报（每6小时，字段dfs.blockreport.intervalMsec）所有块信息
- DN会每3秒发起心跳信号，告诉NN它还存活。若超过10分钟+30秒（timeOut=2dfs.namenode.heartbeat.recheck-interval + 10dfs.heartbeat.interval）NN仍未收到DN的的心跳信号，NN则认为该DN不可用，即不再使用该节点读写数据
HDFS数据完整性校验
原始数据封装后在末尾添加CRC校验位，HDFS接收数据后重新CRC计算与传输过来的校验位比较看是否一致
待续