乐趣区

关于hdfs:大数据开发之HDFS分布式文件存储系统详解

jiezi

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 景象的产生
退出移动版