【作者主页】Francek Chen【专栏介绍】⌈ ⌈⌈大数据技术原理与应用⌋ ⌋⌋专栏系统介绍大数据的相关知识分为大数据基础篇、大数据存储与管理篇、大数据处理与分析篇、大数据应用篇。内容包含大数据概述、大数据处理架构Hadoop、分布式文件系统HDFS、分布式数据库HBase、NoSQL数据库、云数据库、MapReduce、Hadoop再探讨、数据仓库Hive、Spark、流计算、Flink、图计算、数据可视化以及大数据在互联网领域、生物医学领域的应用和大数据的其他应用。【GitCode】专栏资源保存在我的GitCode仓库https://gitcode.com/Morse_Chen/BigData_principle_application。文章目录一、块二、名称节点和数据节点三、第二名称节点小结本文介绍 HDFS 中的相关概念包括块、名称节点和数据节点、第二名称节点。一、块在传统的文件系统中为了提高磁盘读写效率一般以数据块为单位而不是以字节为单位。比如机械式硬盘磁盘的一种包含了磁头和转动部件在读取数据时有一个寻道的过程通过转动盘片和移动磁头的位置找到数据在机械式硬盘中的存储位置才能进行读写。在 I/O 开销中机械式硬盘的寻址时间是最耗时的部分一旦找到第一条记录剩下的顺序读取效率是非常高的。因此以块为单位读写数据可以把磁盘寻道时间分摊到大量数据中。HDFS 也同样采用了块的概念默认的一个块大小是 64 MB。在 HDFS 中的文件会被拆分成多个块每个块作为独立的单元进行存储。我们所熟悉的普通文件系统的块一般只有几千字节可以看出HDFS 在块的大小的设计上明显要大于普通文件系统。HDFS 这么做是为了最小化寻址开销。HDFS 寻址开销不仅包括磁盘寻道开销还包括数据块的定位开销。当客户端需要访问一个文件时首先从名称节点获得组成这个文件的数据块的位置列表然后根据位置列表获取实际存储各个数据块的数据节点的位置最后数据节点根据数据块信息在本地 Linux 文件系统中找到对应的文件并把数据返回给客户端。设计一个比较大的块可以把上述寻址开销分摊到较多的数据中降低了单位数据的寻址开销。因此HDFS 在文件块大小设置上要远远大于普通文件系统以期在处理大规模文件时能够获得更好的性能。当然块的大小也不宜设置过大因为通常 MapReduce 中的 Map 任务一次只处理一个块中的数据如果启动的任务太少就会降低作业并行处理速度。HDFS 采用抽象的块概念可以带来以下几个明显的好处。支持大规模文件存储。文件以块为单位进行存储一个大规模文件可以被拆分成若干个文件块不同的文件块可以被分发到不同的节点上因此一个文件的大小不会受到单个节点的存储容量的限制可以远远大于网络中任意节点的存储容量。简化系统设计。首先HDFS 采用块概念大大简化了存储管理因为文件块大小是固定的这样就可以很容易计算出一个节点可以存储多少文件块其次这方便了元数据的管理元数据不需要和文件块一起存储可以由其他系统负责管理元数据。适合数据备份。每个文件块都可以冗余存储到多个节点上大大提高了系统的容错性和可用性。二、名称节点和数据节点在 HDFS 中名称节点负责管理分布式文件系统的命名空间Namespace保存了两个核心的数据结构见图1即 FsImage 和 EditLog。FsImage 用于维护文件系统树以及文件树中所有的文件和文件夹的元数据操作日志文件 EditLog 中记录了所有针对文件的创建、删除、重命名等操作。名称节点记录了每个文件中各个块所在的数据节点的位置信息但是并不持久化地存储这些信息而是在系统每次启动时扫描所有数据节点并重构得到这些信息。名称节点在启动时会将 FsImage 的内容加载到内存当中然后执行 EditLog 文件中的各项操作使内存中的元数据保持最新。这个操作完成以后就会创建一个新的 FsImage 文件和一个空的 EditLog 文件。名称节点启动成功并进入正常运行状态以后HDFS 中的更新操作都会被写入 EditLog而不是直接被写入 FsImage。这是因为对于分布式文件系统而言FsImage 文件通常都很庞大一般都是 GB 级别以上如果所有的更新操作都直接在 FsImage 文件中进行那么系统的运行速度会变得非常缓慢。相对而言EditLog 通常都要远远小于 FsImage更新操作写入EditLog 是非常高效的。名称节点在启动的过程中处于“安全模式”只能对外提供读操作无法提供写操作。启动过程结束后系统就会退出安全模式进入正常运行状态对外提供读写操作。图1 名称节点的数据结构数据节点DataNode是分布式文件系统 HDFS 的工作节点负责数据的存储和读取会根据客户端或者名称节点的调度来进行数据的存储和检索并且向名称节点定期发送自己所存储的块的列表信息。每个数据节点中的数据会被保存在各自节点的本地 Linux 文件系统中。三、第二名称节点在名称节点运行期间HDFS 会不断产生更新操作这些更新操作直接被写入 EditLog 文件因此 EditLog 文件也会逐渐变大。在名称节点运行期间不断变大的 EditLog 文件通常对于系统性能不会产生显著影响但是当名称节点重启时需要将 FsImage 加载到内存中然后逐条执行 EditLog 中的记录使 FsImage 保持最新。可想而知如果 EditLog 很大就会导致整个过程变得非常缓慢使名称节点在启动过程中长期处于“安全模式”无法正常对外提供写操作影响用户的使用。为了有效解决 EditLog 逐渐变大带来的问题HDFS 在设计中采用了第二名称节点Secondary NameNode。第二名称节点是 HDFS 架构的一个重要组成部分具有两个方面的功能首先它可以完成 EditLog 与 FsImage 的合并操作减小 EditLog 文件大小缩短名称节点重启时间其次它可以作为名称节点的“检查点”保存名称节点中的元数据信息。具体如下。EditLog 与 FsImage 的合并操作。每隔一段时间第二名称节点会和名称节点通信请求其停止使用 EditLog 文件这里假设这个时刻为t 1 t_1t1如图2所示暂时将新到达的写操作添加到一个新的文件 EditLog.new 中。然后第二名称节点把名称节点中的 FsImage 文件和 EditLog 文件拉回本地再加载到内存中对二者执行合并操作即在内存中逐条执行 EditLog 中的操作使 FsImage 保持最新。合并结束后第二名称节点会把合并后得到的最新的 FsImage.ckpt 文件发送到名称节点。名称节点收到后会用最新的 FsImage.ckpt 文件去替换旧的 FsImage 文件同时用 EditLog.new 文件去替换 EditLog 文件这里假设这个时刻为t 2 t_2t2从而减小了 EditLog 文件的大小。作为名称节点的“检查点”。从上面的合并过程可以看出第二名称节点会定期和名称节点通信从名称节点获取 FsImage 文件和 EditLog 文件执行合并操作得到新的 FsImage.ckpt 文件。从这个角度来讲第二名称节点相当于为名称节点设置了一个“检查点”周期性地备份名称节点中的元数据信息当名称节点发生故障时就可以用第二名称节点中记录的元数据信息进行系统恢复。但是在第二名称节点上合并操作得到的新的 FsImage 文件是合并操作发生时即t 1 t_1t1时刻HDFS 记录的元数据信息并没有包含t 1 t_1t1时刻和t 2 t_2t2时刻期间发生的更新操作。如果名称节点在t 1 t_1t1时刻和t 2 t_2t2时刻期间发生故障系统就会丢失部分元数据信息在 HDFS 的设计中也并不支持把系统直接切换到第二名称节点。因此从这个角度来讲第二名称节点只是起到了名称节点的“检查点”作用并不能起到“热备份”作用。即使有了第二名称节点的存在当名称节点发生故障时系统还是有可能会丢失部分元数据信息的。图2 第二名称节点工作过程示意小结HDFS 以块为单位存储文件默认块大小 64MB远大于普通文件系统以最小化寻址开销支持大规模文件存储简化系统设计方便数据备份。名称节点管理命名空间保存 FsImage 和 EditLog。数据节点负责数据存储和读取。第二名称节点负责合并 EditLog 与 FsImage减小文件大小缩短名称节点重启时间并作为名称节点的“检查点”备份元数据但不能“热备份”名称节点故障时系统仍可能丢失部分元数据。欢迎点赞 | 收藏⭐ | 评论✍ | 关注