关于MapReduce的一些想法|青训笔记

这是我参与「第四届青训营 」笔记创作活动的的第2天，在昨天的课程中，反复的看见mapreduce这个概念，刚开始只简单将其理解为是一个负责分布式处理的函数，但随着对昨天课程内容的复盘发现仍需要对其进行更加深入的理解。

首先关于什么是MapReduce：

mapreduce这个过程又可以拆分为map和reduce这两个过程： map即将一堆复杂、大量的数据/文件拆分为多个小的、易处理的子数据块，进而方便将这些子数据给多个分布式结算节点进行计算 而

reduce即将多个map离散处理的计算结果进行整合，从而得到最终的结果

MapReduce的工作机制是什么：

从图中可以看见，在这个过程中主要包括了四个参与者：

实体一：客户端，用来提交MapReduce作业。

实体二：JobTracker，用来协调作业的运行，主要负责协调作业的任务调度

实体三：TaskTracker，用来处理作业划分后的任务，主要负责处理JobTracker调度给它的具体的作业

实体四：HDFS，用来在其它实体间共享作业文件

总体过程首先由客户端提交待处理的作业，随后在jobtracker放进行对作业的初始化，并将作业拆分为数个任务，分配给多个tasktracker进行具体的处理，之后在作业执行阶段，Map首先对大任务进行分解处理,Reduce最后再将处理的结果返回给前端客户

思考和总结

对于MapReduce,其作为Hadoop中重要的分布式处理框架，对于分布式系统的“分治”思想的发展起了重要的意义。但是并不是所有的文件都能够采用MapReduce的处理方式，比如文件本身不能够拆分的话就不能进行mapreduce处理。

同时map和reduce也并不一定配对出现，由于文件的大小往往是不可控的，因此map的输入往往使我们不可控的，但是map的输出作为reduce的输入则使我们可以控制的了，因此我们便可以通过控制reduce的数量来控制输出结果的数量，比如将reduce设置为0的话，那么map输出的就是最终的结果而不再经过reduce操作了