初识分布式计算:从MapReduce到Yarn&Fuxi

Posted xybaby

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了初识分布式计算:从MapReduce到Yarn&Fuxi相关的知识,希望对你有一定的参考价值。

    这些年,云计算、大数据的发展如火如荼,从早期的以MapReduce为代表的基于文件系统的离线数据计算,到以Spark为代表的内存计算,以及以Storm为代表的实时计算,还有图计算等等。只要数据规模到了一定的程度,都需要依赖分布式计算来实时或者离线做出决策。虽然本人并未从事相关工作,但是了解一下还是好的。

  MapReduce这个词一度是分布式计算的代名词,至少代表了离线计算这一大类大数据编程范式。当提到这个词,可能是指google的论文,或者hadoop的mr实现,也或者是这种编程范式。在本文中,除非特别说明,都是指Google 2004年的论文《MapReduce: Simplified Data Processing on Large Clusters》,这篇论文非常通俗易懂,也没有复杂的概念和算法,值得一读。

  在论文中,MapReduce既是一种分布式编程模型(programming model);又是该模型的运行时环境,该环境是为这种编程模型所量身定做的。

MapReduce is a programming model and an associated implementation for processing and generating large data sets.  

MapReduce编程模型

  前面说MapReduce论文比较容易读懂,原因就是MapReduce的思想很简单。MapReduce分为两个阶段:Map, Reduce。 Map就是把问题划分成独立的组成部分,每一个Map(计算过程)处理独立的一部分数据,分而治之,逐个击破; Reduce就是对Map的结果做一个聚合。

  程序员学习每一门语言都是从Hello World开始,分布式计算也有“Hello World”, 那就是WordCount。WordCount就是统计一段文本中每个单词的出现次数,具体计算过程就是先把文本分成M份数据,通过M个并行的map function计算出每一份数据中每个单词的次数,生成结果是一个<key, value>对,key是单词,value是该单词的数量;而reduce function将所有map function的结果按照key进行聚合(相加),结果就是整个文本中每个单词的数目。

  我觉得下面这个图更加形象(来源见水印):

  

  在论文中提到,MapReduce来自函数式编程(如Lisp)的两个算子:map、reduce。函数式编程是与面向对象编程并列的一种编程范式,函数式编程中,函数是一等公民,且支持高阶函数,即以函数作为另一个函数的参数。即使是面向对象的编程语言,也提供函数式编程机制,比如C++中的std::for_each,而对于笔者比较熟悉的Python,也有两个同名、同含义的函数map reduce。下面是python代码

>>> lst = [1, 2, 3, 5, 6]
>>> new_lst = map(lambda e: 2 * e, lst)
>>> new_lst
[2, 4, 6, 10, 12]
>>>
>>> reduced = reduce(lambda total, e : total + e, lst, 0)
>>> reduced
17 

  指的一提的是,函数式编程的无状态特性,即函数的运行结果只依赖于输入,且不会对外界的环境产生引用,只有输入相同,输出就是确定的,这个特性非常重要,因为在MapReduce编程模型中,会有同一份数据的重复计算,后面会提到。

  还有,从对map过程的介绍不难理解,MapReduce只适合线性可并行的计算任务,子任务之间不能有依赖关系,只有这样的计算任务,才能进行拆分,然后通过map并行计算,最终通过reduce进行结果的叠加。主要满足这个条件,都适合用mapreduce模型来计算,如论文中提到的:

  • word counting:统计文本中每个单词的数量
  • distributed grep:分布式grep
  • Count of URL Access Frequency:统计每个url的访问频率
  • Reverse Web-Link Graph: 引用关系图
  • Inverted Index: 倒排索引

  不管是WordCount问题,还是上面“做菜”的例子,大家一看都很简单,完全可以串行执行。但是当数据量到了TB、PB级别,用单台计算机的话得计算到猴年马月,分布式就是要解决单台计算机无法完成的计算任务,每台计算机算一点(map过程),然后将结果汇总起来(reduce过程),这就是分布式计算。

