HDFS

HDFS基本概念 是一个文件系统,用于存储文件,通过目录树来定位文件;是分布式的,由多个服务器联合起来实现其功。 适合场景:一次写入,多次读出,不可更改。文件写入后就不需要再改变   HDFS特征 优点
  • 高容错,文件报错多个副本
  • 适合处理大数据,数据规模到GB、TB甚至TP;文件数量多到百万级以上均可处理
  • 可建构廉价机器上
缺点
  • 不适合低延迟数据访问,实时场景不合适
  • 无法高效对大量小文件进行存储(占用大量NN内存来存储目录和块信息,且小文件的寻址时间超过读取时间,违反了HDFS的设计目标)
  • 不支持并发写入、文件随机修改,不允许多线程写入
  • 仅支持数据追加,不允许文件修改 
  组成架构 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是块大小主要取决于磁盘传输的速率,普通机械硬盘一般80~90MB/s,固态200~300MB/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读数据流程   HDFS   节点距离计算 在HDFS写数据的过程中,NN会选择距离上离带上传数据最近的DN接收数据。 节点距离:两个节点到达最近共同祖先的距离总和。 解释:将网络分层,数出节点到达共同祖先的另一节点即可   副本存储节点选择——机架感知 HDFSNameNode和DataNode的工作机制 注意的点: secondary NameNode向NameNode checkpoint时的条件:
  1. 定时时间到
  • 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即每分钟检查一次操作次数
      HDFS   Fsimage和Edits解析   NameNode被格式化之后,将会在$HADOOP_HOME/data/tmp/dfs/name/cirrent目录下产生如下文件 HDFS Fsimage:HDFS文件系统元数据的一个永久性的检查点,包含HDFS文件系统的所有目录和文件inode的序列化信息 Edits:存放HDFS文件系统的所有更新操作,客户端执行的写操作会首先被记录到Edits文件中(追加操作) seen_txid:保存的是一个数字,最后一个edits_的数字  
    • oiv查看Fsimage文件
    语法:hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径
    例子:
    hadoop103:8088hdfs oiv -p XML -i fsimage_0000000000000000025 -o /opt/module/hadoop-3.1.3/fsimage.xml
    cat /opt/module/hadoop-3.1.3/fsimage.xml
    fsimage.xml文件中,记录了HDFS中的文件树,并使用inode来作为元数据中的目录管理节点,与文件一一对应。  
    • oev查看Edits
    语法:hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径
    例子:
    hdfs oev -p XML -i edits_inprogress_0000000000000000289 -o /opt/software/edits.xml
    cat /opt/module/hadoop-3.1.3/edits.xml
    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=2*dfs.namenode.heartbeat.recheck-interval + 10*dfs.heartbeat.interval)NN仍未收到DN的的心跳信号,NN则认为该DN不可用,即不再使用该节点读写数据
      HDFS数据完整性校验 原始数据封装后在末尾添加CRC校验位,HDFS接收数据后重新CRC计算与传输过来的校验位比较看是否一致                    
    上一篇:python基础练习题(题目 求输入数字的平方,如果平方运算后小于 50 则退出)


    下一篇:一文介绍备机重建各种方法的实现机制