HDFS（Hadoop Distributed File System）分布式文件存储系统，次要为各类分布式计算框架如Spark、MapReduce等提供海量数据存储服务，同时HBase、Hive底层存储也依赖于HDFS。HDFS提供一个对立的形象目录树，客户端可通过门路来拜访文件。HDFS集群分为两大角色：Namenode、Datanode（非HA模式会存在Secondary Namenode）
Namenode
Namenode是HDFS集群主节点，负责管理整个文件系统的元数据，所有的读写申请都要通过Namenode。
元数据管理
Namenode对元数据的治理采纳了三种模式：
1) 内存元数据：基于内存存储元数据，元数据比拟残缺
2) fsimage文件：磁盘元数据镜像文件，在NameNode工作目录中，它不蕴含block所在的Datanode 信息
3) edits文件：数据操作日志文件，用于连接内存元数据和fsimage之间的操作日志，可通过日志运算出元数据
fsimage + edits = 内存元数据
留神：当客户端对hdfs中的文件进行新增或批改时，操作记录首先被记入edit日志文件，当客户端操作胜利后，相应的元数据会更新到内存元数据中

能够通过hdfs的一个工具来查看edits中的信息
bin/hdfs oev -i edits -o edits.xml
查看fsimage
bin/hdfs oiv -i fsimage_0000000000000000087 -p XML -o fsimage.xml

元数据的checkpoint（非HA模式）
Secondary Namenode每隔一段时间会查看Namenode上的fsimage和edits文件是否须要合并，如触发设置的条件就开始下载最新的fsimage和所有的edits文件到本地，并加载到内存中进行合并，而后将合并之后取得的新的fsimage上传到Namenode。checkpoint操作的触发条件次要配置参数：

dfs.namenode.checkpoint.check.period=60 #查看触发条件是否满足的频率，单位秒
dfs.namenode.checkpoint.dir=file://${hadoop.tmp.dir}/dfs/namesecondary
dfs.namenode.checkpoint.edits.dir=${dfs.namenode.checkpoint.dir}

以上两个参数做checkpoint操作时，secondary namenode的本地工作目录，次要解决fsimage和edits文件的

dfs.namenode.checkpoint.max-retries=3 #最大重试次数
dfs.namenode.checkpoint.period=3600 #两次checkpoint之间的工夫距离3600秒
dfs.namenode.checkpoint.txns=1000000 #两次checkpoint之间最大的操作记录

checkpoint作用

  1. 放慢Namenode启动
    Namenode启动时，会合并磁盘上的fsimage文件和edits文件，失去残缺的元数据信息，但如果fsimage和edits文件十分大，这个合并过程就会十分慢，导致HDFS长时间处于平安模式中而无奈失常提供服务。SecondaryNamenode的checkpoint机制能够缓解这一问题
  2. 数据恢复
    Namenode和SecondaryNamenode的工作目录存储构造完全相同，当Namenode故障退出须要从新复原时，能够从SecondaryNamenode的工作目录中将fsimage拷贝到Namenode的工作目录，以复原Namenode的元数据。然而SecondaryNamenode最初一次合并之后的更新操作的元数据将会失落，最好Namenode元数据的文件夹放在多个磁盘下面进行冗余，升高数据失落的可能性。
    注意事项：
  3. SecondaryNamenode只有在第一次进行元数据合并时须要从Namenode下载fsimage到本地。SecondaryNamenode在第一次元数据合并实现并上传到Namenode后，所持有的fsimage已是最新的fsimage，无需再从Namenode处获取，而只须要获取edits文件即可。
  4. SecondaryNamenode从Namenode上将要合并的edits和fsimage拷贝到本人以后服务器上，而后将fsimage和edits反序列化到SecondaryNamenode的内存中，进行计算合并。因而个别须要把Namenode和SecondaryNamenode别离部署到不同的机器下面，且SecondaryNamenode服务器配置要求个别不低于Namenode。
  5. SecondaryNamenode不是充当Namenode的“备服务器”，它的次要作用是进行元数据的checkpoint
    Datanode
    Datanode作为HDFS集群从节点，大数据培训负责存储管理用户的文件块数据，并定期向Namenode汇报本身所持有的block信息（这点很重要，因为，当集群中产生某些block正本生效时，集群如何复原block初始正本数量的问题）。
    对于Datanode两个重要的参数：
  6. 通过心跳信息上报参数

<property>
<name>dfs.blockreport.intervalMsec</name>
<value>3600000</value>
<description>Determines block reporting interval in milliseconds.</description>
</property>

  1. Datanode掉线判断时限参数
    Datanode过程死亡或者网络故障造成Datanode无奈与Namenode通信时，Namenode不会立刻把该Datanode断定为死亡，要通过一段时间，这段时间称作超时时长。HDFS默认的超时时长为10分钟30秒。如果定义超时工夫为timeout，则超时时长的计算公式为：
    timeout = 2 heartbeat.recheck.interval（默认5分钟） + 10 dfs.heartbeat.interval（默认3秒）。
    <property>
    <name>heartbeat.recheck.interval</name>

    单位毫秒

    <value>2000</value>
    </property>
    <property>
    <name>dfs.heartbeat.interval</name>

    单位秒

    <value>1</value>
    </property>

HDFS读写数据流程
理解了Namenode和Datanode的作用后，就很容易了解HDFS读写数据流程，这个也是面试中常常问的问题。
HDFS写数据流程

留神：
1.文件block块切分和上传是在客户端进行的操作
2.Datanode之间自身是建设了一个RPC通信建设pipeline
3.客户端先从磁盘读取数据放到一个本地内存缓存，开始往Datanode1上传第一个block，以packet为单位，Datanode1收到一个packet就会传给Datanode2，Datanode2传给Datanode3；Datanode1每传一个packet会放入一个应答队列期待应答
4.当一个block传输实现之后，客户端会告诉Namenode存储块结束，Namenode将元数据同步到内存中

  1. Datanode之间pipeline传输文件时，个别依照就近可用准则
    a) 首先就近筛选一台机器
    b) 优先选择另一个机架上的Datanode
    c) 在本机架上再随机筛选一台
    HDFS读数据流程

    留神：
  2. Datanode发送数据，是从磁盘外面读取数据放入流，以packet为单位来做校验
  3. 客户端以packet为单位接管，先在本地缓存，而后写入指标文件
    客户端将要读取的文件门路发送给namenode，namenode获取文件的元信息（次要是block的寄存地位信息）返回给客户端，客户端依据返回的信息找到相应datanode一一获取文件的block并在客户端本地进行数据追加合并从而取得整个文件
    HDFSHA机制
    HA：高可用，通过双Namenode打消单点故障。

    双Namenode协调工作的要点：
  4. 元数据管理形式须要扭转
    a) 内存中各自保留一份元数据
    b) edits日志只能有一份，只有active状态的Namenode节点能够做写操作
    c) 两个Namenode都能够读取edits
    d) 共享的edits放在一个共享存储中治理（qjournal和NFS两个支流实现，图中以放在一个共享存储中治理（qjournal和为例）
  5. 须要一个状态治理功能模块
    a) 实现了一个zk failover，常驻在每一个Namenode所在的节点
    b) 每一个zk failover负责监控本人所在Namenode节点，利用zk进行状态标识，当须要进行状态切换时，由zk failover来负责切换，切换时须要避免brain split景象的产生