MapReduce 计算模式

声明：本文摘录自《大数据日知录——架构与算法》一书。

较常见的计算模式有4类，实际应用中大部分ETL任务都可以归结为这些计算模式或者变体。

1.求和模式

　　a.数值求和

　　比如我们熟悉的单词计数，即使该模式的一个应用。求最大最小值，求平均值皆属此类。

　　b.记录求和

　　非数值内容的累加，形成队列。比如将包含某个key的网页添加到一个列表当中。

2.过滤模式

　　不对数据进行转换，只是从大量数据中筛选。

　　a.简单过滤

　　这类应用不需要对数据进行聚合（原因不复杂），所以无需reduce阶段。

　　b.Top 10

　　和简单过滤的差异在于：简单过滤的条件判断只涉及当前记录，而Top k计算模式需要在记录之间进行比较，并获得全局最大的子集。

　　思路：map =>local top k =>reduce =>overall top k

3.组织数据模式

　　a.数据分片

　　重点在partitioner策略的设计上，通过改变partitioner来将相同标准的数据经过Shuffle过程放到一起，由同一个reducer 来输出。

　　问题来了，这该如何实现呢？

　　考虑到partitioner是可以自定义的（这TM不废话么），那么，我们可以在partitioner内部实现对数据的分析，然后将其输出到不同的partition中。

　　b.全局排序

　　可以直接利用内置排序过程，也就是说，mapper只需要将要排序的字段作为key，记录内容作为value输出即可。

　　reducer其实也不需要做额外的任务，因为sort过程已经排好序了。（有一个问题，假如我对排序算法不满意怎么办？一个办法是自定义key，也就是自定义一个WritableComparable接口的类，并且根据需求实现里面的compareTo方法）

　　如果有不止一个reducer怎么办？如果不做额外的处理，排序结果就会成为局部排序。

　　有办法：Partitioner，可以将处于不同区间的key放在不同的Partition，相同区间的Key放在同一Partition。

4.Join模式

　　a.Reduce-Side Join

　　这个过程对于笔者而言比较复杂，所以这个主题会耗费较多文字。

　　在选定外键之后，所有相同外键的数据分配到了同一个Reducer。需要注意的是如何区分来自不同数据集合的记录？一个显而易见的办法是在Mapper阶段动动手脚：给记录做标记，放在Value中。

　　然后，将reducer的Value list根据集合的不同整合成2个列表（或者哈希表，其实就是一个查询效率的问题，想怎么搞就怎么搞），然后再将这些数据进行Join。

　　多说一句：整个过程需要经过数轮磁盘的读写，shuffle阶段的网络传输，以及Reduce阶段的排序，所以计算效率比较低。（意思就是Mapper几乎什么事都没干，却因为IO的问题而导致时间效率低）

　　b.Map-Side Join

　　好了，效率低的解决办法来了；不过有前提条件：数据集合一个大一个小，并且小的那个完全可以放入内存。

　　读者朋友，读到这里你应该想明白Map-side Join是怎么回事了吧！

这个问题到此告一段落！