莎士比亚文集词频统计并行化算法，莎士比亚词频

莎士比亚文集词频统计并行化算法，莎士比亚词频

      大家好，好久没没更新Spark类容了，主要是最近考试比较多。今天先给大家展示一个实战案例，这个案例是我在今年参加第一届高校云计算应用

创新大赛时技能赛第四题——莎士比亚文集词频统计并行化算加法。PS:感谢师兄辉哥，真大神！

题目是这样的（这里截图展示出来）：

在这里停词表的作用是对于在该表中的单词不予以统计，一般而言停词表中的单词是出现频率比较高的单词（如the）。这个案例比较简单，但

有的人的思路可能是这样的：先对莎士比亚文集进行wordcount操作统计出各个单词的出现频率，然后对wordcount中的结果过滤掉在停词表

中出现的单词，最后找到出现频率最高的100个即可。这种方式可行，但效率略低。大家知道wordcount包含shuffle操作，shuffle所带来的IO是spark

性能的瓶颈。我们在写程序的时候应该尽可能的较少shuffle IO，那么如何减少shuffle IO呢，在这里我们可以尽量减少要参与shuffle操作的数据。

所以，优化的思路是对莎士比亚文集进行单词分片后就进行过滤操作，过滤掉在停词表中得单词，然后进行wordcount操作。这样一来我们可以

过滤掉大量出现频率很高的词汇从而减少了主要shuffle IO。可能有的同学会问那这里的filter操作岂不是比上面的思路中filter操作需要处理的单词书更

多，确实是这样。但是对性能没有任何影响，为什么这么说？大家知道spark的一个优良的特点就是它的pipeline(血统)，我们的处理在每一个shuffle

操作之 前都会算作一个同一个stage,在这个satge中的计算都是在最后的action时才进行的，血统就是具有这一优良特性。那么对每一个partiton上的

文本进行单词切割后进行filter操作是不是具有pipeline的特性？是不是这两个操作就像血液一样瞬间流过你的血管中的两个细胞？是不是几乎是同时发

生？是不是没有任何性能影响？

此外，我们还可以将规模较小的停词表放在一个hash表中，hash查找的效率几乎为单位时间（大家一定要多关注hash的原理,前几天百度面试包

含了很多hash类容）。

说了这么多，下面贴出源码：

在后面我会提供包含技能赛第三题以及其他的案例详解。希望大家共同学习讨论。 （by老杨，转载请注明出处）