the last reducer as there is a write barrier at the end of a job. Although there are faster and newer big data processing frameworks like Apache Spark [@zaharia2012resilient] MapReduce is still relevant in the big data processing domain.

![**The MapReduce Communication Pattern**[]{data-label="mrpattern"}](images/mrpattern){width="15.00000%"}

In order to define a representative model to predict the performance of a MapReduce application, all the phases shown in in Figure \[mrworkflow\] should be considered. The phases can be grouped into user-defined and framework-defined phases. User-defined phases are implemented by the programmer to provide customised functionality, e.g. the *map()* and *reduce()* functions. Framework-defined phases are defined and controlled by the framework, and users cannot modify those functionalities. Examples are *read*, *collect*, *spill*, *merge*, *shuffle* and *write*. In Section \[theoriticalmodels\], we will present detailed explanation for each of the phases of the MapReduce pipeline illustrated in Figure \[mrworkflow\].

Theoretical Models of The MapReduce Pattern {#theoriticalmodels}
===========================================

In this chapter, we present the lessons learnt from the in-depth exploration of the MapReduce source code and its internals.

![image](images/mrflow){width="70.00000%"}

**Map Phase**
-------------

As shown in Figure \[mrworkflow\], the Map Phase consists of the following sub-phases: *Read*, *Map*, *Collect*, *Spill* and *Merge*.

### **Read**

This phase reads a configurable input 