|
第2章 YARN设计理念与基本架构
n% W2 S2 L) j- G+ K在第1章, 我们介绍了Hadoop学习环境的搭建方法, 这是学习Hadoop需要进行的最基本的准备工作。 在这一章中, 我们将从 I/ W! G6 j& t& H, z! I+ A/ i2 A
设计理念和基本架构方面对Hadoop YARN进行介绍, 这也属于准备工作的一部分。 通过本章的介绍将会为下面几章深入剖析
" _! f$ b+ s9 L9 _2 M1 PYARN内部实现奠定基础。* K2 O1 O% p p% ` G
由于MRv1在扩展性、 可靠性、 资源利用率和多框架等方面存在明显不足, Apache开始尝试对MapReduce进行升级改造, 于; g" p* s: O) D" G f
是诞生了更加先进的下一代MapReduce计算框架MRv2。 由于MRv2将资源管理模块构建成了一个独立的通用系统YARN, 这直接
% t5 y0 ?; \: F% X. n! |使得MRv2的核心从计算框架MapReduce转移为资源管理系统YARN。 在本章中, 我们将从背景、 设计思想和基本架构等方面对1 h" T7 }; L* v1 X
YARN框架进行介绍。7 s4 _; J( p" w
2.1 YARN 产生背景7 |4 h: m2 M6 G
2.1.1 MRv1 的局限性
m" ^: _2 P& Q( @$ ]" ?6 vYARN是在MRv1基础上演化而来的, 它克服了MRv1中的各种局限性。 在正式介绍YARN之前, 我们先要了解MRv1的一些局9 q! H, M0 h4 w
限性, 这可概括为以下几个方面:) i% ?; ?, I/ n' f3 W
❑扩展性差
: H' ~+ ^6 s. K4 X( c/ D7 {: {。 在MRv1中, JobTracker同时兼备了资源管理和作业控制两个功能, 这成为系统的一个最大瓶颈, 严重制约了Hadoop集群扩展
, u7 U* x0 I' J& {0 }性。
" z; w e, ?% \+ v, p; W/ A4 t❑可靠性差
0 {' k* F* `6 K1 z0 t/ T+ c$ [。 MRv1采用了master/slave结构, 其中, master存在单点故障问题, 一旦它出现故障将导致整个集群不可用。/ ~" I, |) i; Z9 T" R* F1 M
❑资源利用率低2 ^7 A7 i: K% c% ~, T6 R9 [& B+ w7 `
。 MRv1采用了基于槽位的资源分配模型, 槽位是一种粗粒度的资源划分单位, 通常一个任务不会用完槽位对应的资源, 且其他5 \: F+ C& [: J- s* u# G- K
任务也无法使用这些空闲资源。 此外, Hadoop将槽位分为Map Slot和Reduce Slot两种, 且不允许它们之间共享, 常常会导致一种+ P. e. z) o8 n! k6 A0 U
槽位资源紧张而另外一种闲置( 比如一个作业刚刚提交时, 只会运行Map Task, 此时Reduce Slot闲置) 。
3 H4 Q: z+ ~4 P4 V L$ X* T: J❑无法支持多种计算框架. o3 D2 A6 o# J0 Y$ P1 Y4 h
。 随着互联网高速发展, MapReduce这种基于磁盘的离线计算框架已经不能满足应用要求, 从而出现了一些新的计算框架, 包括
U# ^: V' L% l9 E9 }6 A内存计算框架、 流式计算框架和迭代式计算框架等, 而MRv1不能支持多种计算框架并存。3 I/ Q) g% Y. n% j9 b) w
为了克服以上几个缺点, Apache开始尝试对Hadoop进行升级改造, 进而诞生了更加先进的下一代MapReduce计算框架4 h9 C# D$ a- i" F. e1 H
MRv2。 正是由于MRv2将资源管理功能抽象成了一个独立的通用系统YARN, 直接导致下一代MapReduce的核心从单一的计算框
# O) R) A* r" G. b架MapReduce转移为通用的资源管理系统YARN。 为了让读者更进一步理解以YARN为核心的软件栈, 我们将之与以MapReduce为
# b- v: ^% G& b核心的软件栈进行对比, 如图2-1所示, 在以MapReduce为核心的软件栈中, 资源管理系统YARN是可插拔替换的, 比如选择8 r( H0 L; ~7 |# x! n
Mesos替换YARN, 一旦MapReduce接口改变, 所有的资源管理系统的实现均需要跟着改变; 但以YARN为核心的软件栈则不同,, @9 Z1 A; W# G
所有框架都需要实现YARN定义的对外接口以运行在YARN之上, 这意味着Hadoop 2.0可以打造一个以YARN为核心的生态系统。
5 O( y/ Y& A; ~) a) i图2-1 以MapReduce为核心和以YARN为核心的软件栈对比
2 q3 r& ^ ]+ P( }, t6 W- O2.1.2 轻量级弹性计算平台
+ K! m5 b- y0 {- m随着互联网的高速发展, 基于数据密集型应用的计算框架不断出现, 从支持离线处理的MapReduce, 到支持在线处理的
: [ g+ n8 t$ D6 }6 qStorm, 从迭代式计算框架Spark到流式处理框架S4, 各种框架诞生于不同的公司或者实验室, 它们各有所长, 各自解决了某一类
$ B8 d8 u+ c7 \" O$ f应用问题。 而在大部分互联网公司中, 这几种框架可能同时被采用。 比如在搜索引擎公司中, 一种可能的技术方案如下: 网页建
! C( U2 a! E3 I$ A" k: s立索引采用MapReduce框架, 自然语言处理/数据挖掘采用Spark( 如网页PageRank计算、 聚类分类算法等) , 对性能要求很高的
( `, |; u* X3 l" ~& F2 p数据挖掘算法用MPI等。 考虑到资源利用率、 运维成本、 数据共享等因素, 公司一般希望将所有这些框架都部署到一个公共的集' g j: W( p2 T( m: J' y
群中, 让它们共享集群的资源, 并对资源进行统一使用, 同时采用某种资源隔离方案( 如轻量级cgroups) 对各个任务进行隔离,% i- i8 `5 I( {
这样便诞生了轻量级弹性计算平台, 如图2-2所示。 YARN便是弹性计算平台的典型代表。7 m1 K% \2 `8 a5 I% k. r' o' h
从上面分析可知, YARN实际上是一个弹性计算平台, 它的目标已经不再局限于支持MapReduce一种计算框架, 而是朝着对
9 ? C+ g7 b, S, K4 G. B多种框架进行统一管理的方向发展。
4 D7 V1 S% ~) a# ^& A/ m相比于“一种计算框架一个集群”的模式, 共享集群的模式存在多种好处:" \; D# ^6 P0 ^5 c
❑资源利用率高
, v# O) i* G+ X: s5 Z- ^。 如图2-3所示, 如果每个框架一个集群, 则往往由于应用程序数量和资源需求的不均衡性, 使得在某段时间内, 有些计算框架
1 g, U e/ \6 R$ p g- z& Z的集群资源紧张, 而另外一些集群资源空闲。 共享集群模式则通过多种框架共享资源, 使得集群中的资源得到更加充分的利用。5 a) i' w) P7 K: L
❑运维成本低; e. h% y- a( K5 Y
。 如果采用“一个框架一个集群”的模式, 则可能需要多个管理员管理这些集群, 进而增加运维成本, 而共享模式通常需要少数管
3 M g; E# _! K0 ?+ t2 n1 W# N理员即可完成多个框架的统一管理。
4 n1 T1 i3 n3 p图2-2 以YARN为核心的弹性计算平台的基本架构
, M4 P6 K8 m, d/ n5 R9 G$ ~3 ?图2-3 共享集群模式使得资源利用率提高2 {8 {, m0 V+ x! e8 `' b
❑数据共享
, {6 p9 T/ @0 R) l/ A- S; U。 随着数据量的暴增, 跨集群间的数据移动不仅需花费更长的时间, 且硬件成本也会大大增加, 而共享集群模式可让多种框架# Y& k& W: ~( \2 p
共享数据和硬件资源, 将大大减小数据移动带来的成本。
; E8 l @* \) @2 H
% R" C' [# n& J |
|