来说说YARN的前世今生

写在前面。本文并未具体描述YARN的使用细节,而是从YARN出现的背景、解决什么问题、怎么解决这些问题的角度出发,希望帮助已经使用YARN的、刚接触YARN的读者更好的了解YARN。

Hadoop

对于大数据的处理,Hadoop俨然已是业界认可、成熟的数据存储、处理框架。目前,Hadoop经历主要经历了两个版本。在Hadoop v2.0的版本中,YARN被引入,YARN的引入主要是解决了Hadoop v1.0中的一些问题(在下文中将主要探讨)。

YARN要解决什么问题?

在Hadoop v1.0的框架中,对数据的处理、资源调度主要依赖MapReduce完成,具体过程如下所示:

从以上图中,我们可以了解到Hadoop v1.0的数据处理方式。在小规模的数据处理过程中,这套方法没有太大问题。但是,在真实的场景中往往需要处理大量数据,这套方法便会遇到以下问题:

  • 由于大量的数据处理Job提交给Job Tracker,且Job Tracker需要协调的Data Node可能有数千台,Job Tracker极易成为整个系统的性能、可用的瓶颈。

  • 无法有效地调配资源,导致资源分配不均。如以下例子,假设有3台Data Node(DN),每个DN的内存为4GB。用户提交了6个Job,每个Job需要1GB内存进行处理,且数据均在DN#2上。由于DN#2只有4GB内存,所以Job#1-4在DN#2上运行,Job#5和#6则在排队等待。但是,此时DN#1和#3均在闲置的状态下,而未能有效的被利用。

  • 只能接受MapReduce的方式,且技术栈仅为Java。

YARN的解决方案

基于上述问题,Hadoop在2.0版本上推出了YARN (Yet Another Resource Negotiator)。YARN的核心思想是将资源管理和Job的调度/监控进行分离。YARN的架构如下图所示。

YARN的核心组件可以分为两大部分:

  • 全局组件

    • Resource Manager: 作为全局统一的资源管理、调度、分配。Resource Manager由Scheduler和Applicatio Manager组成。Scheduler根据节点的容量、队列情况,为Application分配资源;Application Manager接受用户提交的请求,在节点中启动Application Master,并监控Application Master的状态、进行必要的重启。
    • Node Manager: 在每一个节点上都有一个Node Manager作为代理监控节点的资源使用情况(cpu, memory, disk, network)并向Resource Manager上报节点状态。
  • Per-applicaiton组件

    • Application Master: 负责数据处理job的执行调度。Application Master与Resource Manager进行沟通,获取资源进行计算。得到资源后,与节点上的Node Manager进行沟通,在分配的Container汇总执行任务,并监控任务执行的情况。
    • Container: 资源的一种抽象方式,它封装了某个节点上的多维度资源,如内存、CPU、磁盘、网络等,当Application Master向Resource Manager申请资源时,Resource Manager为Application Master返回的资源便是Container。

当YARN接受用户提交的Job时,其工作过程为:

YARN通过以下方式,解决了上述问题。

  • 通过Application Master来解决Job Tracker的瓶颈问题。每当新的job提交进来后,Resource Manager会在恰当的节点启动一个新的Application Master,从而避免在Hadoop v1.0中Job Tracker成为性能瓶颈的尴尬。

  • 更有效的进行资源的调度。Resource Manager可以为Application Master分配空余的资源,帮忙Application Master完成任务。

  • 支持MapReduce以外的数据处理方式,例如:Spark等。

YARN的一些问题

即便Hadoop v2.0应用来YARN的设计思路,也仍有一个难题:当大量的job提交、用尽所有计算资源后,新的job要等待很久才能被处理,即便新的job是非常重要的任务,也只能等待。在YARN中,通过scheduler plugin(例如:FIFO Scheduler、Fair Scheduler、Capacity Scheduler)的方式,配置不同的资源调度规则,来尽量缓解该问题,让重要的job可以优先获得资源调配。

Reference


pstrike 2018.08.31 于深圳

【尊重版权:转载之前请先联系我】

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

推荐阅读更多精彩内容