Hadoop之详解HDFS架构

Posted 侦查一线

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Hadoop之详解HDFS架构相关的知识,希望对你有一定的参考价值。

Hadoop包含三大基本组件:

  • HDFS——分布式文件系统,用于数据存储

  • YARN——统一资源管理和调度系统,用于管理集群的计算资源并根据计算框架的需求进行调度,支持包含MapReduce、Spark、Flink等多种计算框架。MRv2(Hadoop 2.x)之后的新特性。

  • MapReduce——分布式计算框架,运行于YARN之上

    Hadoop之详解HDFS架构

这篇文章主要是对Hadoop三大基本组件之一的HDFS进行深入的学习。


一、HDFS概述

1.1 HDFS产生背景

随着数据量越来越大,在一一个操作系统存不下所有的数据,那么就分配到更多的操作系统管理的磁盘中,但是不方便管理和维护,迫切需要一种系统来管理多台机器上的文件,这就是分布式文件管理系统。HDFS只是分布式文件管理系统中的一种。


1.2 HDFS定义


HDFS(Hadoop Distributed File System):是Hadoop的分布式文件系统的实现。它的设计目标是存储海量的数据,并为分布在网络中的大量客户端提供数据访问。
HDFS是高容错性的,可以部署在低成本的硬件之上,HDFS提供高吞吐量地对应用程序数据访问。
HDFS的使用场景:适合一次写入,多次读出的场景,且不支持文件的修改。适合用来做数据分析,并不适合用来做网盘应用。

1.1 HDFS特性

  1. 能够保存PB级的数据量,将数据散布在大量的计算机(节点)上,支持更大的文件。

  2. 使用数据备份的方法解决文件存储的可靠性,如果集群中单个节点故障则启用备份。

  3. 很好的与Map-Reduce集成,为减小计算时的数据交互,HDFS允许数据在本地计算。

1.2 HDFS局限性

  • 针对高速流式读取进行优化,查询性能低下(可利用Hive查询)

  • 一次写入多次读取,不支持并发写入,并发读取性能很高

  • 不支持文件修改

  • 不支持缓存,每次读取文件须从硬盘上重新读取,当然对于大文件顺序读取性能影响不大

  • 不适合存储小文件


二、HDFS架构思路解析

2.1 HDFS架构思路解析1

HDFS是一种分布式文件系统,将文件存储到不同的计算机节点中。如何将文件保存到不同节点中?

Hadoop之详解HDFS架构
HDFS是基于何种思路来设计目前的架构?

2.2 HDFS架构思路解析2

  • 将文件保存在不同的节点(Node)中:
    Hadoop之详解HDFS架构

  • 问题: 可靠性差,节点损坏会导致节点内数据丢失。

  • 解决方案,将一份数据备份到多个节点。
    Hadoop之详解HDFS架构
    采用这种方法存在以下两种优点:
    1、可靠性高,一个节点坏掉,启用备份
    2、读取速度快,同一份数据多个备份同时读
    那又存在什么局限性呢?
    大文件保存和读取困难(如:单个100G文件)。

2.3 HDFS架构思路解析3

  • 解决方案: 将所有文件以固定大小分割为块(Block),节点只保存固定大小的块。
    Hadoop之详解HDFS架构

2.4 HDFS架构思路解析4

  • 在思路解析3中还存在数据读取的问题

  1. 如何知道系统中有哪些文件?
    节点中只存储了文件的Block,文件的原始信息丢失

  2. 如何知道某个原始文件的Block对应于哪些节点?
    逐个节点去查找?
    还是建立一个管理节点,专门来管理各个节点的信息?

最终解决方案:

  • 存储数据时,将文件的原始信息,以及对应的Block信息存储到“管理节点”中保存。

  • 读取数据时,先查询原始文件记录和对应的Block信息就知道本系统有哪些原始文件,这些文件有哪些Block,以及这些Block存储在哪些节点中。

二、HDFS组成架构

主从模式

  • 整个Hadoop被构建在集群上,集群由各个节点(Node)构成。

  • 将集群中的节点分为NameNode(管理者)和DataNode(工作者)。

