典型分布式系统分析：MapReduce

　　在 《分布式学习最佳实践：从分布式系统的特征开始（附思惟导图）》一文中，提到学习分布式系统的一个好方法是思考分布式系统要解决的问题，有哪些衡量标准，为了解决这些问题；提出了哪些理论、协议、算法，这些解决办法各自的优缺点、适用场景；而后再思考，不一样的系统是如何解决同一个问题的，好比说数据分片，好比说元数据的高可用，到了工程实践这个层面是怎么解决的。

　　上面是从问题出发，寻找答案。而另外一个方法，是从一个具体的系统出发，分析这个分布式系统是如何解决须要解决全部问题，如何根据实际状况对分布式特性进行权衡。好比说对于CAP，是如何在C（一致性）与A（一致性）之间折中的。所以，本系列文章的主题就是了解这些分布式系统是如何知足高性能、可扩展、高可用的通常性要求，各自的衡量标准，使用了哪些算法，有哪些设计巧妙、值得借鉴之处。

　　刘杰的《分布式系统原理介绍》一文中，也是介绍了分布式系统的诸多概念和协议，而后说道：

　　“即使如此，笔者以为后续能够再做一篇《典型分布式系统分析》，从各个系统的角度横向分析这些系统的特色。”

　　可是我在网上搜索并无发现相关的文章，本文冒昧地使用了这个题目，而我本身深知，在分布式领域我知之甚少，所以只算得抛砖引玉，但愿大牛多指正。若是业界前辈可以有时间来写写这个系列，那就更好了。

　　在这个系列中，通常都是根据论文对系统进行简介，而后尝试回答一下问题：　

● 　　系统在性能、可扩展性、可用性、一致性之间的衡量，特别是CAP
● 　　系统的水平扩展是如何实现的，是如何分片的
● 　　系统的元数据服务器的性能、可用性
● 　　系统的副本控制协议，是中心化仍是去中心化
● 　　对于中心化副本控制协议，中心是如何选举的
● 　　系统还用到了哪些协议、理论、算法

 

本文地址：http://www.cnblogs.com/xybaby/p/8878054.html

MapReduce简介

　　在google的论文《MapReduce: Simplified Data Processing on Large Clusters》中，MapReduce既指一种编程模型，又指google为这种编程模型开发的一套运行时框架。

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

　　在《初识分布式计算：从MapReduce到Yarn&Fuxi》一文中，已经对MapReduce进行了详细介绍，并且论文自己也很是容易读懂。因此在本文中，只重述一些重要的点 -- 决定了MapReduce这个系统的特征的点。

　　这里强调两个概念：Job  and Task。在MapReduce中，整个计算任务称之为Job，而被划分的子任务称之为task。Job是对用户而言的，而task是运行框架内部术语。

MapReduce运算模型

　　MapReduce编程模型来自函数式编程，包含两个最基本的算子：map，reduce

map： (k1, v1) -> [(k2, v2)]

reduce: [(k2, [v2] )] --> [(k3, v3)]

　　将一个运算任务分解成大量独立正交的子任务，每一个子任务经过map算子计算，获得中间结果，而后用reduce算子进行聚合，获得最终结果。这两个算子看起来简单，但不少问题都能用这个模型来解决。

　　这两个算子有一个很重要的特征：肯定性的纯过程调用（pure function），函数既不会修改输入，也不存在中间状态，也没有共享的内存。所以，输入一致的状况下，输出也是一致的，这大大方便了容错性设计。

MapReduce运行框架

　　运行框架的做用在于提升用户（在这里也是程序员）的生产力，用户只需经过map function、reduce function描述本身的计算问题，而不用关心计算在哪一个机器上进行、相互之间如何通讯、机器故障如何处理等复杂的问题，由于这些问题自己与计算任务不相关。

　　运行框架调度流程图以下：

　　

　　系统中有两类主要的进程节点：master（单点），worker（多个）。其中，worker根据不一样的计算任务，又分为map worker（对应上图中的Map phase）、reduce worker（对应上图中的Reduce phase）。

　　master是系统的中心节点，负责计算任务到worker节点的分配，同时监控worker节点的状态。若是某个worker计算太慢，或者宕机，master会将该worker进程负责的计算任务转移到其余进程。

