聊一聊MapReduce计算模型

        在大数据技术生态里，MapReduce思想是各种大数据计算引擎的理论基础。从Hadoop MapReduce到Spark，再到Flink，MapReduce思想的运用已经非常成熟。正是因为它是一个非常基础的东西，值得单独拿出来聊一聊。

        在理解MapReduce模型之前，先来看一个有意思的问题：

        有一个url文件，共10亿行，平均每个url长度为64字节。求每个url出现的频次。

        条件：内存1G，磁盘1T。

笔者作为大数据面试官，问过很多做过数据开发工作5年以上的候选人，不少人对这个问题没有求解思路。而这个问题却反映了大数据工程师在熟练的应用开发和技术理解之间存在Gap。

首先，估算下这个文件的大小: 10亿 X 64 = 64G。传统的思路是：

1）先将文件线性切分成64份小文件；

2）对每个小文件进行K-V统计；

3）对第一轮统计结果两两合并统计，依次进行下去，直到合并成一个结果。

       如图1所示。当第一次K-V统计完成后，第二次以及更后面的merge操作会有可能导致内存不够用。要merge的原因是并不知道url的分布，同一条url有可能出现在第一个小文件，也可能出现在最后一个小文件。如果url都不相同的话，爆内存是必然的事。说明线性切分的方法行不通。

图1 传统分治法

再看一种特殊的分治方法：

1）遍历大文件，对于每个url，通过hash(url) % 64得到一个id；

2）将这个url追加到第id个文件，这个文件可以称为分区文件；

3）重复上述步骤直到遍历完所有url；

4）对每个分区文件单独统计K-V，直接输出结果。

如图2所示。hash(url)计算得到一个随机的整数值，对64取模后，得到一个[0-63]之间的整数值。

图2 特殊的分治法

这种特殊分治法的特点：

1）将所有url以概率均等的方式分发到不同的分区文件；每个分区文件大概1G；

2）相同的url一定会分发到相同的分区文件，不同分区文件之间没有数据交集；

4）不管是url重复度高还是低，这个方案都能应对。如果url都不重复，也许存在某个分区文件大小会超过1G，把64改为128就行，反正总能很好应对。

        这个问题就是经典的单机版大数据问题，理解了这个后，可以直接抛出MapReduce计算模型，如图3-2所示。

图3-1 HDFS内部逻辑图

图3-2 分布式MapReduce计算模型

        大数据天然以Block的方式散落在分布式存储系统里（如HDFS），每个Block之间是独立的，如图3-1所示。一个InputSplit包含一个或多个Block分块，一个InputSplit对应一个Map Task。这些Map Task可以并行运行，充分利用了大数据集群的资源。Map Task处理的每条url，都经过hash(url)%64运算，分发到对应的Reduce Task。

        站在Map Task角度看，Map Task的输出包含了很多条数据，会分发到不同的Reduce Task。站在Reduce Task角度看，Reduce Task的输入可能来自不同的Map Task的输出。Map Task和Reduce Task在数据流上形成了复杂的多对多关系。这里不展开Shuffle过程的具体实现，Hadoop MR和Spark的Shuffle原理上基本一致，实现细节上存在差异。

        对于Reduce Task来说，必须等所有的Map Task运行完才能开始计算（当然可以先接收数据），否则会出现数据缺失。Reduce Task计算后的结果直接输出到对应的分区文件。

        相信到这，对MapReduce计算模型的理解更清晰了。如果想要了解Map和Reduce这两个词的意思，可以读一读Jeff Dean大神的论文《MapReduce: Simplified Data Processing on Large Clusters》，也体会下MapReduce这种编程模型的巧妙。

欢迎关注公众号：职场嘚吧嘚

一个专注IT人才成长的平台。