关于hadoop: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 进行元数据的复原，复原回一个小时前的状态