HDFS学习之Yarn

开始学习Hadoop了,其中很重要的一块就是它的存储系统-HDFS,先学学HDFS

HDFS概述

HDFS源于Google发表于2003年10月的GFS论文,为GFS的克隆版,HDFS是 Hadoop Distributed File System的简写, 它是一个易于扩展的分布式文件系统,运行在大量普通廉价机器上,成本较低,并且通过多副本方式提供较好的容错能力

优点

HDFS的优点有很多,简单介绍:

高容错: 系统的数据自动保存多个副本, 在副本丢失后,可以自动恢复

适合大数据批处理:系统通过API将数据位置暴露给计算框架,通过移动计算不移动数据的方式来处理大数据量的计算,可以存储GB、TB甚至PB级别的数据,文件数量可达到百万规模及以上,目前实用的案例有超过上万台节点的部署

流式文件访问:系统数据支持一次写入,多次读取,并不支持随机修改,通过多副本的方式来保证数据的一致性和完整性。

构建成本低,安全可靠 :系统部署在廉价的商用机器上,设备成本低,通过多副本的方式提高了系统的可靠性,并提供容错和恢复机制。

缺点

不适合低延迟数据访问:系统以数据块存储,通过牺牲访问速度来换取高吞吐率,不适合对存取速度要求较高的场景。

不适合大量小文件存储:系统NameNode会存储文件元数据,小文件太多内存占用过大,导致NameNode不可用,且小文件过多在读取时会占用大量的寻道时间,读取时间和寻道时间的比例不太好。

不适合并发写入:系统的一个文件只能有一个写入者,不适合并发场景的写入

不提供文件随机修改:系统只支持追加数据,不提供随机修改操作

基本架构与原理


HDFS架构

HDFS以NameNode管理命名空间,维护文件存储的元数据信息,将存储的数据按照固定大小切分成多块,分别存储多份数据,存放在不同的节点, 通过Standby NameNode实现高可用,保证系统在Active NameNode挂掉的情况下还能够对外提供服务,以DataNode来存储具体数据,DataNode通过心跳机制来向NameNode报告节点运行状态及存储的数据等信息,HDFS默认存储的副本为3,如果因为节点挂掉导致副本数量不足,系统会再复制数据来保证最低副本数。

概念

ActiveNameNode

系统的主节点,只有一个,主要作用是管理HDFS文件系统的命名空间,维护文件元数据信息,管理HDFS的副本策略,处理客户端的读写请求


HDFS读写


客户端在向HDFS发送写请求时,NameNode首先将操作信息写入edit日志,然后对数据进行分块,向DataNode发送写请求,在DataNode写入大部分数据(一半以上),NameNode将元数据写入内存,fsimage定期将内存内容及edit日志同步并固化到磁盘(此过程理解不全,有疏漏敬请指正)

Standby NameNode

Active NameNode的热备节点,它会周期性同步edits的编辑日志,定期合并fsimage和eidts到本地磁盘,当Active NameNode出现故障时,集群可以几乎无缝切换到Standby NameNode

NameNode元数据文件

NameNode元数据文件包括edits和fsimage,edits保存客户端对文件的写操作记录,包括创建文件、删除文件,fsimage为文件系统元数据的检查点镜像文件,保存了文件系统中的所有目录和文件信息,如目录结构、文件副本数、文件的块信息等,NameNode中的内存中保存着最新的镜像信息,镜像内容为fsimage + edits,NameNode会定期将内存中的数据增量备份到磁盘中

DataNode

slave的工作节点,一般启动多个,可以灵活扩展

存储数据块和数据校验和(对数据内容进行校验,看数据内容是否完整)

通过心跳机制定期向NameNode汇报运行状态和所有块的列表信息

在集群启动时DataNode向NameNode提供存储的Block块的列表信息

Block数据块

文件写入HDFS会被切分成固定大小的Block块

数据块的大小固定,Hadoop2.0默认128M,1.0默认64MB,可自定义修改

Block数据块是HDFS的最小存储单元,定义的数据块大小为数据切分的最大大小,如果大小不够,以实际的来

默认每个Block有三个副本

Client

客户端,主要作用为文件切分,与NameNode交互获取文件元数据信息,与DataNode交互,读取或写入数据,管理HDFS

HDFS为什么不适合存储小文件

HDFS元数据信息存储在NameNode的内存中,内存大小再大也有限制

NameNode存储的Block数量有限(一个block元信息消耗大约150byte内存,小文件过多,占用的内存太大,存的数据却没有多少,性价比不高)

存储大量的小文件浪费大量的磁盘寻道时间

HDFS的高可用


HDFS高可用

在Hadoop系统中,如果NameNode故障,由于集群数据量大,重启需要的时间将会很长,HDFS使用Standby NameNode来解决这样的问题,主要的实现路径有两条,一条为NameNode的数据共享,另外一条为NameNode故障时的主备切换

数据共享:

