HDFS概述
HDFS（Hadoop Distributed File System），是一个文件系统（更确切点是分布式文件管理系统的一种）。HDFS适用场景，适合一次写入，多次读出的场景，且不支持文件的修改。适合用来做数据分析，并不适合做网盘应用。
架构图
优缺点
优点：
1.高容错性
2.适合处理大数据
3.可构建在廉价的机器上，通过多副本机制提高可靠性。
4.高容错性，数据自动保存多个副本，通过增加多个副本的行式提高容错性，若一个副本丢失以后，可以自动恢复；适合处理大数据，数据规模上能够处理TB、甚至PB级别数据，文件规模上能够处理百万规模以上的文件数量；
缺点：
1.不适合低延时数据访问，比如做不到毫秒级别的存储数据
2.无法高效地对大量小文件进行存储
3.不支持并发写入、文件随机修改。
存储大量的小文件会占用NN大量的内存来存储文件的目录和块信息，NN的内存总是有限的；
另外小文件存储的寻址时间会超过读取时间，违反了HDFS的设计目标；
HDFS不允许多个线程同时写，仅支持数据追加（append），不支持文件随机修改。
HDFS Shell操作
基本命令
//创建多级目录hadoop fs -mkdir -p /a/b//删除多级目录hadoop fs -rm -R /hdfs/zhan//上传本地文件到HDFS：hadoop fs -put /local/zhan.txt /hdfs/zhan.txt//从本地剪切到HDFS：hadoop fs -moveFromLocal /local/zhan.txt /hdfs///从本地拷贝到HDFS：hadoop fs -copyFromLocal /local/zhan.txt /hdfs///从HDFS拷贝本地：hadoop fs -copyToLocal /hdfs/zhan.txt /local///追加一个本地文件到HDFS已存在的文件末尾：hadoop fs -appendToFile /local/qian.txt /hdfs/zhan.txt//下载HDFS文件到本地：hadoop fs -get /hdfs/zhan.txt /local//合并下载多个HDFS文件到本地：hadoop fs -getmerge /hdfs/* /local/zhanqian.txt//查看：hadoop fs -[cat|tail] /hdfs/zhan.txt//统计目录总大小：hadoop fs -du -h -s /hdfs//设置副本数量为2：hadoop fs -settrep 2 /hdfs/zhan.txt
HDFS数据流
写流程
- 客户端访问集群，首先创建Distribute FileSystem对象进行集群连接，向NN进行文件上传申请
- NN响应，
- 请求上传第一个Block（0-128M），默认Block大小为128M
- NN返回DN1、DN2、DN3返回三个节点存储数据
- 客户端建立DN通道
- DN应答
- 客户端开始传输数据，串行存储
- DN存储完成后通知NN
- NN返回响应
NN的返回给客户端的节点是如何选择的？
NN会返回距离文件上传最近的DN节点。
如何判节点间距离？
两个节点到达公共祖先的距离之和。
读流程
- 创建Distributed FileSystem，请求NN下载xx路径文件
- NN返回相关DN的节点地址
- FSDataInputStream 依次请求DN1的blk_1下载
- DN1数据传输
- 请求DN2的blk_2下载
- DN2返回
- 关闭流
NN和SNN
思考：NN中的元数据存储在哪里？
假如是存储在磁盘上，那么频繁的读写，IO开销特别高效率特别低，所以不适合存放在磁盘。
假如是存储在内存中，那么如果断电或者内存被清除，那么就无法复原元数据，集群不可工作。
那么最好的方式就是内存+磁盘的存储方式，内存读写，磁盘备份复原的方式，即磁盘中备份元数据的FSImage。那么又引申出数据一致性的问题，数据写的时候同时写内存和FSImage，效率也过低，不写FSImage会导致数据不一致，产生数据丢失。因此引入Edits文件（只进行操作日志追加，即WAL），高效率写磁盘的日志文件。这样一旦断电，通过Edits和FSImage的合并，即可合成元数据。
但是如果长时间如此，Edits文件会越来越庞大，每次数据恢复会越来越慢，元数据恢复的效率越来越低。因此需要定时合并Edits和FSImage，如果由NN来执行，NN的效率会被拖慢（消耗NN资源）。因此引入了SNN，专门用于Edits和FSImage的合并。
NN和SNN的元数据存储工作机制
- SNN定时监控
- checkpoint，满足时间或空间条件即触发
- SNN从NN拷贝edits和fsimage，内存中合并
- 合并后写入文件SNN.fsimage
- SNN.fsimage拷贝至NN
- NN进行fsimage替换
namenode
属性名dfs.namenode.name.dir的是namenode的Fsimage文件路径
属性名dfs.namenode.edits.dir的是namenode的Edits_Log文件路径
SecondaryNameNode
属性名dfs.namenode.checkpoint.dir的是namenode的Fsimage文件路径
属性名dfs.namenode.checkpoint.edits.dir的是namenode的Edits_Log文件路径
SecondaryNameNode工作的触发因素：
- 时间维度，默认一小时触发一次工作流程 dfs.namenode.checkpoint.period ：3600
- 次数维度，默认100万次触发一次工作流程 dfs.namenode.checkpoint.txns ： 1000000（60s判断一次是否达到100W）
集群安全模式
NameNode启动
NN启动时，首先加载FSImage载入内存，并执行合并Edits文件。一旦在内存中成功建立系统元数据得镜像，则创建一个新得FsImage和空得Edit日志文件。次时，NN开始监听DN请求。这个过程期间，NN一直运行在安全模式，即NN得文件系统对于客户端来说是只读得
DataNode启动
Block数据块得位置并不是由NN维护得，而是存储在DN中的。在系统正常操作期间，NN会在内存中保留所有块位置的映射信息；在安全模式下，各个DN会向NN发送最新的块列表信息。
安全模式退出判断
如果满足最小副本条件，NN会在30秒后推出安全模式。所谓最小副本条件是指在整个文件系统中99.99%的块满足最小副本级别（默认dfs.replication.min=1）。在启动一个刚刚格式化的HDFS集群时，因为系统中没有任何块，所以NN不会进入安全模式。
集群处于安全模式，不能执行重要操作（写操作），集群启动后，自动退出安全模式。
DN
DN工作机制
掉线时限参数设置，DN进程死亡或网络故障造成无法与NN通信，NN并不会立刻判定DN不可用，会有一段TimeOut时常。
TimeOut = 2 * dfs.namenode.heartbeat.recheck.interval + 10 * dfs.heartbeat.interval
默认 dfs.namenode.heartbeat.recheck.interval 为5分钟，dfs.heartbeat.interval 为3秒
数据完整性
- 当DN读取Block时候，会计算checkSum
- 如果计算后的checkSum与Block创建时值不一样，说明Block已经损坏
- Client读取其他DN上的Block
- DN在其文件创建后，周期验证checkSum（简单点就是用奇偶校验，生产一般使用CRC校验）
HDFS2.X新特性
集群间数据拷贝
//采用distcp命令实现两个hadoop集群之间的递归数据复制
bin/haddop distcp hdfs://host1:9000/user/zhan.txt hdfs://host2:9000/user/zhan.txt
小文件存档
每个文件均按块存储，每个块的元素据存储在NN的内存中（每个块信息大约占150B），因此HDFS存储小文件效率会非常低，大量的小文件会耗尽NN的内存。注：存储小文件所需要的磁盘容量和数据块的大小无关。
解决小文件存储方法之一，对文件进行归档（har）存储。har将多个小文件归档成一个文件存入HDFS块中，在减少NN内存使用的同时，允许对一个文件进行透明访问。通俗来说，HDFS归档文件还是一个个独立的文件，但对NN而言却是一个整体，主要为了减少占用NN内存。
归档文件使用命令：
//1.启动Yarn
start-yarn.sh
//2.归档文件，把/user/目录里面所有文件归档成一个交user.har的归档文件，并把归档后的文件存储到/hdfs/user/output路径下
bin/hadoop archive -archiveName user.har -p /user /hdfs/user/output
//3.查看归档
hadoop fs -lsr /hdfs/user/output/user.har
//解归档文件
hadoop fs -cp har:///hdfs/user/output/user.har/* /hdfs/user
回收站
删除文件存在存活时间设置： core-site.xml中 fs.trash.interval = 1 （单位分钟）
若有收获，就点个赞吧
0 人点赞
