分布式文件存储系统hdfs

hdfs基础知识

hadoop当中的文件系统是一个抽象类,里面有很多的子实现类,例如 hdfs,file:///, ftp等文件系统。

  • block块缓存
    hadoop可以将我们的block块缓存到内存当中,我们在执行一些MapReduce计算的时候,可以直接从内存当中获取数据,比较快,特别适用于一些小表join大表的情况。
  • hdfs的权限验证
    采用的是和Linux类似的权限校验机制,防止好人做错事,不能阻止坏人干坏事,hdfs相信你告诉我你是谁,你就是谁。
  • hdfs的元数据信息管理
    hdfs的元数据都在hdfs-site.xml当中的配置
    fsimage:存放的是一份最完整的元数据信息,内容比较大
    edits:元数据操作日志,记录了一段时间的元数据信息的变化,例如增删改查哪些文件,文件内容比较小,操作起来比较方便,edits一直记录元数据操作记录的话,也会慢慢膨胀的比较大,也会造成操作起来比较困难为了控制edits不会膨胀太大,引入secondaryNameNode机制。
    secondaryNameNode:主要职责,合并fsimage与edits,清空edits。
    问题:edits什么时候跟fsimage合并?
    控制策略:时间长短 + 文件大小 (默认大小64M或者到一个小时合并一次)
    dfs.namenode.name.dir:定义了我们fsimage文件存储的路径

        
        dfs.namenode.name.dir
        file:///namenodeDatas

dfs.namenode.edits.dir:定义了我们edits文件存储的路径


      dfs.namenode.edits.dir
       file:///hadoopDatas/dfs/nn/edits

hdfs的文件写入过程

角色:client(客服端),namenode、datanode
第一步:客户端发出请求,请求namneode需要上传写入数据;
第二步:namenode检测客户端是或否有权限上传;
第三步:客户端请求namenode第一个block块上传到哪里去(一个文件会拆分多个block块);
第四步:namenode找三个block块返回给客户端(默认三个replication副本);
第五步:客户端找datanode建立pipeline管道,主备上传数据,数据都是以packet包的形式通过管道上传到datanode上面去;
第六步:datanode保存好了之后,给客户端一个ack确认机制,客户端准备上传下一个block块,直到所有的block块上传完成,关闭文件流;

hdfs当中的小文件的处理

每一个小文件都会有一份元数据信息,元数据信息都保存在namenode的内存当中,如果有大量的小文件,会产生大量的元数据信息,造成namenode的内存压力飙升。实际工作当中,尽量不要造成大量的小文件存储到hdfs上面去,如果有大量的小文件,想办法,合并成大文件。
第一种解决方案:从源头上避免小文件,上传的时候都是一些大文件。如果真的有各种小文件,可以考虑上传的时候能不能合并到一个文件里面去。
第二种解决方案:sequenceFile
第三种解决方案:har文件 归档文件

你可能感兴趣的:(分布式文件存储系统hdfs)