转载

HDFS

最近看了The Hadoop Distributed File System,2010年发表的一篇关于HDFS的论文

里面详细介绍了HDFS的各个方面,虽然里面有些技术已经被淘汰或者革新了,但是里面的

设计思想还值得学习的,所以写下这篇笔记。

技术有限,可能会有差错,希望指出。

  • NameNode, DataNode

    文件和目录是以block的形式,存储在HDFS中的。为了实现数据的容错,HDFS中都至少保存每个

    block的一个副本(用户可以通过改变复制因子,来改变每个block的副本数量)

    hadoop集群中,只有一个NameNode,可以有许多DataNode。

    DataNode,顾名思义,是用来保存文件块(file block)的。

    而NameNode,维护一个namespace tree,表示文件和目录的层次结构,包含文件和目录的访问权限,

    修改和访问的时间,还有同时NameNode也记录每个文件块的具体位置(具体存在于那个DataNode)

    以上这些数据都保存在内存中,可想而知,NameNode需要比普通的DataNode更大的内存。

    block report

    你可能好奇为什么NameNode知道文件块,具体在那个DataNode.

    DataNode会定期发送一个block report,里面每一个块的块id,形成戳,块长等信息

    心跳机制(heartbeats)

    DataNode同时会发送一个“心跳”给NameNode,以告诉NameNode,其存储的文件块可用。

    一般默认的心跳间隔是5秒钟,如果NameNode在10分钟之内没有收到DataNode发来的心跳

    其就认为DataNode已经“死亡”,其存储的文件块被标记为不可用状态。

  • HDFS namespace中的核心数据结构 FsImage, EditLog

    • FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据

    • 操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作

    • FsImage文件没有记录块存储在哪个数据节点。而是由名称节点把这些映射保留在
      内存中,当数据节点加入HDFS集群时,数据节点会把自己所包含的块列表告知给名
      称节点,此后会定期执行这种告知操作,以确保名称节点的块映射是最新的

    • 系统运行一段时间后,editlog可能过大,造成每一次NameNode启动时间变长

      为了解决这个问题,设计了SecondaryNameNode

      1. SecondaryNameNode会定期和NameNode通信,请求其停止使用EditLog文件,暂时将

        新的写操作写到一个新的文件edit.new上来

      2. SecondaryNameNode通过HTTP GET方式从NameNode上获取FsImage和EditLog文件

      3. SecondaryNameNode将获取到的FsImage和EditLog文件载入内存,然后一条条执行

        EditLog文件中的各项操作,使得内存中的FsImage更新到最新。以上过程可以称为

        FsImage和EditLog合并

      4. SecondaryNameNode将新的FsImage发送到NameNode节点

      5. NameNode节点用新的FsImage替换旧的FsImage,edit.new替换EditLog

  • HDFS中文件块

    文件块的读写

    当加入了一个新文件块的时候,HDFS Client首先会询问NameNode,NameNode会给出

    放置块副本的DataNode列表,以及相应的最优顺序。然后HDFS Client会和相应DataNode

    建立的数据流通道(pipeline),传送block数据,如下图所示。

    数据传输的过程使用的是TCP协议,具体的流传输过程如下图所示。其中DN0,DN1,DN2分别

    代表三个DataNode(一般复制因子为3,3个副本)

    ?

    读文件块非常简单,client询问NameNode包含文件块的DataNode,client选择最近的DataNode,

    进行读取文件块。

    文件块的管理

    hadoop集群中的节点的拓扑结构一般如下

    一个机架(rack),包含多台机器,多个机架组成一个集群。

    块副本的放置策略可以总结为以下两点

    • 一个DataNode不能包含超过一个块副本
    • 一个机架内不能包含超过两个的块副本(机架足够的话)

    可能块副本数量可能会出现两种情况,1:其超过复制因子 2:其少于复制因子

    超过复制因子,就减少块的数量就可以,在减少文件块的时候,需要遵循两个基本

    原则,1.不能减少存储块副本的机架数量。2 尽量减少存储在存储空间少的DataNode的文件块

    少于复制因子,就增加块的数量。文件块放置策略跟上面总结的两点相似。

  • 其他

    DataNode退役(Decommissioing)

    一旦DataNode被指定退役,新的文件块就能不能放置于此,但HDFS client还可以从中读取

    文件块。同时NameNode开始将存储在这个DataNode的文件块转移到其他DataNode中。一旦

    NameNode检测到存储的所有文件块转移完毕,这个DataNode正式进入退役状态。其存储的

    文件块被标记为不可用。

    image, checkpoint, journal, backupnode

    image, checkpoint, journal, backupnode,这些概念都是跟NameNode的恢复有关的概念

    HDFS为什么喜欢大文件

    论文中反复提了一点,建议用户使用大文件。那为什么HDFS偏向于大文件

    • NameNode,维护一个namespace tree,表示文件和目录的层次结构,包含文件和目录的访问权限,

      修改和访问的时间,还有同时NameNode也记录每个文件块的具体位置,如果小文件过多会占用

      较多的NameNode内存。

    • 文件过小,寻道时间大于数据读写时间,这不符合HDFS的设计

      HDFS为了使数据的传输速度和硬盘的传输速度接近,则设计将寻道时间(Seek)相对最小化,将block的大小设置的比较大,这样读写数据块的时间将远大于寻道时间,接近于硬盘的传输速度。


    引用

    https://blog.csdn.net/wenxindiaolong061/article/details/79880290

    林子雨 大数据技术原理与应用

    Shvachko K, Kuang H, Radia S, Chansler R. The hadoop distributed file system. In2010 IEEE 26th symposium on mass storage systems and technologies (MSST) 2010 May 3 (pp. 1-10). Ieee.

正文到此结束
本文目录