前情回首

Google MapReduce到底解决什么问题?
Google MapReduce是Google产出的一个编程模子,同时Google也给出架构实现,它能够解决“能用分治法解决的问题”。

Google MapReduce有啥巧妙优化?

  • 分区函数:保证差别map输出的相同key,落到同一个reduce里
  • 合并函数:在map竣事时,对相同key的多个输出做内陆合并,节约总体资源
  • 输入文件到map若何切分:随意,切分平均就行
    画外音:看懂了这个流程,对工程架构的明白,会容易许多。

上述执行流程,Google MapReduce通过怎样的工程架构实现的呢?


先看下总体架构图,有个直观的印象。

用户使用GoogleMR系统,必须输入的是什么?

  • 输入数据,必选
    画外音:否则系统处置啥。
  • map函数,必选
  • reduce函数,必选
    画外音:分治法,分与合的营业逻辑。
  • 分区函数,必选
    画外音:保证同一个key,在合并阶段,必须落到同一个reduce上,系统提供默认hash(key)法。
  • 合并函数,可选
    画外音:看用户是否需要在map竣事阶段举行优化。

用户提供各个输入后,GoogleMR的执行流程是什么?

画外音:
不妨假设,用户设置了M个map节点,R个reduce节点;例如:M=500,R=200

(1) 在集群中建立大量可执行实例副本(fork);

(2) 这些副本中有一个master,其他均为worker,义务的分配由master完成, M个map实例和R个reduce实例由worker完成;

(3) 将输入数据分成M份,然后被分配到map义务的worker,从其中一份读取输入数据,执行用户的map函数处置,并在内陆内存天生暂且数据;

(4) 内陆内存暂且数据,通过分区函数,被分成R份,周期性的写到内陆磁盘,由master调剂,传给被分配到reduce义务的worker;

(5) 卖力reduce义务的worker,从远程读取多个map输出的数据,执行用户的reduce函数处置,处置效果写入输出文件;
画外音:可能对key要举行外部排序。

(6) 所有map和reduce的worker都竣事事情后,master叫醒用户程序,MapReduce挪用返回,效果被输出到了R个文件中。

GoogleMR系统里的master和worker是啥?

(1) master:单点master会存储一些元数据,监控所有map与reduce的状态,纪录哪个数据要给哪个map,哪个数据要给哪个reduce,掌控全局视野,做中控;
画外音:是不是和GFS的master异常像?
(2) worker:多个worker举行营业逻辑处置,详细一个worker是用来执行map照样reduce,是由master调剂的;
画外音:是不是和事情线程池异常像?这里的worker是漫衍在多台机械上的而已。

master的高可用是若何保证的?

一个简朴的方式是,将元数据固化到磁盘上,用一个shadow-master来做高可用。
画外音:GFS不就是这么干的么?

然而现实情形是:没有将元数据固化到磁盘上,元数据被存放在master的内存里用以提高事情效率,当master挂掉后,通知用户“义务执行失败”,让其选择重新执行。
画外音:
(1) 单点master,掌控全局视野,能让系统的复杂性降低异常多;
(2) master挂掉的概率很小;
(3) 不做高可用,能让系统的复杂性降低异常多;

,

以太坊数据网

www.326681.com采用以太坊区块链高度哈希值作为统计数据,联博以太坊统计数据开源、公平、无任何作弊可能性。联博统计免费提供API接口,支持多语言接入。

,

worker的高可用是若何保证的?

master会周期性的ping每个worker,若是超时未返回,master会把对应的worker置为无效,把这个worker的事情义务重新执行:

  • 若是重新执行的是reduce义务,不需要有分外的通知
  • 若是重新执行的是map义务,需要通知执行reduce的worker节点,输入数据换了一个worker

随时都可能有map或者reduce挂掉,义务完成前重新被执行,会不会影响MR的最终效果?

在用户输入稳定的情形下,MR的输出一定是稳定的,这就要求MR系统必须具备幂等性:

  • 对相同的输入,不管哪个卖力map的worker执行的效果,一定是稳定的,产出的R个内陆输出文件内容也一定是稳定的
  • 对于M个map,每个map输出的R个内陆文件,只要这些输入稳定,对应吸收这些数据的reduce的worker执行效果,一定是稳定的,输出文件内容也也一定是稳定的

长尾效应怎么解决?

一个MR执行时间的最大短板,往往是“长尾worker”。

导致“长尾worker”的缘故原由有许多:
(1) 用户的分区函数设计得不合理,导致某些reduce负载不均,要处置大量的数据;
画外音:
最坏的情形,所有数据最终都落到一个reduce上,漫衍式并行处置,转变为了单机串行处置;
以是,分区函数的负载平衡性,是用户需要思量的。

(2) 由于系统的缘故原由,worker所在的机械磁盘坏了,CPU有问题,也可能导致义务执行很慢;

GoogleMR有一个“备用worker”的机制,当某些worker的执行时间超出预期时,会启动另一个worker执行相同的义务,以实验解决长尾效应。

总结
Google MapReduce架构,提现了许多经典架构实践:

  • 单点master简化系统复杂度
  • 单点master不高可用,简化系统复杂度
  • master对worker的监控以及重启,保证worker高可用
  • 幂等性,保证效果的正确性
  • 多个worker执行同一个义务优化长尾问题


架构师之路-分享可落地的技术文章

相关推荐:
《GFS架构启示》
《Google MapReduce解决什么问题?》
《Google MapReduce巧妙优化思绪?》
《过载珍爱+异构服务器的负载平衡》
《程序员养女儿的四大要点!》

作业:
MR中有大量的数据举行传输,若何举行优化呢?