文件被拆分为多个Block(块)放到不同的DataNode中,在HDFS 1.x 中每个块默认大小为64MB,HDFS 2.x 中每个块默认大小为128MB,同一个块会备份到多个DataNode中存储。

2.1 HDFS组成架构介绍

HDFS组成架构如下所示:
Hadoop之详解HDFS架构

  1. NameNode(nn):也就是Master,它是一个主管、管理者。使用NameNode存储元数据信息,保存文件名以及文件的块(Block)存储在哪些DataNode中。每个存活的DataNode定时向NameNode发送心跳信息,如果未收到DataNode的心跳,NameNode将认定其已失效,不再向其派发任何文件读请求。NameNode会将失效的DataNode中的块(Block)备份到其他存活的DataNode中。简单来说就是:
    (1)管理HDFS的名称空间;
    (2)配置副本策略;
    (3)管理数据块(Block) 映射信息;
    (4)处理客户端读写请求。

  2. DataNode:就是Slave,NameNode下达命令,DataNode执行实际操作。
    (1)存储实际的数据块
    (2)执行数据块的读/写操作

  3. Client:就是客户端。
    (1)文件切分。文件上传HDFS的时候, Client将文件切分成一 个个的Block, 然后进行上传
    (2)与NameNode交互,获取文件的位置信息
    (3)与DataNode交互,读取或者写入数据
    (4)Client提供一 些命 令来管理HDFS,比如NameNode格式化
    (5)Client可以通过一些命令来访问HDFS,比如对HDFS增删查改操作

  4. Secondany NameNode:并非NameNode的热备。当NameNode挂掉的时候, 它并不能马上替换NameNode并提供服务。
    (1)辅助NameNode,分担其工作量,比如定期台并fsimage和edits,并推送给NameNode ;
    (2)在紧急情况下,可辅助恢复NameNode。

2.2 Namenode的元数据管理机制

整个系统的元数据都保存在NameNode中

  • 内存元数据:meta data,用于元数据查询

  • 硬盘元数据镜像文件:fsimage,持久化存储元数据

  • 数据操作日志:edits,HDFS文件增删会造成元数据更改,将更改记录到edits,可运算出元数据

NameNode元数据管理过程

  1. 系统启动时,读取fsimage和edits至内存,形成内存元数据meta data。

  2. client向NameNode发起数据增删查请求

  3. NameNode接收到请求后,在内存元数据中执行增删查操作,并向client返回操作结果。

  4. 如果是增删操作,则同时记录数据操作日志edits。

  5. 使用Secondary NameNode,在适当的时机将操作日志合并到fsimage中(CheckPoint过程)

2.3 三个问题

为什么块的大小不能设置太小,也不能设置太大?

  1. HDFS的块设置太小,会增加寻址时间,程序一直在找块的开始位置;

  2. 如果块设置的太大,从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。导致程序在处理这块数据时,会非常慢。
    总结: HDFS块的大小设置主要取决于磁盘传输速率。

为什么文件操作不直接写入fsimage,而要写入单独的edits文件?

  1. fsimage记录了整个大数据系统的元数据,非常庞大

  2. fsimage是一个流式的文本文件,新增记录只需在文件末尾新增数据,速度快;删除记录时,需要删除文件中间的某些记录,文件越大执行效率越低

  3. edits文件一般很小,通常超过64mb就会被执行合并,批量合并的操作效率比频繁修改高多了

为什么要使用Secondary NameNode合并操作日志?

  1. 提高性能:NameNode是唯一面向Client的管理节点,承受Client的并发访问,性能非常重要,而合并edits和fsimage需要较大计算量

  2. 提高可靠性:Secondary NameNode在合并edits 和fsimage时,会做数据备份,如果NameNode中的fsimage丢失,可从Secondary NameNode恢复

2.4 Checkpoint过程

Hadoop之详解HDFS架构

  1. SN(Secondary NameNode)向NameNode(NN)发起询问,是否需要checkpoint

  2. NN读取fstime中的上次checkpoint时间,结合edits文件大小等因素,决定开始checkpoint

  3. NN新建一个edits文件(如:edits.new),让新操作写入到edits.new中(避免在checkpoint过程中,edits发生改变)

  4. SN向NN请求(http协议)获取fsimage和edits文件

  5. SN将edits与fsimage合并,生成新的fsimage.checkpoint文件

  6. SN将fsimage.checkpoint发送给NN

  7. NN收到fsimage.checkpoint后,将其与旧的fsimage替换,更新fstime文件记录本次checkpoint操作