MapReduce运行时环境

  前面提到,尽管MapReduce编程模型简单直观,但是由于数据量巨大的问题,必须要使用大量机器进行分布式计算,而分布式本事又是一个复杂且困难的问题。因此,运行时环境(框架)的作用就在于将程序员从分布式的繁枝缛节中解放出来,程序员只需关注本质的问题:数据的计算问题,而不用关心数据是在哪台机器上计算的、怎么计算的。而且由于MapReduce编程模型的普适性,只要将运行环境与计算公式隔离开,就可以复用运行环境,大大提高生产力。

  运行时环境是提供给需要进行大量数据计算的程序员使用的,后文统称使用运行时环境的程序员为运行时环境的用户

  以Google实现的MapReduce·运行环境为例,运行时环境负责输出数据的拆分、将计算任务在一组节点(计算机)上调度执行、处理节点的故障、以及节点之间的RPC通信。用户只需要提供两个最基本的算子,map function,reduce function即可。

The run-time system takes care of the details of partitioning the input data, scheduling the program\'s execution across a set of machines, handling machine failures, and managing the required inter-machine communication.This allows programmers without any experience with parallel and distributed systems to easily utilize the resources of a large distributed system.

  下面是mapreduce框架

  

  框架中有两类节点(也可以说是进程),MasterWorker,当用户提交一个计算作业(Job)的时候,会启动Job唯一对应的Master进程,Master进程负责整个Job的调度,包括分配worker的角色(map或者reduce)、worker计算的数据,以及向用户返回结果等等。而Worker负责的具体计算称之为task,在MapReduce框架下,worker按照计算的阶段又分为map worker和reduce worker,worker在master获取计算任务,然后在文件系统读取数据进行运算,并将结果写入到临时文件或者持久化文件系统。

  一个Job的流程是这样的

  1. MapReduce将待运算的数据分为M份,每一份的大小为16M或者64M(这个跟默认使用的分布式文件系统GFS有关),每一份数据称之为一个split
  2. 启动M个map worker,读取相应的split,然后调用用户的Map function,对数据进行运算
  3. map worker周期性将计算结果(称之为中间结果)写入到R份本地文件中的其中一份,R是reduce worker的数量,具体写入哪一个临时文件 规则由Partitioning function指定
  4. 当一个map worker计算任务完成的时候,将R份中间结果的位置通知master,master通知对应的reduce worker
  5. reduce worker根据中间结果的位置,通过rpc从map worker上获取与自己对应的中间结果,进行计算,并将计算结果写入到持久化分布式文件系统,
  6. 当所有map reduce worker的计算任务结束之后,通知用户计算结果

  当然,一个mapreduce的结果并不一定直接给用户,很有可能是一个链式(chain)计算,即将一个mapreduce的输出当做另一个mapreduce的输入

MapReduce优缺点

  google MapReduce以及hadoop的开源实现mapreduce(简称hadoop mr1)都是十余年前的产物,虽然已经不能满足现在的很多运算需求,但是还是有很多很好的设计值得学习借鉴。

  data locality,即计算离需要的数据存储越近越好,以尽量避免网络传输

  fault tolerance,分布式系统中,节点故障是常态,运行环境需要对用户透明地监控、处理故障。由于mapreduce编程模型的线性无状态特性,对于某一个worker的故障,只需将计算任务给其他worker负责就行

  backup task,按照木桶定律,即一只水桶能装多少水取决于它最短的那块木板,在mapreduce中,运行最为缓慢的worker会成为整个Job的短板。运行环境需要监控到异常缓慢的worker,主动将其上的task重新调度到其他worker上,以便在合理的时间结束整个Job,提高系统的吞吐。

  partitioning function & combiner function,这是用户可以提供的另外两个算子,实时上也是非常有用的。map worker的中间结果,通过partitioning function分发到R(R为reducer的数目)位本地文件,默认为“hash(key) mod R”。而Combiner function是对每一个map worker的结果先进行一次合并(partial merge),然后再写入本地文件,以减少数据传输,较少reduce worker的计算任务。

  local execution:本地执行,会提供一个最小化的本地运行环境,以便用户调试、分析自己的代码。这个功能笔者神深有感触,多年前实习的时候使用MapReduce进行数据分析,由于需要排队且自己的优先级比较低,所以一个Job要等个一天才有结果,如果因为一个拼写错误就要重新跑的话简直要崩溃。这个时候就可以先在本地环境用少量数据进行调试,验证。

  

  在google 论文中,也有不足或者没有考虑到的点。

  第一:master是单点,故障恢复依赖于周期性的checkpoint,不保证可靠性,因此发生故障的时候会通知用户,用户自行决定是否重新计算。

  第二:没有提到作业(Job)的调度策略,运行时环境肯定是有大量的Job并发的,因此多样且高效的调度策略是非常重要的,比如按优先级、按群组

  第三:并没有提到资源(CPU、内存、网络)的调度,或者说并不区分作业调度与资源调度。

  第四:没有提到资源隔离与安全性,大量Job并发的时候,如何保证单个Job不占用过多的资源,如何保证用户的程序对系统而言是安全的,在论文中并没有提及

  第五:计算数据来源于文件系统,效率不是很高,不过本来就是用于离线任务,这个也不是什么大问题

