根本介绍

组成

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