DataNode通过多副本的形式进行数据备份,NameNode则使用了Standby NameNode,在客户端写数据时,Active NameNode除了写edits,也会同步阻塞写JournalNode的eidt日志,只有大部分(二分之一)JournalNode的edit日志写入成功,才会修改内存中的数据信息,之后数据才会修改。(JournalNode为一组轻量的NameNode和Standby NameNode进行通信的进程,它们组成了一套QIM共享存储系统,只负责存储edit日志),Standby NameNode定期与JournalNode进行同步更新内存数据,Active NameNode 和Standby NameNode都会定期将数据固化到fsimage中

主备切换:

准备切换由DFSZKFailoverController(以下简称ZKFC)来控制,每个NameNode都有一个ZKFC进程,ZKFC会同时构建HealthMonitor和ActiveStandbyElector,HealthMonotor会通过RPC定期检查NameNode的健康状况。

集群启动时,ActiveStandbyElector都会主动在Zookeeper创建临时锁节点,写入成功的NameNode即为Active,另外为Standby的,在运行时Active NameNode发生故障/网络延迟时,Zookeeper临时节点删除,Standby NameNode会尝试创建临时节点,如果创建成功,则Standby NameNode会变成Active NameNode。另外,如果HealthMonitor监测到Active NameNode机器故障,则通知ActiveStandbyElector进行选举,故障节点不参与选举,主备会进行切换Standby NameNode创建临时节点

脑裂:Active NameNode会因为其他原因(如网络阻塞、Full GC)而与Zookeeper的会话超时,导致假死,此时Standby NameNode切换为Active NameNode,但另外的Active NameNode恢复后也为Active NameNode这样造成双主现象,称为脑裂。Hadoop会通过fencing机制,首先会通过ssh把Active NameNode切换为Standby NameNode,如果失败,则会强行将进程kill,如果再失败,可配置bash脚本将服务器强行关机。

以上为HDFS的一些学习笔记,如有遗漏,欢迎指正。

Yarn

Yarn是Yet Another Resource Negotiator的简称,从Hadoop2.0开始引入的一个资源调度系统,为了解决多框架下的资源及硬件的管理。

Yarn主要提供了资源管理,统一管理和调度集群资源,负责与客户端交互,处理客户端的请求。

基本架构

Yarn采用典型的Master-Slave架构,Master即ResourceManager,Slave即NodeManager,ResourceManager负责全局资源管理和调度,NodeManager负责本机的资源管理,ResourceManager一般与DataNode一一对应,ResourceManager通过心跳定期与ResourceManager进行通信,汇报机器的资源使用情况,ResourceManager在接收到作业请求后,通过调度器分配一个Container(运行任务所必需的资源的一个抽象容器),然后协调NodeManager,分配到具体的NodeManager,NodeManager启动一个ApplicationMaster,ApplicationMaster与ResourceManager通信申请资源,ResourceManager分配给ApplicationMaster资源,ResourceManager调度NodeManager资源进行相应的任务执行,在任务执行的过程中ApplicationMaster与ResourceManager进行通信,汇报任务执行情况,如果任务执行失败,会调度到其他机器进行再次执行。

为了集群高可用,ResourceManager也会启动一个备用的ResourceManager,它们基于Zookeeper实现高可用


Yarn基本架构


核心组件

ResourceManager

整个集群只有一个,主要用来处理客户端请求,启动/监控ApplicationMaster,监控NodeManager,对资源进行分配和调度

NodeManager

每个节点只有一个,集群中一般与DataNode一一对应,在相同的机器上进行部署,主要功能:单个节点的资源监控和管理;定时向ResourceManager汇报本机的资源使用情况;处理ResourceManager的请求,为作业的执行分配Container;处理来自ApplicationMaster的请求,启动和停止Container

ApplicationMaster

每个应用程序只有一个,负责应用程序的管理,资源的申请和任务调度,主要功能:与ResourceManager协商为应用程序申请资源;与NodeManager通信启动/停止任务;监控任务的运行状态和失败处理

Container

任务运行环境的抽象,只有在分配任务的时候才会抽象出一个Container,主要功能:描述一系列信息(任务运行资源如节点、CPU、内存等);管理任务的启停及任务的运行环境

Yarn容错

Resource基于Zookeeper实现高可用

NodeManager故障会导致运行在该节点运行的任务失败,任务失败后,ResourceManager将失败任务通知对应的ApplicationMaster,ApplicationMaster决定如何处理失败的任务

ApplicationMaster失败后,由ResourceManager负责重启,RMApplicationMaster会保存已经运行完成的Task,重启后不需要重新运行。

补充:在超大规模的集群中,可以使用namenode federation来配置多个命名空间,但一般来说是不会用到的,除了向百度,google这样数据量超多的公司

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,743评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,296评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,285评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,485评论 1 283
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,581评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,821评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,960评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,719评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,186评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,516评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,650评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,329评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,936评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,757评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,991评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,370评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,527评论 2 349