yarn & fuxi

  上一章节的最后提到了mapreduce的一些缺陷,包括master单点,资源调度与任务调度职责不明确,只使用与离线数据处理等。随着大数据分析的蓬勃发展,就需要更加多样性的分布式编程范式,比如实时数据处理、内存计算、图计算等等。编程范式的多样化对运行时环境提出了更大的挑战,即运行时环境需要更通用,以支持不同的编程模型,而不是像mapreduce框架那样只支持mapreduce这种编程范式。不同的编程范式,或者说不同的计算任务,对资源(如CPU、内存)的需求是不同的,因此需要优秀的调度策略,在满足应用的特殊需求的情况下,最大化利用资源,同时也需要做好任务之间的隔离,避免相互影响。

  在这种需求背景下,就产生了hadoop 2.0 ,主要就是分布式资源调度器Yarn,国内的话比较出名的就是阿里的fuxi系统。二者在架构上非常类似,下面做简单介绍。

  需要注意的是,yarn只是hadoop2.0的资源调度器,只负责资源的调度。由于资源调度与任务相互隔离,因此yarn支持更多的分布式计算模型,包括MapReduce,Spark,Storm等。

  Yarn的架构如下:

  

  在Yarn中,有以下组件

  ResourceManager:资源管理器,接收用户的请求,负载应用(application)的调度管理,启动应用对应的ApplicationMaseter,并为每一个应用分配所需的资源

  NodeManager:框架agent,在每一个计算机节点上都有一个,用于本机上的Container,监控机器的资源使用情况,并向ResourceManager汇报

  ApplicationMaseter(图中所有为App Mstr),每一个应用都有自己唯一的ApplicationMaseter,用于管理应用的生命周期,向ResourceMananger申请资源,监控任务对应的container

  Containner:具体任务task的计算单元,是一组资源的抽象,可用于以后实现资源的隔离

  其中,ResourceManager包含两个重要的组件,scheduler和ApplicationManager。scheduler负责为各种应用分配资源,支持各种调度算法,如 CapacityScheduler、 FairScheduler。ApplicationManager负责接收用于的请求,启动应用对应的ApplicationMaseter。

 

  阿里fuxi的架构与Yarn非常类似,如图所示

  

  可以看到:

  fuxi master对应Resourcemanager

  tubo对应NodeManager 

  AppMaster对应ApplitionMast

  AppWorker对应Container

 

  关于阿里的fuxi分布式调度,在阿里云大学和课堂在线都有视频课程,包含了许多细节,如详细的资源调度流程,各种调度策略,容错机制,应用的隔离等,值得看一看。

references

MapReduce: Simplified Data Processing on Large Clusters

Apache Hadoop YARN

分布式系统开发——调度技术

以上是关于初识分布式计算:从MapReduce到Yarn&Fuxi的主要内容,如果未能解决你的问题,请参考以下文章

Hadoop学习之路(十三)MapReduce的初识

初识Hadoop

分布式计算 MapReduce与yarn工作机制

初识Hadoop

初识hadoop

Hadoop2.2.0伪分布式之MapReduce简介