2.5 NameNode单点故障恢复

NameNode单点故障会导致整个Hadoop崩溃

  1. 利用SN(Secondary NameNode)的备份恢复NN (NameNode)元数据
    SN与NN并不是时刻同步的,checkpoint有时间间隔,这会导致恢复后有数据丢失

  2. NFS方案(NFS灾备),对NN中元数据进行即时备份,避免元数据丢失
    NSF(Network File System,网络文件系统)可与网络中的主机相互传输文件
    NN可配置NFS灾备服务器,在写入fsimage、fstime、edits、edits.new等文件时,同步写入到NSF服务器中,进而避免NN数据丢失

HDFS高可用性

  • 允许配置两个相同的NameNode一个为active mode处于活动模式,另一个为standby mode处于待机模式

  • 两个NameNode数据保持一致,一旦活动节点失效,则由待机节点切换为活动节点,保证Hadoop的正常运行

  • 两个NameNode的共享同一个NFS以进行数据同步

三、HDFS数据写入机制

Hadoop之详解HDFS架构
0:NameNode需要通过心跳机制收集DataNode的生存状态和存储状态;用以在第3步时,分配最佳的block存储位置。

  1. 用户客户端请求Hadoop客户端,并执行文件上传

  2. 上传的文件写入到Hadoop客户端的临时目录中,每当写入的数据量越过块(block)边界时(hadoop 1.x缺省64mb,hadoop2.x缺省128mb),请求NameNode申请数据块

  3. NameNode向Hadoop客户端返回block的位置

  4. Hadoop客户端直接将block写入指定的DataNode

四、HDFS数据读取机制


0:NameNode需要通过心跳机制收集DataNode的生存状态;在第3步时,不会将失效的DataNode位置返回给客户端

  1. 用户客户端请求Hadoop客户端,请求返回指定文件

  2. Hadoop客户端向NameNode发起读文件请求

  3. NameNode查询meta data并返回文件对应的block位置

  4. Hadoop客户端直接向DataNode请求block数据,获取到所有block后合并成文件

五、涉及概念(总结)

  • Block
    所有的文件将被拆分为若干block(缺省每个block大小为64mb),以存放在不同的DataNode中(每个block将有3个备份保存到不同DataNode)

  • DataNode
    用于存储block, block以文件的形式随机存储在集群的各个DataNode上
    DataNode不知道数据的内容,提取数据时无法知道每个Block该哪个DataNode上提取,于是需要记录每个Block存储在何处(NameNode上的元数据)。

  • NameNode
    记录文件的元数据,NameNode知道所有的文件对应哪些Block以及这些Block都存放在何处
    与各个DataNode通信并管理DataNode

  • 元数据( Metadata )
    描述数据的数据(data about data)
    包含了:每个文件的文件名、文件位置、访问权限和各个块的名称和位置
    大量小文件会生成过多元数据记录,降低NameNode查询效率(小文件定义:远远小于block边界大小的文件)。
    例:64Mb的文件分配1个block,占用1条元数据记录;而同样大小的1024个64Kb的文件,须分配1024个block,占用1024条元数据记录

  • 心跳
    NameNode记录了所有的DataNode,但如果DataNode突然失效,NameNode需要迅速的知道;于是需要每个DataNode定期(默认每3秒)向NameNode发送心跳信息

  • 客户端(Client)
    代表用户通过与NameNode和DataNode交互来访问整个文件系统.


更多推荐




                                                                                                         觉得好看,请点这里↓↓↓

以上是关于Hadoop之详解HDFS架构的主要内容,如果未能解决你的问题,请参考以下文章

Hadoop核心架构HDFS+MapReduce+Hbase+Hive内部机理详解

Hadoop核心架构HDFS+MapReduce+Hbase+Hive内部机理详解

Hadoop系列之HDFS架构

Hadoop之HDFS的FileSystem接口详解

Hadoop之HDFS架构设计

深入理解Hadoop之HDFS架构