MapReduce 算法设计(二)--- Pairs 和 Stripes

之前提到从MapReduce 可控和不可控的方面我们可以挖掘出一些有用的设计模式。在可控方面Key 和Value 数据结构的自定义给了我们很大的发挥空间。
本篇要讲述的就是Pairs 和Stripes 。这两种设计模式并没有利用MapReduce 的框架机制，而是巧妙的利用数据结构来实现的。但是依然可以利用我们之前提到的Combiner 和In-Mapper Combining 来进行效率优化。
 在日常应用中，我们通常想要从大数据集中挖掘出一些有用的关联模式。比如大型零售机构想要从他们的销售记录中挖掘出一些关联销售(比如用户购买了A产品，很大可能性上会买B产品)。这样的挖掘是非常有用的，比如在货物架上摆放时可以将A和B放在一起或者将A和B进行捆绑销售。而接下来要讨论的Pairs 和Stripes 对这种关联模式的挖掘是非常有效的。
为了更加简单的描述算法，我们这里用单词共现矩阵作为例子来讲述。很显然单词共现算法的空间复杂度为O(n2)。这里的n即为所有文集中单词出现的个数。对于大文集或者是互联网规模的数据来说，这个n无疑是非常大的。以至于大到无法在单机上运行，使用MapReduce 并行处理无疑是在恰当不过了。
首先我们来看下单词共现的Pair 的算法伪码：
1: class Mapper
2:      method Map(docid a; doc d)
3:      for all term w in doc d do
4:                for all term u is Neighbors(w) do
5:                         Emit(pair (w; u); count 1) .  // Emit count for each co-occurrence
1: class Reducer
2:      method Reduce(pair p; counts [c1; c2; : : :])
3:               s = 0
4:               for all count c in counts [c1; c2; : : :] do
5:                         s = s + c                           //Sum co-occurrence counts
6:                Emit(pair p; count s)
 
从上面的算法可以看出，这里求文集中的单词共现并没有利用MapReduce 本身的机制，而是通过设计良好的数据结构来完成的。
我们在来看下单词共现的Stripes的算法伪码：
 
1: class Mapper
2:    method Map(docid a; doc d)
3:             for all term w in doc d do
4:                       H = new AssociativeArray
5:             for all term u is Neighbors(w) do
6:                       H{u} = H{u} + 1                       // Tally words co-occurring with w
7:             Emit(Term w; Stripe H)
1: class Reducer
2:     method Reduce(term w; stripes [H1;H2;H3; : : :])
3:             Hf = new AssociativeArray
4:             for all stripe H in stripes [H1;H2;H3; : : :] do
5:                       Sum(Hf ;H)                     //Element-wise sum
6:             Emit(term w; stripe Hf)
 
 
2.1 Pairs 和 Stripes 分析比较

从上面Pairs 和 Stripes 的伪码可以看出，它们都实现了单词共现的需求，但是实现方法有所不同。
举个例子：假设现在篇文档的Id =“001”文档的内容为Content=“big data analytics is important”。(这里我们不考虑单词共现的先后关系)。
Pairs 的Mapper阶段产生的数据如下：
{(big, data);1}        {(big, analytics);1}        {(big, is);1}         {(big, important);1}
{(data, analytics);1}   {(data, is);1}             {(data, important);1}
{( analytics, is);1}     {( analytics, important);1}
{( is, important);1}
而Stripes的Mapper阶段产生的数据如下：
{big;        (< data ,1>,< analytics,1 >,< is,1 >,< important,1 >)}
{ data;      (< analytics,1 >,< is,1 >,< important,1 >)}
{ analytics;  (< is,1 >,< important,1 >)}
{ is;        (< important,1 >)}
从上面两个算法产生的中间数据来看：Pairs 和 Stripes 各有优缺点：
(1)  Pairs 和Stripes 相比会有更多的中间结果产生，就上面的例子来说Pairs 的Mapper阶段产生的中间Key/Value 就有10个，而Stripes 的中间结果只有4个。若有之前讲的Combiner 和In-Mapper Combining 来优化中间结果，Stripes的优化效率比Paris会高很多的。因为Paris 的Key更加复杂。优化的效率会更低。
(2)  但是从可拓展性上来说，Pairs 比Stripes 有更高的拓展性，因为Paris 产生的Key/Value 的大小总是很小的，所以Paris几乎不存在拓展性问题。但是对于Stripes就不同了。Stripes 产生的Key/Value 的大小依据整个文集的大小。当文集很大时，一个Key/Value 的Value就会非常的大，有可能一个Mapper无法处理。这样拓展性能问题就显而易见了