从芒果分装角度---看MapReduce流程

从芒果分装角度-看MapReduce流程

背景

有一芒果产销基地，园区内有芒果种植园(产), 芒果分装库(装)，芒果销路(销)。

芒果种植园即HDFS中的文件，这个种植园规模很大，有不同的山头，假设一个山头一个分区。

芒果的品质不同、个头不同、成熟度不同，价格和可以销往的地点不同。

芒果产销基地需要知道不同时段芒果的品质、销售额，以对企业决策做出调整、吸引投资。

芒果季到了，用户已有预定，战斗开始了。

MapReduce流程

输入切片

不同山头位于芒果分装库的四周，属于不同山头的火车从不同方向，将芒果拉到芒果分装库。

​ 现在假设a山头的一车芒果运达分装库，按照以往的经验，三个工人稳定高效地分装一车芒果。三名工人分别负责芒果车的前部、中部和后部芒果。即逻辑切片过程，并不是真的把车切开，而是一个工人负责一个区域。

​ 因为车装的量有多有少，有的前部多一点，只要不超过数据块的1.1倍，工人也不会有怨言。

​ 而如果b车装的量太少，每个工人还是处理车的一部分，那么其他车的工人干的活儿就比这个车的人多。芒果的总数是一定的，工人的总数也是一定的，活儿多的工人就会有怨言了，最后也会影响整体的工作效率。（即小文件太多的问题）

• 小文件问题：
  • 增加map的开销，每一个分片就要执行一次map
  • 增加作业寻址时间
  • Namenode需要记录元数据，浪费Namenode内存

map阶段

因为要根据芒果的品种分类，所以分装库会提前打印好不同的芒果袋。

​ 工人将芒果贴上小贴纸（就是香蕉上的那种小标签，记录了当前芒果值多少钱),即map阶段将芒果处理成想要的模式(k-v对)。然后将芒果放到框(环形缓冲区）中，框快满了的时候，就根据芒果的品类、大小等，按照顺序(快排、外部排序)放到不同的分类区,这是若出现大小品类完全一样的芒果，则先装成一块儿(conbiner)。分类区的芒果多了之后，产生很多的小堆儿，不好管理，就把同一类的放到纸箱装好(小文件merge，conbiner)。

shuffle阶段

​ map阶段和reduce阶段之间的阶段为shuffle阶段。

​ 一个切片对应一个map任务，一个分区对应一个reduce任务。

​ 我的理解是，就是将不同map阶段的输出(因为一个车分出了多种芒果嘛)，发往不同的reduce处理(每个reduce只处理一种或者特定几种类型的芒果)。

reduce阶段

不同品类的芒果，发往不同的地方。

​ reduce通过MRAppmaster获取“从哪台机器获取map输出”.MRAppmaster负责任务调度和监控，map结束会通知MRAppmaster，Reduce也会定期询问MRAppmaster以便获取map输出的位置。

​ 由于map阶段已经将芒果分好类、分区内有序。每个reduce只聚合特定种类(或者几种)的芒果。reduce就从不同的车边拿芒果箱子，放到车上运输车上，然后根据芒果标签进行计算总价格。

​ 由于reduce阶段从不同的map阶段获取芒果，map阶段内的芒果有序，但是不同map阶段之间的芒果不一定有序。所以reduce阶段要将不同map阶段获取的芒果进行一次归并排序。

几次排序&为什么排序

• map阶段溢写排序(快排、外部排序，根据key排)
• 小文件合并排序(已经有序了，所以用归并排序)
• reduce阶段从多map获取排序(归并排序)

至于为什么排序，因为一开始mapreduce是为了大数据排序而生的。

MR在reduce阶段需要分组，将key相同的放在一起进行规约，为了达到该目的，有两种算法：hash map和sort，前者太耗内存，而排序通过外排可对任意数据量分组，只要磁盘够大就行。map端排序是为了减轻reduce端排序的压力。在spark中，除了sort的方法，也提供hash map，用户可配置，毕竟sort开销太大了。

参考

Hadoop的MapReduce阶段为什么要进行排序呢，这样的排序对后续操作有什么好处么？

后记

​ 感觉写着写着，芒果的浓度就不高了哈哈哈