Data-Intensive Text Processing with MapReduce第三章（1）-MapReduce算法设计-简介
大量高效的MapReduce程序因为它简单的编写方法而产生：除了准备输入数据之外，程序员只需要实现mapper和ruducer接口，或加上合并器（combiner）和分配器（partitioner）。所有其他方面的执行都透明地控制在由一个节点到上千个节点组成的，数据级别达到GB到PB级别的集群的执行框架中。然而，这就意味着程序员想在上面实现的算法必须表现为一些严格定义的组件，必须用特殊的方法把它们整合起来。大量算法的不会很简单就能转换成这种编程模型。这章的目的主要是提供一些MapReduce算法的设计例子。这些例子说明了MapReduce的设计模式，组件的例示准备和特殊技术去解决的经常遇到的各种领域的不同问题。其中的两种设计模式将会在第四章中的伸缩性反向索引算法中展示；这章展示的概念也会在第五章（图处理）和第六章（获得期望最大值算法）中出现。
同步可能是设计MapReduce算法（一般来说，通常是并行和分布式算法）中最棘手的部分。不同于令人尴尬的并行问题，运行在同一集群不同节点的进程必须及时到达某些节点集合。例如，在节点中分配部分结果到需要的节点上。在一个简单的MapReduce job中，只有一次机会给整个集群同步-----在shuffle（清洗）和sort（排序）阶段中的中间key-value键值对以key分类从mappers复制到reducers的时候。除了上述情况，mappers和reducers独立地运行着，没有任何机制来使他们直接通信。而且，程序员在程序执行时可控制的方面很少，例如：
mapper、reducer运行在那里？（在那个节点）
什么时候mapper、reducer开始或结束？
一个输入键值对由具体那一个mapper处理？
一个中间键值对由具体那一个reducer处理？
然而，有一些技术可以用来控制执行和管理MapReduce中的数据流，总的来说它们是：
1. 构建复杂数据结构作为键和值来存储并和部分结果交互。
2. 在map或reduce任务开始前执行用户自定初始化代码和在map或reduce任务结束前执行用户自定终止代码。
3. 在mappers和reducers传入多样输入或中间值时保持状态。
4. 控制中间值的排序，使reducer会遇到特定的键。
5. 控制键空间的分配，使reducer会遇到特定的键。
要意识到很多算法并不能简单的转换成一个MapReduce的job。它必须经常把复合的算法分解到一个job序列，并需要把一个job中的输出数据变成下一个job的输入数据。很多算法实质上是迭代，它需要重复计算直到达到一些收敛准则-----第五章的图算法和第六章的最大期望值算法就是这种情况。在大多数情况下，收敛的自我检查在MapReduce中不容易实现。普遍的解决方案是用一个外部（非MapReduce）程序作为一个驱动器来协调MapReduce迭代。
这章解释了在Mapduce中怎样用各种技术来控制代码执行和可以用于设计算法的数据流。关注于扩展性---确保算法在应用到不断增长的数据集时没有瓶颈并且高效---确保算法不会因消耗额外的资源由此降低了并行的价值。黄金法则，当然是线性的可伸缩性：算法对于两倍的数据量需要两倍的时间来执行，同理，对于由两倍的节点数执行时间应该减半。
此章组成结构如下：
3.1节介绍了MapReduce中局部聚集的重要概念和一些策略来设计高效的算法来最小化必须通过网络传输的部分结果的数据量。合并器（combiner）的合理使用和(map内合并)in-mapper combining模式也会详细讨论。
3.2节用在大文本集合中建立词语同现矩阵来阐述两个常见的设计模式，我们称为pairs和strips。这两种方法在需要通过大量的观测值跟踪共同事件这类问题很有用。
3.3节展示了同现计数（co-occurrence counts）是怎样用顺序倒转模式转换成相关频率的。Reducer中的计算顺序会被转换为一个排序问题，中间数据被排成序来进行一系列的计算。常常一个reducer需要在单独的元素被加工之前计算一套元素总的统计量。通常，这会被置之不理，但对于“顺序倒转”模式，总数统计应该在单独元素到来之前被计算。这会被认为是违反直觉的：怎样能让我们在单独的元素被加工之前计算一套元素总的统计量？事实的结果是，智能的对特殊的键值对进行排序就能做到。
3.4节提供一个二次排序的常规解决办法，问题的关键是在reduce阶段把键对应的值排序。我们把这种技术称为“键值转换（value-to-key conversion）”。
3.5节涉及到在相关的数据集中执行joins的方法和演示3个不同的方法：reduce端连接, map端连接和基于内存的连接。