声明：本文摘录自《大数据日知录——架构与算法》一书。
较常见的计算模式有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是怎么回事了吧！
这个问题到此告一段落！