分布式文件存储系统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文件存储的路径

<property>
        <!-- 实际工作当中，这个路径不能随便写，需要首先确定我们的磁盘的挂载路径
                df  -lh   查看我们磁盘的挂载路径
        -->
        <name>dfs.namenode.name.dir</name>
        <value>file:///namenodeDatas</value>
</property>

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

<property>
      <name>dfs.namenode.edits.dir</name>
       <value>file:///hadoopDatas/dfs/nn/edits</value>
</property>

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文件 归档文件