|
第2章 YARN设计理念与基本架构/ ?: [% h* f5 M5 P9 ?" H& Q
在第1章, 我们介绍了Hadoop学习环境的搭建方法, 这是学习Hadoop需要进行的最基本的准备工作。 在这一章中, 我们将从
_4 O$ l. j- \3 t7 d/ g设计理念和基本架构方面对Hadoop YARN进行介绍, 这也属于准备工作的一部分。 通过本章的介绍将会为下面几章深入剖析
; Y* R% ?" B; I$ B* ?/ _$ i7 h/ [YARN内部实现奠定基础。4 o" K1 }. Q" s" n
由于MRv1在扩展性、 可靠性、 资源利用率和多框架等方面存在明显不足, Apache开始尝试对MapReduce进行升级改造, 于 J: _0 R9 T; U3 p* z$ B
是诞生了更加先进的下一代MapReduce计算框架MRv2。 由于MRv2将资源管理模块构建成了一个独立的通用系统YARN, 这直接 S: h1 U5 T# b- `
使得MRv2的核心从计算框架MapReduce转移为资源管理系统YARN。 在本章中, 我们将从背景、 设计思想和基本架构等方面对- Q& a- V& F6 l/ L2 Z' ?
YARN框架进行介绍。. J {" g: T9 j
2.1 YARN 产生背景; t2 e& c9 t( F* E1 [
2.1.1 MRv1 的局限性2 V1 c* @; `$ j# @7 R" {
YARN是在MRv1基础上演化而来的, 它克服了MRv1中的各种局限性。 在正式介绍YARN之前, 我们先要了解MRv1的一些局2 Z( ~ W5 v2 e8 L/ R( r* _1 @# W/ v, [
限性, 这可概括为以下几个方面:/ w! ]. z' |* @/ B& ]# u
❑扩展性差
: c7 P, _# h# g) V& d3 r。 在MRv1中, JobTracker同时兼备了资源管理和作业控制两个功能, 这成为系统的一个最大瓶颈, 严重制约了Hadoop集群扩展
, f) ]4 Y; |; G4 w5 ~5 U性。
1 V: b: V* B, o: r* A$ a: T \❑可靠性差
3 o0 \( i/ l$ o, A# @# Z。 MRv1采用了master/slave结构, 其中, master存在单点故障问题, 一旦它出现故障将导致整个集群不可用。 _# `8 R8 Z) m- b' I, c
❑资源利用率低
6 x9 J1 t/ l* {, a% G4 h。 MRv1采用了基于槽位的资源分配模型, 槽位是一种粗粒度的资源划分单位, 通常一个任务不会用完槽位对应的资源, 且其他; T" J& m8 k2 M" m4 a7 v
任务也无法使用这些空闲资源。 此外, Hadoop将槽位分为Map Slot和Reduce Slot两种, 且不允许它们之间共享, 常常会导致一种! Z$ f8 G) o) g9 j& d
槽位资源紧张而另外一种闲置( 比如一个作业刚刚提交时, 只会运行Map Task, 此时Reduce Slot闲置) 。" `. ~$ h4 x- n0 m) p
❑无法支持多种计算框架
. Z) ~) q# n# }5 ?6 B$ T+ N。 随着互联网高速发展, MapReduce这种基于磁盘的离线计算框架已经不能满足应用要求, 从而出现了一些新的计算框架, 包括
- a0 ?/ p' \" _内存计算框架、 流式计算框架和迭代式计算框架等, 而MRv1不能支持多种计算框架并存。+ h& f+ H5 k: @% X# a; g! m
为了克服以上几个缺点, Apache开始尝试对Hadoop进行升级改造, 进而诞生了更加先进的下一代MapReduce计算框架6 h5 o6 D3 q/ R x+ D$ y& `
MRv2。 正是由于MRv2将资源管理功能抽象成了一个独立的通用系统YARN, 直接导致下一代MapReduce的核心从单一的计算框
\* M8 a0 i* U7 v) r架MapReduce转移为通用的资源管理系统YARN。 为了让读者更进一步理解以YARN为核心的软件栈, 我们将之与以MapReduce为6 s2 j0 g* j* r% G3 o
核心的软件栈进行对比, 如图2-1所示, 在以MapReduce为核心的软件栈中, 资源管理系统YARN是可插拔替换的, 比如选择
5 L; }* H% D" T# ^& e( w% iMesos替换YARN, 一旦MapReduce接口改变, 所有的资源管理系统的实现均需要跟着改变; 但以YARN为核心的软件栈则不同,! k# l( ~8 N5 l) } k) z$ v. G: v
所有框架都需要实现YARN定义的对外接口以运行在YARN之上, 这意味着Hadoop 2.0可以打造一个以YARN为核心的生态系统。
( h1 |6 g( h3 C% [+ M# }图2-1 以MapReduce为核心和以YARN为核心的软件栈对比
2 c2 K6 Q" F: [! _2.1.2 轻量级弹性计算平台
! H ?! ]' h: b8 h% K, z随着互联网的高速发展, 基于数据密集型应用的计算框架不断出现, 从支持离线处理的MapReduce, 到支持在线处理的
( Z) o/ D5 h7 h" z$ yStorm, 从迭代式计算框架Spark到流式处理框架S4, 各种框架诞生于不同的公司或者实验室, 它们各有所长, 各自解决了某一类
& h0 ~9 O$ m" D! M0 @* w- M" K应用问题。 而在大部分互联网公司中, 这几种框架可能同时被采用。 比如在搜索引擎公司中, 一种可能的技术方案如下: 网页建
- I# x( ]6 ~& I1 C- Q& X2 u. \立索引采用MapReduce框架, 自然语言处理/数据挖掘采用Spark( 如网页PageRank计算、 聚类分类算法等) , 对性能要求很高的
5 Q1 I2 J$ u4 j4 z数据挖掘算法用MPI等。 考虑到资源利用率、 运维成本、 数据共享等因素, 公司一般希望将所有这些框架都部署到一个公共的集
& k* a. g! i+ ^0 P! c p- i群中, 让它们共享集群的资源, 并对资源进行统一使用, 同时采用某种资源隔离方案( 如轻量级cgroups) 对各个任务进行隔离,+ J5 L* n3 ]$ Q6 @! {/ K$ I- p
这样便诞生了轻量级弹性计算平台, 如图2-2所示。 YARN便是弹性计算平台的典型代表。
' `& \( B! \0 t: e+ h/ @从上面分析可知, YARN实际上是一个弹性计算平台, 它的目标已经不再局限于支持MapReduce一种计算框架, 而是朝着对
7 l/ k' u% a' x. T: K6 ^多种框架进行统一管理的方向发展。
5 |6 B9 c# s! l- d2 |$ ~$ |相比于“一种计算框架一个集群”的模式, 共享集群的模式存在多种好处:- g9 E) T/ g1 B- F
❑资源利用率高8 |- @, `& h/ J& [& z
。 如图2-3所示, 如果每个框架一个集群, 则往往由于应用程序数量和资源需求的不均衡性, 使得在某段时间内, 有些计算框架
6 V- ~& @ ]( N的集群资源紧张, 而另外一些集群资源空闲。 共享集群模式则通过多种框架共享资源, 使得集群中的资源得到更加充分的利用。
. W& F& w* J/ T8 a! G. ?❑运维成本低6 A+ ] h! G5 v, l8 ]0 } J, [# t
。 如果采用“一个框架一个集群”的模式, 则可能需要多个管理员管理这些集群, 进而增加运维成本, 而共享模式通常需要少数管
0 ]/ X& I. U7 W4 N/ _# Z9 S" `理员即可完成多个框架的统一管理。
$ M& t% W4 p5 t! v0 I图2-2 以YARN为核心的弹性计算平台的基本架构9 P! j: {+ b' @+ Z5 Q* y
图2-3 共享集群模式使得资源利用率提高
$ [9 O/ D/ w0 f, S2 R: G❑数据共享 N w) R a8 l! v7 {- y
。 随着数据量的暴增, 跨集群间的数据移动不仅需花费更长的时间, 且硬件成本也会大大增加, 而共享集群模式可让多种框架
* {6 ~3 ]% Z. q5 ~0 ^共享数据和硬件资源, 将大大减小数据移动带来的成本。
, z* @ V8 V3 {( P( T% a8 u; P# K0 p+ l0 c2 h, F# S* f5 D
|
|