|
|
第2章 YARN设计理念与基本架构' @& A* u! R" { \1 _4 B
在第1章， 我们介绍了Hadoop学习环境的搭建方法， 这是学习Hadoop需要进行的最基本的准备工作。 在这一章中， 我们将从
9 P' B, r3 R7 @' b设计理念和基本架构方面对Hadoop YARN进行介绍， 这也属于准备工作的一部分。 通过本章的介绍将会为下面几章深入剖析* y9 K- S. I# n
YARN内部实现奠定基础。9 T. e1 I0 Z- K+ k* K3 S- @, u. g
由于MRv1在扩展性、 可靠性、 资源利用率和多框架等方面存在明显不足， Apache开始尝试对MapReduce进行升级改造， 于
, Q' z" h7 T* _, _, s% Q是诞生了更加先进的下一代MapReduce计算框架MRv2。 由于MRv2将资源管理模块构建成了一个独立的通用系统YARN， 这直接8 e; c- ?4 @; w6 b; z r
使得MRv2的核心从计算框架MapReduce转移为资源管理系统YARN。 在本章中， 我们将从背景、 设计思想和基本架构等方面对
* N! h9 q C" o5 |, u7 m# z, {9 YYARN框架进行介绍。- E+ v& f0 y* V3 z2 J% j
2.1 YARN 产生背景" L! h0 @5 F" M7 o6 T$ z
2.1.1 MRv1 的局限性
" Y- T0 H( s) d2 C; m7 PYARN是在MRv1基础上演化而来的， 它克服了MRv1中的各种局限性。 在正式介绍YARN之前， 我们先要了解MRv1的一些局! f; A2 s. t' N+ a6 m3 x% d2 q
限性， 这可概括为以下几个方面： |6 S$ ~* E) e" \% s
❑扩展性差9 Q: B4 f( H4 M8 Z V4 P, P4 J0 B- V
。 在MRv1中， JobTracker同时兼备了资源管理和作业控制两个功能， 这成为系统的一个最大瓶颈， 严重制约了Hadoop集群扩展
: w( Y/ p7 p" [' R2 @* j性。
4 I! D8 `7 o% ^2 m! B- z❑可靠性差
8 p6 R/ l) i% _- \! m。 MRv1采用了master/slave结构， 其中， master存在单点故障问题， 一旦它出现故障将导致整个集群不可用。8 S0 C1 J. D/ E& J: E
❑资源利用率低: Z8 U# Q8 K2 G( H% x% ^
。 MRv1采用了基于槽位的资源分配模型， 槽位是一种粗粒度的资源划分单位， 通常一个任务不会用完槽位对应的资源， 且其他
S# y3 @$ o% B7 c/ S$ \/ K任务也无法使用这些空闲资源。 此外， Hadoop将槽位分为Map Slot和Reduce Slot两种， 且不允许它们之间共享， 常常会导致一种1 C! Y: }( a8 v7 D: [$ a
槽位资源紧张而另外一种闲置（ 比如一个作业刚刚提交时， 只会运行Map Task， 此时Reduce Slot闲置） 。
$ ]: U0 [! X8 R* ^/ a4 J- Q❑无法支持多种计算框架4 q* g* U6 j2 n$ B s1 R* K
。 随着互联网高速发展， MapReduce这种基于磁盘的离线计算框架已经不能满足应用要求， 从而出现了一些新的计算框架， 包括
' g7 H5 F# M. p; u2 e+ k: I/ H) d内存计算框架、 流式计算框架和迭代式计算框架等， 而MRv1不能支持多种计算框架并存。8 h( n5 w6 U" b5 f1 C- p
为了克服以上几个缺点， Apache开始尝试对Hadoop进行升级改造， 进而诞生了更加先进的下一代MapReduce计算框架
9 h/ e/ G' V, L2 h! E! SMRv2。 正是由于MRv2将资源管理功能抽象成了一个独立的通用系统YARN， 直接导致下一代MapReduce的核心从单一的计算框
# E8 z+ m' q2 v. M( [" L架MapReduce转移为通用的资源管理系统YARN。 为了让读者更进一步理解以YARN为核心的软件栈， 我们将之与以MapReduce为 v3 @7 h& Y( T1 Q* m5 n: b
核心的软件栈进行对比， 如图2-1所示， 在以MapReduce为核心的软件栈中， 资源管理系统YARN是可插拔替换的， 比如选择
2 d& I4 S$ d. j9 fMesos替换YARN， 一旦MapReduce接口改变， 所有的资源管理系统的实现均需要跟着改变； 但以YARN为核心的软件栈则不同，+ h7 p* |) L0 w1 E4 x* P
所有框架都需要实现YARN定义的对外接口以运行在YARN之上， 这意味着Hadoop 2.0可以打造一个以YARN为核心的生态系统。# z9 o% {5 B7 }0 H# _5 ^' C' a
图2-1 以MapReduce为核心和以YARN为核心的软件栈对比4 O* `( c3 h0 f- n. E8 M$ C: `
2.1.2 轻量级弹性计算平台
$ G$ J, K5 ^( }6 n) Y随着互联网的高速发展， 基于数据密集型应用的计算框架不断出现， 从支持离线处理的MapReduce， 到支持在线处理的 R8 H: G z, K, t0 |
Storm， 从迭代式计算框架Spark到流式处理框架S4， 各种框架诞生于不同的公司或者实验室， 它们各有所长， 各自解决了某一类
. c6 t( D O! ] B5 ]9 g应用问题。 而在大部分互联网公司中， 这几种框架可能同时被采用。 比如在搜索引擎公司中， 一种可能的技术方案如下： 网页建7 ^* F- n8 [' z- t$ D3 W# U9 c
立索引采用MapReduce框架， 自然语言处理/数据挖掘采用Spark（ 如网页PageRank计算、 聚类分类算法等） ， 对性能要求很高的* ^$ ?3 M5 B3 ^% G# v5 W1 G; L
数据挖掘算法用MPI等。 考虑到资源利用率、 运维成本、 数据共享等因素， 公司一般希望将所有这些框架都部署到一个公共的集
' M% {+ S0 ]/ u群中， 让它们共享集群的资源， 并对资源进行统一使用， 同时采用某种资源隔离方案（ 如轻量级cgroups） 对各个任务进行隔离，
, Z n1 |& I6 K3 g% L9 `1 q这样便诞生了轻量级弹性计算平台， 如图2-2所示。 YARN便是弹性计算平台的典型代表。
3 H& W8 y; n' O5 [; W( X: a从上面分析可知， YARN实际上是一个弹性计算平台， 它的目标已经不再局限于支持MapReduce一种计算框架， 而是朝着对
; z" v1 O) A4 h3 r' C6 F) ^多种框架进行统一管理的方向发展。. @% [/ w5 L/ L$ l; S8 l1 H Y2 u
相比于“一种计算框架一个集群”的模式， 共享集群的模式存在多种好处：
+ a" u$ B$ d* K6 f. C1 h❑资源利用率高, o: A5 Z; M! x9 x/ j/ G, p$ s7 ~0 r
。 如图2-3所示， 如果每个框架一个集群， 则往往由于应用程序数量和资源需求的不均衡性， 使得在某段时间内， 有些计算框架) }0 `8 _+ G* @3 z0 o7 p1 Z
的集群资源紧张， 而另外一些集群资源空闲。 共享集群模式则通过多种框架共享资源， 使得集群中的资源得到更加充分的利用。: e$ P* { T& X& j8 P' G9 s# _5 I
❑运维成本低2 `9 H4 ]$ M! Z8 J( Q X
。 如果采用“一个框架一个集群”的模式， 则可能需要多个管理员管理这些集群， 进而增加运维成本， 而共享模式通常需要少数管
. n# h. F& C8 j" l理员即可完成多个框架的统一管理。
$ @2 K% r- W; o+ k# i图2-2 以YARN为核心的弹性计算平台的基本架构6 f8 h9 @% v( P [8 x% u0 x
图2-3 共享集群模式使得资源利用率提高4 O6 C& T0 q& D1 i6 r0 G' J
❑数据共享
, ~9 T$ ]" W3 {: Q& M- |3 O$ U/ w。 随着数据量的暴增， 跨集群间的数据移动不仅需花费更长的时间， 且硬件成本也会大大增加， 而共享集群模式可让多种框架
# \* y. [6 m4 e2 e9 t, F) i# Q0 g4 F共享数据和硬件资源， 将大大减小数据移动带来的成本。
. o0 j. q! O) [, i4 f$ A$ B: W
8 H; P5 E) R4 v5 |( B1 ^+ V6 [: N6 D |
|
发表于 2017-4-13 21:21:00
