您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
Hadoop之详解HDFS架构
 
 
 
  469  次浏览      50
2020-9-22 
 
编辑推荐:
本文主要讲解了HDFS基础,HDFS架构思路解析、HDFS组成架构、HDFS数据写入机制、HDFS数据读取机制等内容。
本文来自微信侦查一线,由火龙果软件Anna编辑、推荐。

Hadoop包含三大基本组件:

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

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

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

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

一、HDFS概述

1.1 HDFS产生背景

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

1.2 HDFS定义

HDFS(Hadoop Distributed File System):是Hadoop的分布式文件系统的实现。它的设计目标是存储海量的数据,并为分布在网络中的大量客户端提供数据访问。

HDFS是高容错性的,可以部署在低成本的硬件之上,HDFS提供高吞吐量地对应用程序数据访问。

HDFS的使用场景:适合一次写入,多次读出的场景,且不支持文件的修改。适合用来做数据分析,并不适合用来做网盘应用。

1.3 HDFS特性

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

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

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

1.4 HDFS局限性

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

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

不支持文件修改

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

不适合存储小文件

二、HDFS架构思路解析

2.1 HDFS架构思路解析1

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

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

2.2 HDFS架构思路解析2

将文件保存在不同的节点(Node)中:

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

解决方案,将一份数据备份到多个节点。

采用这种方法存在以下两种优点:

1、可靠性高,一个节点坏掉,启用备份

2、读取速度快,同一份数据多个备份同时读

那又存在什么局限性呢?

大文件保存和读取困难(如:单个100G文件)。

2.3 HDFS架构思路解析3

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

2.4 HDFS架构思路解析4

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

如何知道系统中有哪些文件?

节点中只存储了文件的Block,文件的原始信息丢失

如何知道某个原始文件的Block对应于哪些节点?

逐个节点去查找?

还是建立一个管理节点,专门来管理各个节点的信息?

最终解决方案:

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

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

三、HDFS组成架构

主从模式

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

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

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

3.1 HDFS组成架构介绍

HDFS组成架构如下所示:

NameNode(nn):也就是Master,它是一个主管、管理者。使用NameNode存储元数据信息,保存文件名以及文件的块(Block)存储在哪些DataNode中。每个存活的DataNode定时向NameNode发送心跳信息,如果未收到DataNode的心跳,NameNode将认定其已失效,不再向其派发任何文件读请求。NameNode会将失效的DataNode中的块(Block)备份到其他存活的DataNode中。简单来说就是:

(1)管理HDFS的名称空间;

(2)配置副本策略;

(3)管理数据块(Block) 映射信息;

(4)处理客户端读写请求。

DataNode:就是Slave,NameNode下达命令,DataNode执行实际操作。

(1)存储实际的数据块

(2)执行数据块的读/写操作

Client:就是客户端。

(1)文件切分。文件上传HDFS的时候, Client将文件切分成一 个个的Block, 然后进行上传

(2)与NameNode交互,获取文件的位置信息

(3)与DataNode交互,读取或者写入数据

(4)Client提供一 些命 令来管理HDFS,比如NameNode格式化

(5)Client可以通过一些命令来访问HDFS,比如对HDFS增删查改操作

Secondany NameNode:并非NameNode的热备。当NameNode挂掉的时候, 它并不能马上替换NameNode并提供服务。

(1)辅助NameNode,分担其工作量,比如定期台并fsimage和edits,并推送给NameNode ;

(2)在紧急情况下,可辅助恢复NameNode。

3.2 Namenode的元数据管理机制

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

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

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

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

NameNode元数据管理过程

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

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

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

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

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

3.3 三个问题

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

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

如果块设置的太大,从磁盘传输数据的时间会明显大于定位这个块开始位置所需的时间。导致程序在处理这块数据时,会非常慢。

总结: HDFS块的大小设置主要取决于磁盘传输速率。

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

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

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

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

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

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

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

3.4 Checkpoint过程

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

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

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

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

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

SN将fsimage.checkpoint发送给NN

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

3.5 NameNode单点故障恢复

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

利用SN(Secondary NameNode)的备份恢复NN (NameNode)元数据

SN与NN并不是时刻同步的,checkpoint有时间间隔,这会导致恢复后有数据丢失

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数据写入机制

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

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

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

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

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

五、HDFS数据读取机制

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

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

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

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

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交互来访问整个文件系统.

 

 
   
469 次浏览       50
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训
最新课程计划
 
最新文章
大数据平台下的数据治理
如何设计实时数据平台(技术篇)
大数据资产管理总体框架概述
Kafka架构和原理
ELK多种架构及优劣
最新课程
大数据平台搭建与高性能计算
大数据平台架构与应用实战
大数据系统运维
大数据分析与管理
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
北京 Python及数据分析
神龙汽车 大数据技术平台-Hadoop
中国电信 大数据时代与现代企业的数据化运营实践
更多...