　　map worker从GFS（google file system）中读取输入数据，而后将中间结果写到本地文件；reduce worker从master处得知中间结果的问题，经过rpc读取中间文件，计算以后将最终结果写入到可靠存储GFS。生产环境中，一个MapReduce过程的输出一般是另外一个MapReduce计算的输入，相似Unix 的 pipeline，只不过unix pipeline经过stdin、stdout链接两个程序，而MapReduce使用GFS链接两个计算过程。

MapReduce系统分析

　　MapReduce是一个分布式计算系统，计算的数据来自于文件，并且文件系统是可靠的（GFS保证了文件的可用性、可靠性）。

 Scalability

　　因为计算任务的正交性，很容易经过增长map worker、reduce worker来处理计算任务的增加。Input file 到 Map phase这个阶段，使用了基于范围（range based）的分片方法，master做为元数据服务器会记录split到worker的映射关系。当用户指定R份最终输出（也就是reduce worker的输出）时，如何对中间结果（intermediate files）进行划分呢？系统默认提供了hash分片方法(e.g. hash(key) mod R)， 也容许用户自行提供partition function来进行划分。

　　在Mapreduce中，子任务（task）的数量要远小于worker的数量，这样的好处在于更好的负载均衡、更快的故障恢复。

We subdivide the map phase into M pieces and the reduce phase into R pieces, as described above.

Ideally,M and R should be much larger than the number of worker machines.

Having each worker perform many different tasks improves dynamic load balancing, and also speeds up recovery when a worker fails: the many map tasksit has completed can be spread out across all the other worker machines. 

　　系统的scalability主要受到master的约束，master是系统中的单点，须要维护每一个计算子任务（task）的状态，与全部的worker保持心跳，记录map worker计算的中间结果的文件位置。

 Availability

　　系统对worker的容错性较好，但对master的容错性较差。

　　master经过心跳来保证肯定worker是否存活，若是心跳超时，那么master标记这个worker failed，而后将该worker所负责的全部task设置为idle（等待计算）状态。在《关于心跳、故障监测、lease机制》一文种中，提到了心跳检测只能保证完整性（completeness），没法保证准确性（accuracy），接下来后分析到，在MapReduce，不许确也是没有关系的。

　　对于map worker，计算结果是写到本地文件，本地文件的位置须要通知到master，即便同一个task被多个map worker执行，单点的master只会采纳一份中间结果。并且上面提到了map function是pure function，因此计算结果也是同样的。

　　对于reduce worker，reduce task的计算结果会先写到临时文件（temporary file），task完成以后再重命名写入gfs，那么若是一个reduce task再多个reduce worker上计算，那么会不会有问题呢，答案是不会的

　　We rely on the atomic renameoperation provided by the underlying file system to guarantee that the final file system state contains just the data produced by one execution of the reduce task.

　　而因为master是单点，即便有周期性的checkpoint也可能形成状态的不一致，所以MapReduce会将master的crash告知用户，用户可自行决定是否重试整个计算。

Performance

　　MapReduce做为离线计算平台，更多关注的是系统的吞吐率，那么有哪些提升性能的点呢

第一：data locality

　　在论文中提到，网络传输代价是昂贵的，因此若是worker能从本地文件系统读取数据的话就能尽量的少网络传输。这也归功于GFS系统，GFS以chuck（对应的就是Input file split）的粒度将每一份文件在不一样的机器上保存三份。那么master在掌握了chunk的位置时，就能够将map worker调度到相应的机器，避免网络传输。

第二：backup task

　　master在发现某个worker上的task进展异常缓慢的时候，会将这个task调度到其余worker，以缩短这个任务（Job）的完成时间。在上面avaliability已经提到，即便有两个worker执行同一份task，也不会有问题的。

总结

　　MapReduce提供了一个简单但强大的编程范式与运行环境，是一个离线分布式计算系统。MapReduce的最大优势在于易于使用、伸缩性很好。相比分布式存储，分布式计算的状态更少(worker上没有须要维护的上下文环境），所以不会出现严重的一致性、可用性问题。直接增长更多的节点就能解决扩展性问题，因为计算的肯定性，经过简单重试就能解决不少可用性问题。

references

分布式系统原理介绍

MapReduce: Simplified Data Processing on Large Clusters

The Google File System

6.824 Schedule: Spring 2016 LEC 1