hdfs分布式文件系统

基本介绍

组成

• Client

  • 分块后存储
  • 与namenode交互获取文件的位置信息
  • 与DataNode交互，读取或者写入数据
  • Client提供一些命令来管理和访问HDFS

• NameNode:就是一个master，它是一个主管

  • 管理HDFS的名称空间
  • 管理数据块block的映射信息，但并不持久化，太大了
  • 配置副本策略
  • 处理客户端读写请求

• DataNode:执行namenode的指令

  • 存储实际数据块
  • 执行数据块的读写操作

• snn

  • 辅助nn
  • 定期合并fsimage和fsedits,推送给nn
  • 紧急情况下可以恢复nn为一个小时前数据
• 解决海量存储问题，跨机器存储，统一管理分布在集群上的文件系统称分布式文件系统
• 适合存储大型数据，提供统一的访问接口，能够像普通文件系统那样操作

• 分布式存储方案

  • 将大文件拆分成多块分别放到不同服务器中
• 不管文件多大一律分块存储，每个块128M，每个块都有一个副本，默认每个块的副本为3
• 元数据是存储在namenode内存中，磁盘中有元数据的备份

• 设计目标

  • 硬件故障处理：检测和快速恢复是核心
  • 流式读取数据：适合做批量处理，而不是交互式，注重数据访问高吞吐量
  • 文件大小应尽量大，小文件元数据占用内存
  • 移动计算(在hdfs中计算)的代价比移动数据(把数据拉到本地)的代价低

• 应用场景

  • gb,tb,pb基本以上的数据存储，批量高吞吐
  • 一次写入多次读取，没有修改必要，hdfs不支持随机修改文件数据，如历史已经发展的事实(天气)
  • 可运行于普通廉价机器
  • 高容错性
  • 具备扩展能力

• 不适用场景

  • 随机修改场景、
  • 交互式强的场景
  • 存储大量小文件场景

架构

• 心跳机制：datanode和namenode之间保持的心跳机制，datanode每隔3秒向namenode发送一次心跳包hdfs-default.xml中配置，证明自己还活着，当datanode在一定时间内没发送心跳，等待10次，默认配置30秒未收到心跳，namenode会认定其为假死，由namenode主动每隔5秒向datanode发送一次检查，两次检查仍然没收到则认定为宕机。按默认配置共630断定datanode死亡。除此之外，datanode每隔六小时还会向namenode汇报自己的块信息

<property>
  <name>dfs.heartbeat.interval</name>
//  <value>3</value>
  <description>Determines datanode heartbeat interval in seconds.</description>
</property>

<property>
  <name>dfs.namenode.heartbeat.recheck-interval</name>
  <value>300000</value>
  <description>
    This time decides the interval to check for expired datanodes.
    With this value and dfs.heartbeat.interval, the interval of
    deciding the datanode is stale or not is also calculated.
    The unit of this configuration is millisecond.
  </description>
</property>

• 负载均衡：namenode要保证每个datanode上的块的数量大致相当

start-balancer.sh -t 10% 

• 副本机制：默认每个块3个副本，当发现某些块副本不足3个，会让指定节点创建副本，保证副本为3个，如果副本数据多于3个，会让指定的节点将多余副本删除。如果无法处理副本(挂了一大半机子)，此时namenode会让hdfs进行安全模式，不许写入。 每一次刚启动hdfs默认都会先进入安全模式，各个datanode向namenode汇报块信息，namenode检测数据完整，退出安全模式

  • 注意事项

    • 存储时块大小按128m，但分块后小于128m时按实际大小存

• 副本存储(机架感知)

      - 第一个副本存储在离客户端最近的机架上任意一台机器上，如果相等，随机找一个机架
      - 第二个副本存储选择与第一个不同的机架服务器
      - 第三个副本：与第二个副本同机架不同服务器上

hdfs操作

• hdfs dfs -put localpath hdfspath 上传到hdfs
• hdfs dfs -moveFromLocal localpath hdfspath 从本地移动到hdfs中
• hdfs dfs -get hdfspath localpath 从hdfs下载到本地
• hdfs dfs -getmerge hdfspath1 hdfspath2 localpath 从hdfs下载并合并到本地
• hdfs dfs -rm [-r -f -skipTrash] xx 数据移动到垃圾桶，有存储时间
• hdfs dfs -du [-h] 文件
• hdfs dfs -chown [-R] 所属用户:所属用户组 文件
• hdfs dfs -appendToFile srcLocalFilePath hdfsFilePath 追加文件

hdfs高级shell

• hdfs dfs -safemode get/enter/leave

  • 补充安全模式:hadoop的一种保护机制，此时会检查数据的完整性，默认副本率为0.999，超过datanode也会删掉多余的副本，只接受读请求，确认安全之后会自动退出，至少为30秒
  • 如果有缺失块且hdfs不能主动退出安全模式，手动离开安全模式，才可以删除，1.文件不重要跳过回收站全部干掉；2.如果文件数据重要，将文件下载到本地磁盘，将hdfs对应的文件跳过回收站删除，再重新上传
• 基准测试，测试刚搭建好的hdfs集群整体吞吐量，取大值，多次不同参数测试取平均

hadoop jar /export/server/hadoop-2.7.5/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-2.7.5.jar TestDFSIO -write -nrFiles 10 -fileSize 10MB

hdfs原理

namenode存储元数据流程

• 保存整个系统的名称空间和数据的地址映射，因此整个系统的存储容量受限于namenode的内存大小

• namenode记录元数据信息时，先记到edits再记录到内存空间，二者成功后才算真正成功

  • edits文件太大达到64m大小就被关闭，开启一个新的edits
  • edits一个小时后也要开启一个新的
  • 重启也会开启一个新的edits
  • edits都是小文件，不宜过多，需要将他们合并，形成的文件就是fsimage,随着不断合并，这个文件会越来越大，接近于内存大小
  • fsimage是一个保存相对完整的一个元数据，hdfs刚刚启动时先加载fsimage文件中的数据到内存中，然后加载edits文件到内存，此时就将所有元数据恢复到内存中
  • secondarynamenode:辅助namenode合并edits到fsimage
• namenode文件操作数据流不经过namenode，会告知处理的datanode
• namenode根据全局情况作出防止副本的决定
• 心跳机制和状态报告，均衡见上述架构内容

hdfs读写流程

• 写

• 读

snn （secondarynamenode）

首先要理解fsimage和edits文件的作用
edits：存放操作日志，
fsimage:合并edits生成，并且就是由snn完成

• edits超过64m,snn提醒namenode创建新edits
• 每隔一小时新建一个
• 重启时新建
• 特殊情况下可以用snn进行元数据的恢复，恢复回一个小时前的状态