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

11次阅读

共计 3704 个字符,预计需要花费 10 分钟才能阅读完成。

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 景象的产生
正文完
 0