前言
虽然mapreduce几乎已经被淘汰，但是他的原理机制还是需要去了解深挖的，他的分而治之的理念差不多是贯通整个大数据的框架的，spark，flink都借鉴了其分而治之的理念，下面是我总结的mapReduce的模型，结构，以及原理。写的不好，请见谅！！！虽然mapreduce几乎已经被淘汰，但是他的原理机制还是需要去了解深挖的，他的分而治之的理念差不多是贯通整个大数据的框架的，spark，flink都借鉴了其分而治之的理念，下面是我总结的mapReduce的模型，结构，以及原理。写的不好，请见谅！！！
Mapreduce1.0
Client：编写mapreduce程序，配置作业，提交作业，这就是程序员完成的工作；
JobTracker：JobTracker只有一个，一般情况应该把JobTracker部署在单独的机器上,类似于namenode，每个应用程序被表示成一个作业，每个作业又被分成多个任务，JobTracker的作业控制模块则负责作业的分解和状态监控,简单来说：jobTracker管理折map，reduce搜友任务的启动，以及所有资源的调配。
TaskTracker：TaskTracker是运行在多个节点上的slaver服务。TaskTracker主动与JobTracker通信，接收作业，并负责直接执行每一个任务。本地节点上各个任务的状态通过心跳周期性汇报给JobTracker，节点健康情况、资源使用情况，任务执行进度、任务运行状态等，比如说map task我做完啦，你什么时候让reduce task过来拉数据啊。从JobTracker接收并执行各种命令：运行任务、提交任务、杀死任务等
总体步骤
- input：也就是数据存储位置，这里当然是类似于hdfs这样的分布式存储啦，
- split：因为maptask只读split，而split基本上和hdfs的基本存储块block同样大小，一个split对应一个map，你可以把它当做map的单位块来理解，投喂进map的时候必须要这样的格式。
- List itemmap：这里做的是wordcount，而map程序是由程序原来编写的。
- shuffle：这是一个比较核心的过程，shuffle有洗牌的意思。
-
List itemreduce：既然都说了似wordcount了。
细化过程
mapTask读取inputSplit的数据，通过map接口，读入的数据为key为在行在这个文件中的offset，value为行数据，通过map接口转换为key为数据，value为你的需求格式的数据，此时数据写入内存区，当内存区数据量过大，此时通过溢写，数据写入磁盘，此时会通过key mod/reduce个数，分出不同的partition，每个分片还会进行排序以combiner（小规模的归并数据），当map执行完成，这时候进行一个大规模的归并，相同位置的partition进行归并，提交reduce作业，最后输出作业
Map阶段：
输入数据的解析：InputFormat
输入数据处理：Mapper
输入分组：Partitioner
本节点的规约：Combiner
Reduce阶段：
Shuffling阶段拉取数据
桶排序，是一个hash过程，使得相同的Key可以排在一堆
数据规约：Reducer
数据输出格式： OutputFormat
数据本地化
map操作都是本地化操作也就是在数据存储节点上进行，将map任务分配给含有该map处理的数据块的TaskTracker，其实就是任务运行在他将处理数据所在的节点上。其实发展到现在，内存已经足够大，cpu计算能力也很强，真正的瓶颈是磁盘io，网络io。同节点>同机架>其他 ，数据本地化可避免跨界点以及跨机架的数据传输，提交运行效率。
memory Buffer ：这是一个环形的缓冲区。map task输出结果首先会进入一个缓冲区内，这个缓冲区的大小是100MB，如果map task内容太大，是很容易撑爆内存的，所以会有一个守护进程，每当缓冲区到达上限80%的时候，就会启动一个Spill(溢写)进程，它的作用是把内存里的map task的结果写入到磁盘。这里值得注意的是，溢写程序是单独的一个进程，不会影响map task的继续输出。当溢写线程启动后，需要对这80MB空间内的key做排序(Sort)。排序是MapReduce模型默认的行为，这里的排序也是对序列化的字节做的排序。
**partition：**partition是分割map每个节点的结果，按照key分别映射给不同的reduce，也是可以自定义的。这里其实可以理解归类。只不过在写程序的时候，mapreduce使用哈希HashPartitioner帮我们归类了。默认是hash(key)%R哈希函数分散到各个reducer去
Combiner：如果client设置过Combiner，那么现在就是使用Combiner的时候了。将有相同key的key/value对的value加起来，减少溢写到磁盘的数据量，combiner简单说就是map端的reduce！。Combiner的输出是Reducer的输入，Combiner绝不能改变最终的计算结果。Combiner的使用一定得慎重，如果用好，它对job执行效率有帮助，反之会影响reduce的最终结果。
Merge：每次溢写会在磁盘上生成一个溢写文件，如果map的输出结果真的很大，有多次这样的溢写发生，磁盘上相应的就会有多个溢写文件存在。当map task真正完成时，内存缓冲区中的数据也全部溢写到磁盘中形成一个溢写文件。最终磁盘中会至少有一个这样的溢写文件存在(如果map的输出结果很少，当map执行完成时，只会产生一个溢写文件)，因为最终的文件只有一个，所以需要将这些溢写文件归并到一起。
Copy过程: Reduce会接收到不同map任务传来的数据，并且每个map传来的数据都是有序的。Reduce进程启动一些数据copy线程(Fetcher)，通过HTTP方式请求map task所在的TaskTracker获取map task的输出文件。因为map task早已结束，这些文件就归TaskTracker管理在本地磁盘中。
Merge: 这里的merge如map端的merge动作，只是数组中存放的是不同map端copy来的数值。Copy过来的数据会先放入内存缓冲区中，这里的缓冲区大小要比map端的更为灵活，它基于JVM的heap size设置，因为Shuffle阶段Reducer不运行，所以应该把绝大部分的内存都给Shuffle用。这里需要强调的是，merge有三种形式：1)内存到内存 2)内存到磁盘 3)磁盘到磁盘。默认情况下第一种形式不启用，让人比较困惑，是吧。当内存中的数据量到达一定阈值，就启动内存到磁盘的merge。与map 端类似，这也是溢写的过程，这个过程中如果你设置有Combiner，也是会启用的，然后在磁盘中生成了众多的溢写文件。第二种merge方式一直在运行，直到没有map端的数据时才结束，然后启动第三种磁盘到磁盘的merge方式生成最终的那个文件。
Reducer的输入文件：不断地merge后，最后会生成一个“最终文件”。为什么加引号？因为这个文件可能存在于磁盘上，也可能存在于内存中。对我们来说，当然希望它存放于内存中，直接作为Reducer的输入，但默认情况下，这个文件是存放于磁盘中的。当Reducer的输入文件已定，整个Shuffle才最终结束。
MapReduce2.0运行在YARN之上。YARN
Client ：用户通过Client与YARN交互，提交MapReduce作业，查询作业运行状态，管理作业等
MRAppMaster ：功能类似于 1.0中的JobTracker，但不负责资源管理，任务划分、资源申请并将之二次分配给Map Task和Reduce Task、任务状态监控和容错，注意这里涉及对RM的两次资源申请，第一次申请是用于启动一个MRAppMaster，来管理这次MR Task, 第二次申请用于申请Map Task和Reduce Task需要的资源（每申请成功一个都会启动一个）
执行流程：Client向ResourceManager提交一个mr作业，ResourceManager会找一个空闲的机器（NodeManager）用来启动MRAppMaster，MRAppMaster会ResourceManager请求资源，获取到资源，联系NodeManager启动mapTask任务。
倒排索引：在搜索引擎中每个文件都对应一个文件ID，文件内容被表示为一系列关键词的集合（实际上在搜索引擎索引库中，关键词也已经转换为关键词ID）。例如“文档1”经过分词，提取了20个关键词，每个关键词都会记录它在文档中的出现次数和出现位置。
当用户在主页上搜索关键词“华为手机”时，假设只存在正向索引（forward index），那么就需要扫描索引库中的所有文档，找出所有包含关键词“华为手机”的文档，再根据打分模型进行打分，排出名次后呈现给用户。因为互联网上收录在搜索引擎中的文档的数目是个天文数字，这样的索引结构根本无法满足实时返回排名结果的要求。
所以，搜索引擎会将正向索引重新构建为倒排索引，即把文件ID对应到关键词的映射转换为关键词到文件ID的映射，每个关键词都对应着一系列的文件，这些文件中都出现这个关键词。
https://blog.csdn.net/zsd_31/article/details/79979818
面试问题收集
https://blog.csdn.net/WYpersist/article/details/80102778