CAMR: Coded Aggregated MapReduce

TL;DR

This paper introduces CAMR, a scheme for distributed algorithms like deep learning that reduces communication load without exponentially increasing the number of jobs or data splits, improving scalability.

Contribution

CAMR achieves optimal communication load in distributed algorithms while maintaining a small number of jobs and data splits, unlike prior exponential-growth methods.

Findings

Reduces communication load in MapReduce-like systems.

Maintains a small number of jobs and data splits.

Achieves load reduction comparable to state-of-the-art methods.

Abstract

Many big data algorithms executed on MapReduce-like systems have a shuffle phase that often dominates the overall job execution time. Recent work has demonstrated schemes where the communication load in the shuffle phase can be traded off for the computation load in the map phase. In this work, we focus on a class of distributed algorithms, broadly used in deep learning, where intermediate computations of the same task can be combined. Even though prior techniques reduce the communication load significantly, they require a number of jobs that grows exponentially in the system parameters. This limitation is crucial and may diminish the load gains as the algorithm scales. We propose a new scheme which achieves the same load as the state-of-the-art while ensuring that the number of jobs as well as the number of subfiles that the data set needs to be split into remain small.

Tables

Table 1. TABLE I: Transmissions within group of { U 1 , U 3 , U 6 } subscript 𝑈 1 subscript 𝑈 3 subscript 𝑈 6 \{U_{1},U_{3},U_{6}\} during stage 2

Server	Transmits	Recovers
$U_1$	$\alpha ({\nu }_{6,3}^{\left(1\right)},{\nu }_{6,4}^{\left(1\right)})\left[1\right]\oplus \alpha ({\nu }_{3,1}^{\left(2\right)},{\nu }_{3,2}^{\left(2\right)})\left[1\right]$	$\alpha ({\nu }_{1,5}^{\left(3\right)},{\nu }_{1,6}^{\left(3\right)})$
$U_3$	$\alpha ({\nu }_{6,3}^{\left(1\right)},{\nu }_{6,4}^{\left(1\right)})\left[2\right]\oplus \alpha ({\nu }_{1,5}^{\left(3\right)},{\nu }_{1,6}^{\left(3\right)})\left[1\right]$	$\alpha ({\nu }_{3,1}^{\left(2\right)},{\nu }_{3,2}^{\left(2\right)})$
$U_6$	$\alpha ({\nu }_{3,1}^{\left(2\right)},{\nu }_{3,2}^{\left(2\right)})\left[2\right]\oplus \alpha ({\nu }_{1,5}^{\left(3\right)},{\nu }_{1,6}^{\left(3\right)})\left[2\right]$	$\alpha ({\nu }_{6,3}^{\left(1\right)},{\nu }_{6,4}^{\left(1\right)})$

Table 2. TABLE II: Needed aggregate values at the end of stage 2

Server	Needs
$U_1$	$\alpha ({\nu }_{1,1}^{\left(3\right)},{\nu }_{1,2}^{\left(3\right)},{\nu }_{1,3}^{\left(3\right)},{\nu }_{1,4}^{\left(3\right)})$ and $\alpha ({\nu }_{1,1}^{\left(4\right)},{\nu }_{1,2}^{\left(4\right)},{\nu }_{1,3}^{\left(4\right)},{\nu }_{1,4}^{\left(4\right)})$
$U_2$	$\alpha ({\nu }_{2,1}^{\left(1\right)},{\nu }_{2,2}^{\left(1\right)},{\nu }_{2,3}^{\left(1\right)},{\nu }_{2,4}^{\left(1\right)})$ and $\alpha ({\nu }_{2,1}^{\left(2\right)},{\nu }_{2,2}^{\left(2\right)},{\nu }_{2,3}^{\left(2\right)},{\nu }_{2,4}^{\left(2\right)})$
$U_3$	$\alpha ({\nu }_{3,3}^{\left(2\right)},{\nu }_{3,4}^{\left(2\right)},{\nu }_{3,5}^{\left(2\right)},{\nu }_{3,6}^{\left(2\right)})$ and $\alpha ({\nu }_{3,3}^{\left(4\right)},{\nu }_{3,4}^{\left(4\right)},{\nu }_{3,5}^{\left(4\right)},{\nu }_{3,6}^{\left(4\right)})$
$U_4$	$\alpha ({\nu }_{4,3}^{\left(1\right)},{\nu }_{4,4}^{\left(1\right)},{\nu }_{4,5}^{\left(1\right)},{\nu }_{4,6}^{\left(1\right)})$ and $\alpha ({\nu }_{4,3}^{\left(3\right)},{\nu }_{4,4}^{\left(3\right)},{\nu }_{4,5}^{\left(3\right)},{\nu }_{4,6}^{\left(3\right)})$
$U_5$	$\alpha ({\nu }_{5,1}^{\left(2\right)},{\nu }_{5,2}^{\left(2\right)},{\nu }_{5,5}^{\left(2\right)},{\nu }_{5,6}^{\left(2\right)})$ and $\alpha ({\nu }_{5,1}^{\left(3\right)},{\nu }_{5,2}^{\left(3\right)},{\nu }_{5,5}^{\left(3\right)},{\nu }_{5,6}^{\left(3\right)})$
$U_6$	$\alpha ({\nu }_{6,1}^{\left(1\right)},{\nu }_{6,2}^{\left(1\right)},{\nu }_{6,5}^{\left(1\right)},{\nu }_{6,6}^{\left(1\right)})$ and $\alpha ({\nu }_{6,1}^{\left(4\right)},{\nu }_{6,2}^{\left(4\right)},{\nu }_{6,5}^{\left(4\right)},{\nu }_{6,6}^{\left(4\right)})$

Table 3. TABLE III: Comparison of the minimum requirement on the number of jobs for CAMR and CCDC schemes using the same storage fraction. Cluster consists of K = 100 𝐾 100 K=100 servers.

k	Minimum $J$
	CAMR	CCDC
2	50	4950
4	15625	3921225
5	160000	75287520

Equations

$${\varphi }_q^{(j)}(1^{(j)},\dots ,N^{(j)})={\nu }_{q,1}^{(j)}+{\nu }_{q,2}^{(j)}+\cdots +{\nu }_{q,N}^{(j)},$$

$${\mathbf{G}}_{SPC}=\left[\begin{array}{cccc}& & \text{vline}& 1\\ & {\mathbf{I}}_{k-1}& \text{vline}& ⋮\\ & & \text{vline}& 1\end{array}\right].$$

$$\mathbf{T}=[{\mathbf{c}}_1^T,{\mathbf{c}}_2^T,\cdots ,{\mathbf{c}}_{q^{k-1}}^T].$$

$$B_{i,l}=\{j:{\mathbf{T}}_{i,j}=l\}.$$

$$\{1^{(j)},\dots ,N^{(j)}\}$$

$$\mathcal{B}=\{{\mathcal{B}}_{[i_1]}^{(j)},\dots ,{\mathcal{B}}_{[i_k]}^{(j)}\}$$

$$\mu =\frac{q^{k-2}\cdot (k-1)\cdot \gamma }{Jk\gamma }=\frac{k-1}{K}.$$

$$\begin{array}[]{r@{}l}X^{(1)}&{}=\{U_{1},U_{3},U_{5}\},\quad X^{(2)}=\{U_{1},U_{4},U_{6}\},\\ X^{(3)}&{}=\{U_{2},U_{3},U_{6}\},\quad X^{(4)}=\{U_{2},U_{4},U_{5}\}.\end{array}$$

$${\mathcal{B}}_{[i_3]}^{(1)}=\{1^{(1)},2^{(1)}\},{\mathcal{B}}_{[i_5]}^{(1)}=\{3^{(1)},4^{(1)}\},{\mathcal{B}}_{[i_1]}^{(1)}=\{5^{(1)},6^{(1)}\}.$$

$${\nu }_{q,n}^{(j)}={\varphi }_q^{(j)}(n^{(j)}),q\in [Q],n\in [N],j\in [J].$$

$$\{{\mathcal{D}}_{[k^{\prime }]}[i]:i=1,\dots ,k-1\}$$

$${\Delta }_m=\underset{k^{\prime }:U_m\in G\setminus \{U_{k^{\prime }}\}}{\oplus }\{{\mathcal{D}}_{[k^{\prime }]}[i]:U_m=U_i^{[k^{\prime }]}\}$$

$${\alpha }_{[k^{\prime }]}^{(j)}=\alpha (\{{\nu }_{k^{\prime },n}^{(j)}:n\in {\mathcal{B}}_{[i_{k^{\prime }}]}^{(j)}\}).$$

$$G=X^{(j)}\text{and}{\mathcal{D}}_{[k^{\prime }]}={\alpha }_{[k^{\prime }]}^{(j)}$$

$$\alpha ({\nu }_{1,5}^{(1)},{\nu }_{1,6}^{(1)})={\nu }_{1,5}^{(1)}+{\nu }_{1,6}^{(1)}.$$

$${\beta }_{[k^{\prime }]}^{(j)}=\alpha (\{{\nu }_{k^{\prime },n}^{(j)}:n\in {\mathcal{B}}_{[i_l]}^{(j)}\}).$$

$$\Delta_{k}^{\text{stage 3}}=\alpha\Bigg{(}\bigcup\limits_{l:U_{l}\in X^{(j)}\setminus\{U_{k}\}}\{\nu_{m,n}^{(j)}:\ n\in\mathcal{B}_{[i_{l}]}^{(j)}\}\Bigg{)}.$$

$${\varphi }_k^{(j)}(1^{(j)},\dots ,N^{(j)})=\alpha ({\nu }_{k,1}^{(j)},{\nu }_{k,2}^{(j)},\dots ,{\nu }_{k,N}^{(j)})$$

$$L_{\text{stage 1}}=\frac{Jk\frac{B}{k-1}}{JQB}=\frac{k}{K(k-1)}.$$

$$L_{\text{stage 2}}=\frac{q^{k-1}(q-1)k\frac{B}{k-1}}{JQB}=\frac{(q-1)k}{K(k-1)}.$$

$$L_{\text{stage 3}}=\frac{K\left(J-q^{k-2}\right)B}{JQB}=\frac{q-1}{q}.$$

$$L_{\text{CAMR}}=\sum _{i=1}^3{L}_{\text{stage i}}=\frac{k(q-1)+1}{q(k-1)}.$$

$$L_{\text{CCDC}}=\frac{(1-\mu )(\mu K+1)}{\mu K}.$$

$$L_{\text{CCDC}}$$

$$J_{\text{CCDC, min}}=\left(\genfrac{}{}{0ex}{}{K}{\mu K+1}\right)=\left(\genfrac{}{}{0ex}{}{kq}{k}\right)\stackrel{\text{(a)}}{\ge }{\left(\frac{kq}{k}\right)}^k\stackrel{\text{(b)}}{>}{J}_{\text{CAMR, min}},$$

$$\{{\Delta }_m:U_m\in G\setminus \{U_k\}\},$$

$$\{{\mathcal{D}}_{[k]}[i]:U_i\in G\setminus \{U_k\}\}.$$

Full text

I Introduction

The recent growth of big data analytics whereby a large amount of data on the orders of petabytes or more needs to be processed in a fast manner has fueled the development of several distributed programming models running on clusters of commodity servers. Some characteristic examples are MapReduce [1], Hadoop [2] and Spark [3].

In these frameworks, the data set is split into disjoint subfiles stored across the worker nodes. The computation takes place in three steps. Initially, the processing servers map the input subfiles to intermediate values having the form of (key, value) pairs. In the next shuffle step, the intermediate pairs are exchanged between the servers. In the final reduce step, each server computes a set of output functions defined based on the keys. By virtue of their simplicity, scalability and fault-tolerance, these frameworks are becoming ubiquitous and have gained significant momentum within both industry and academia. They are well suited for several applications including machine learning [4], [5], graph processing [6], data sorting [7] and web logging [1].

Compelling evidence obtained on large scale clusters suggests that the time spent merely on communication often dominates the execution time. For example, by analyzing a week-long trace from Facebook’s Hadoop cluster, the authors of [8] demonstrated that “on average, $33$% of the overall job execution time is spent on data shuffling.” Similar effects have been reported in the work of [9] on other shuffle-heavy operations such as SelfJoin, TeraSort and RankedInvertedIndex which underlie many deep learning algorithms. Distributed graph analytics also suffer from long communication phases as observed in [6], accounting for up to $50$% of the overall execution time in representative cases [10].

In this paper, we focus on distributed algorithms for which the intermediate values of a particular job computed during the Map phase can be combined locally by the servers before the transmission. This kind of computation is predominant in machine learning (e.g., ImageNet classification [5] and stochastic gradient descent [11]). Another use case would be the matrix-vector multiplications performed during the forward and backward propagation in neural networks (cf. [Dally_nips_tutorial]). In our context, computing each of these products constitutes a job. We could also consider training multiple models simultaneously, as long as they have the same dimensionality. This so-called compression technique was initially investigated in [1] by the means of a “combiner function” which merges multiple intermediate values with the same key computed from different Map functions.

The work of [12] proposed an approach (inspired by coded caching) for trading off communication load with computation load in MapReduce-like systems. This was extended in [4] to Compressed Coded Distributed Computing (CCDC), where compressible functions were considered. In prior work, we addressed one limitation of [12], namely the requirement that jobs need to fit very finely to obtain the promised communication load. Our approach demonstrated a deep relationship between this problem and a class of combinatorial structures called resolvable designs while achieving significant speedup compared to the state-of-the-art.

I-A Main contributions of our work

It turns out that [4] has a limitation of a similar flavor. In this case the number of jobs needs to scale exponentially in the problem parameters to obtain the promised reduction in communication load.

In this work, we extend our algorithm to applications where intermediate values can be compressed and we substantially reduce the requirement on the number of jobs compared to prior literature. The immediate benefit that stems from this fact is that as the size of the cluster increases, the required number of MapReduce jobs (and hence the total number of subfiles) does not scale exponentially. The implicit benefit is that a low requirement on the number of jobs decreases the encoding complexity. This is important since, as we have shown in [7], increasing the number of tasks scales the overhead of the encoding complexity and can diminish any gains in the communication load. We expect a similar type of phenomenon in the current setting.

Our new scheme is named coded aggregated MapReduce (abbreviated, CAMR). We characterize the achievable communication load of CAMR and show that it matches the state-of-the-art. The next section gives the general problem formulation, while in the remaining sections, we describe our scheme, analyze the achievable load and compare it with other combining methods.

II Problem Formulation

Our goal is to process $J$ distributed computing jobs (denoted $\mathcal{J}_{1},\dots,\mathcal{J}_{J}$) in parallel on a cluster of $K$ homogeneous servers $U_{1},\dots,U_{K}$, i.e., machines that have similar computational power. The data set of each job is partitioned into $N$ disjoint and equal-sized subfiles. The subfiles of the $j$-th job are denoted by $n^{(j)},n=1,\dots,N$. A total of $Q$ output functions, denoted $\phi_{q}^{(j)},q=1,...,Q$, need to be computed for each job. Note that these $Q$ functions may be different across different jobs. We examine a special class of functions that possess the aggregation property.

Definition 1**.**

In database systems, an aggregate function $\phi$ is one that is both associative and commutative.

For example, in jobs with linear aggregation the evaluation of each output function can be decomposed as the sum of $N$ intermediate values, one for each subfile, i.e., for $q=1,\dots,Q$,

[TABLE]

where $\nu_{q,n}^{(j)}=\phi_{q}^{(j)}(n^{(j)})$ and each such value is assumed to be of size $B$ bits. In what follows we use $\alpha(\nu_{q,1}^{(j)},\dots,\nu_{q,m}^{(j)})$ to denote the aggregation of $m$ intermediate values $\nu_{q,1}^{(j)},\dots,\nu_{q,m}^{(j)}$ of the same function $\phi_{q}^{(j)}$ and job $\mathcal{J}_{j}$ into a single “compressed” value.

A master node judiciously places each subfile on at least one server before initiating the algorithm.

Definition 2**.**

The storage fraction $\mu\in[1/K,1]$ of a distributed computation scheme is the fraction of the data sets across all jobs that each machine locally caches.

Our formulation assumes that $K$ divides $Q$ so that each server is assigned to $Q/K$ functions per job. However, our proposed algorithm and the main results can be obtained as a simple extension of the case when each server is computing one function. For example, one can repeat the Shuffle phase $Q/K$ times. Owing to this fact, we will only present the case of $Q=K$.

The framework starts with the Map phase during which the servers (in parallel) “map” every subfile $n^{(j)}$ to the values $\{\nu_{1,n}^{(j)},\dots,\nu_{Q,n}^{(j)}\}$. Following this, the servers multicast the computed intermediate values amongst one another via a shared link in the Shuffle phase. In the final Reduce phase, server $k$ computes (or reduces) $\phi_{k}^{(j)}(\nu_{k,1}^{(j)},\dots,\nu_{k,N}^{(j)})$ for $j=1,\dots,J$ as it has all the relevant intermediate values required for performing this operation.

Definition 3**.**

The communication load $L$ of a scheme is the total amount of data (in bits) transmitted by the servers during the Shuffle phase normalized by $JQB$.

Example 1**.**

Suppose that our task consists of $J=4$ jobs. For the $j$-th job we need to count $Q=6$ words given by the set $\mathcal{A}^{(j)}=\{\chi_{1}^{(j)},\dots,\chi_{6}^{(j)}\}$ in a book consisting of $N=6$ chapters using a cluster of $K=6$ servers. $\mathcal{J}_{j}$ is associated with the $j$-th book and its subfiles with the chapters $1^{(j)},\dots,6^{(j)}$. Function $\phi_{k}^{(j)},k=1,\dots,Q$ (assigned to server $U_{k}$ since $Q=K$ as discussed) counts the word $\chi_{k}^{(j)}$ of $\mathcal{A}^{(j)}$ in the book indexed with $j$. This formulation fits the linear aggregation case precisely. Indeed, each reducer only needs the sum of the word counts for the subfiles that it does not locally store and hence there is scope for “compressing” multiple values at the end of the Map phase.

III Description of the CAMR Scheme

In this section, we describe our proposed algorithm. We begin by introducing a few design theory definitions.

Definition 4**.**

A design is a pair $(\mathcal{X},\mathcal{A})$ consisting of

a set of elements (points), $\mathcal{X}$, and 2. 2.

a family $\mathcal{A}$ (i.e. multiset) of nonempty subsets of $\mathcal{X}$ called blocks, where each block has the same cardinality.

In this paper, we use a special class of designs, called resolvable designs.

Definition 5**.**

A subset $\mathcal{P}\subset\mathcal{A}$ in a design $(\mathcal{X},\mathcal{A})$ is said to be a parallel class if for $X_{i}\in\mathcal{P}$ and $X_{j}\in\mathcal{P}$ with $i\neq j$ we have $X_{i}\cap X_{j}=\emptyset$ and $\cup_{\{j:X_{j}\in P\}}X_{j}=\mathcal{X}$. A partition of $\mathcal{A}$ into several parallel classes is called a resolution, and $(\mathcal{X},\mathcal{A})$ is said to be a resolvable design if $\mathcal{A}$ has at least one resolution.

It turns out that there is a systematic procedure for constructing resolvable designs from error correcting codes.

Let $\mathbb{Z}_{q}$ denote the additive group of integers modulo $q$. The generator matrix of an $(k,k-1)$ single parity-check (SPC) code over $\mathbb{Z}_{q}$111We emphasize that this construction works even if $q$ is not a prime, i.e., $\mathbb{Z}_{q}$ is not a field. is defined by

[TABLE]

This code has $q^{k-1}$ codewords. The codewords are $\mathbf{c}=\mathbf{u}\cdot\mathbf{G}_{SPC}$ for each possible message vector $\mathbf{u}$. The $q^{k-1}$ codewords $\mathbf{c}_{i}$ computed in this manner are stacked into the columns of a matrix $\mathbf{T}$ of size $k\times q^{k-1}$, i.e.,

[TABLE]

The corresponding resolvable design is constructed as follows. Let $\mathcal{X}_{SPC}=[q^{k-1}]$ (for a positive integer $n$, we use $[n]$ to denote the set $\{1,2,\dots,n\}$ throughout) represent the point set of the design. We define the blocks as follows. For $0\leq l\leq q-1$, let $B_{i,l}$ be a block defined as

[TABLE]

The set of blocks $\mathcal{A}_{SPC}$ is given by the collection of all $B_{i,l}$ for $1\leq i\leq k$ and $0\leq l\leq q-1$ so that $|\mathcal{A}_{SPC}|=kq$. The following lemma (see [13] for a proof in a different context) shows that this construction yields a resolvable design.

Lemma 1**.**

The above scheme always yields a resolvable design $(\mathcal{X}_{SPC},\mathcal{A}_{SPC})$ with $\mathcal{X}_{SPC}=[q^{k-1}]$, $|B_{i,l}|=q^{k-2}$ for all $1\leq i\leq k$ and $0\leq l\leq q-1$. The parallel classes are analytically described by $\mathcal{P}_{i}=\{B_{i,l}:0\leq l\leq q-1\}$, for $1\leq i\leq k$.

III-A Job assignment and file placement

Our cluster consists of $K$ servers and we choose appropriate integers $q,k$ that factorize it as $K=k\times q$; we further need $N$ to be divisible by $k$. Next, we form a $(k,k-1)$ SPC code and the corresponding resolvable design, as described above. The jobs to be executed are associated with the point set $\mathcal{X}=[q^{k-1}]$. Hence $J=q^{k-1}$ and the block set $\mathcal{A}$ will be such that $|\mathcal{A}|=k\times q$. The servers are associated with the blocks and are indexed as $B_{i,j},i=1,\dots,k,$ and $j=0,1,\dots,q-1$.

The assignment of jobs to servers follows the natural incidence between points and blocks. Thus, job $\mathcal{J}_{j}$ is processed by (or “owned” by) the server indexed by $B_{i,l}$ if $j\in B_{i,l}$. For the sake of convenience we will also interchangeably work with servers indexed as $U_{1},\dots,U_{K}$ with the implicit understanding that each $U_{i},i\in[K]$ corresponds to a block from $\mathcal{A}$. By convention, server $U_{i}$ will be associated with the block $B_{\left\lceil{i/q}\right\rceil,\ (i-1)\ \mathrm{mod}\ q}$.

Let us denote the owners of $\mathcal{J}_{j}$ by $X^{(j)}\subset\{U_{1},\dots,U_{K}\}$. For each job, the data set is split into $k$ batches and each batch is made up of $\gamma$ subfiles, for some integer $\gamma>1$ (recall that $k|N$). The file placement policy is illustrated in Algorithm 1.

Each server is owner of $q^{k-2}$ jobs (block size). For each such job it participates in $k-1$ batches of size $\gamma$, as explained in Algorithm 1. Our requirement for the storage fraction is

[TABLE]

Example 2**.**

In Example 1, we have a cluster of $K=6$ nodes. We chose our parameters $q=2$ and $k=3$, then we need to execute $J=q^{k-1}=4$ MapReduce jobs. The codewords for this choice of parameters are $\{000,011,101,110\}$. Hence, based on Eq. (1), the owners are

[TABLE]

We have subdivided the original data set of each job into $N=6$ subfiles. The subfiles of the $j$-th job are partitioned into three batches, namely $\{1^{(j)},2^{(j)}\}$, $\{3^{(j)},4^{(j)}\}$ and $\{5^{(j)},6^{(j)}\}$. Exactly four such batches are stored on each machine (cf. Fig. 1). For $\gamma=2$, each job’s data set is split into $N=k\gamma=6$ subfiles placed on a unique subset of $k=3$ nodes. For example, the subfiles of job $\mathcal{J}_{1}$, $\{1^{(1)},2^{(1)},\dots,6^{(1)}\}$, are stored exclusively on $U_{1}$, $U_{3}$ and $U_{5}$. Specifically, the three batches of the first job are

[TABLE]

Then, batch $\mathcal{B}_{[i_{3}]}^{(1)}$ is stored on machines $U_{1}$ and $U_{5}$, $\mathcal{B}_{[i_{5}]}^{(1)}$ on $U_{1}$ and $U_{3}$ and, finally, $\mathcal{B}_{[i_{1}]}^{(1)}$ on $U_{3}$ and $U_{5}$. Each machine locally stores $\mu=\frac{k-1}{K}=\frac{1}{3}$ of all the data sets.

III-B Map phase

During this phase, each server maps all the subfiles of each job it has partially stored, for all output functions. The resulting intermediate values have the form

[TABLE]

At the end of the Map phase, for each job $\mathcal{J}_{j}$, each mapper combines all those values $\nu_{q,n}^{(j)}$ that are indexed with the same $q$ and $j$ (in other words, associated with the same function and job) and belong to the same batch of subfiles; we have already referred to this operation as aggregation. Our shuffle algorithm operates on the batch-level, as it will become clear in the following section.

III-C Shuffle phase

The CAMR scheme carries out the data shuffling phase in three stages. The first two stages utilize a common shuffling algorithm (cf. Algorithm 2), summarized in the following lemma and proved in [14, Appendix].

Lemma 2**.**

Consider a group of $k$ machines $G=\{U_{1},\dots,U_{k}\}$ with the property that every subset of $G$ of the form $G\setminus\{U_{k^{\prime}}\}$, stores a chunk of data of size $B$ bits, denoted $\mathcal{D}_{[k^{\prime}]}$, that $U_{k^{\prime}}$ does not store. Then, there exists a protocol where each machine in $G$ can multicast a coded packet useful to all other $k-1$ machines and after $k$ such transmissions each of them can recover its missing chunk. The total number of bits transmitted in this protocol is $Bk/(k-1)$.

Stage 1: In this stage, the owners of each job communicate among themselves. Let us fix a job $\mathcal{J}_{j}$ and consider the servers in $X^{(j)}\setminus\{U_{k^{\prime}}\}$ of cardinality $k-1$ (cf. Algorithm 1). During the Map phase, each machine in that subset has computed an aggregate needed by the remaining owner $U_{k^{\prime}}$ which is

[TABLE]

Repeating this process for every value of $j$ and $k^{\prime}$, we can identify all aggregates $\alpha_{[k^{\prime}]}^{(j)}$. We shall now see an one-to-one correspondence between this setup and Lemma 2 which is the following

[TABLE]

for $j=1,\dots,J$ and the owners $\{U_{k^{\prime}}\in X^{(j)}\}$.

Each owner of a particular job, after receiving $k-1$ such values (one from every other owner of a particular job), can decode all of its missing aggregates for that job.

Example 3**.**

In Example 1, let us consider the group of servers $\{U_{1},U_{3},U_{5}\}$ which are the owners of $\mathcal{J}_{1}$, storing $\{1^{(1)},2^{(1)},3^{(1)},4^{(1)}\}$, $\{3^{(1)},4^{(1)},5^{(1)},6^{(1)}\}$ and $\{1^{(1)},2^{(1)},5^{(1)},6^{(1)}\}$, respectively. Based on this allocation policy, server $U_{1}$ needs $\phi_{1}^{(1)}$ evaluations of the batch $\{5^{(1)},6^{(1)}\}$, i.e., $\nu_{1,5}^{(1)}\text{ and }\nu_{1,6}^{(1)}$ for $\mathcal{J}_{1}$ or simply the aggregate

[TABLE]

Similarly, $U_{3}$ needs $\alpha(\nu_{3,1}^{(1)},\nu_{3,2}^{(1)})$ and $U_{5}$ needs $\alpha(\nu_{5,3}^{(1)},\nu_{5,4}^{(1)})$.

Next, we refer to Fig. 2. The compressed intermediate values are represented by circle/green, star/blue and triangle/red. We further suppose that each value can be split into two packets (represented by the left and right parts of each shape). If $U_{1}$ transmits left circle XOR left star, then $U_{3}$ is able to cancel out the star part (since $U_{3}$ also maps $\{3^{(1)},4^{(1)}\}$) and recover the circle part. Similarly, $U_{5}$ can recover the star part from the same transmission. Each of these transmissions is useful to two servers.

We can repeat this process for the remaining jobs. The total number of bits transmitted in this case is therefore $J\times k\times B/2=6B$. The incurred communication load is $L_{\text{stage 1}}=\frac{6B}{JQB}=\frac{1}{4}$. 2. 2.

Stage 2: In this stage, we form communication groups of both owners and non-owners of a job, so that the latter can recover appropriate data to reduce their functions.

Towards this end, we form collections of user groups by choosing one block from each parallel class based on a simple rule. We choose servers $B_{1,j_{1}},B_{2,j_{2}},\dots,B_{k,j_{k}}$ such that $\cap_{\ell=1}^{k}B_{\ell,j_{\ell}}=\emptyset$. It has been proved in [13] (but in a different context) that if we remove a server $U_{k^{\prime}}$ from such a group $G$, the servers in the corresponding subset $P=G\setminus\{U_{k^{\prime}}\}$ of cardinality $|P|=k-1$ jointly own a job, say $\mathcal{J}_{j}$, that the remaining server $k^{\prime}$ does not. In addition, based on the file placement policy described before (cf. Algorithm 1), they share the batch of subfiles $\mathcal{B}_{[i_{l}]}^{(j)}$ for that common job and some $U_{l}\in X^{(j)}$.

The following simple observation is important. By construction, $U_{l}$ is precisely the remaining owner of $\mathcal{J}_{j}$ and it should lie in the parallel class that none of the other owners belong to; that is the same class as of $U_{k^{\prime}}$.

During the Map phase, each node in $P$ has computed an aggregate needed by $U_{k^{\prime}}$ which is

[TABLE]

As in stage 1, Lemma 2 fits in this description and Algorithm 2 defines the communication scheme; the shuffling group is $G$ and each server $U_{k^{\prime}}\in G$ needs to recover the chunk $\mathcal{D}_{[k^{\prime}]}=\beta_{[k^{\prime}]}^{(j)}$ for the unique batch that all nodes in $P$ share.

As a result, at the end of stage 2, each server $U_{k^{\prime}},k^{\prime}\in[K]$ is able to decode all aggregates of the form in Eq. (4) for all values of $l$, i.e., for all nodes $U_{l}$ that belong to the same parallel class as $U_{k^{\prime}}$. Note that each such value (for a fixed $l$) corresponds to $q^{k-2}$ (block size) jobs for which $U_{k^{\prime}}$ does not store any subfiles and $U_{l}$ does not store the batch $\mathcal{B}_{[i_{l}]}^{(j)}$.

Example 4**.**

In Example 1, in stage 2, the nodes recover values of jobs for which they haven’t stored any subfile. Let $G=\{U_{1},U_{3},U_{6}\}$. Observe from Eq. (2) that there is no job common to all three but each subset of two of them shares a batch of a job they commonly own. The remaining server needs an aggregate value of those subfiles. The values that each of $U_{1},U_{3},U_{6}$ needs as well as the corresponding transmissions are illustrated in Table I. We denote the $i$-th packet of an aggregate value by $\alpha(\cdot)[i]$.

There are $q^{(k-1)}(q-1)$ possible such groups we can pick. The total load is $L_{\text{stage 2}}=\frac{4\times 3\times B/2}{JQB}=\frac{6B}{JQB}=\frac{1}{4}$. 3. 3.

Stage 3: Each worker is still missing values for jobs that it is not owner of from Stage 2. Now, servers communicate within parallel classes. In particular, we show in [14, Appendix] that all values that a server $U_{m}$ still needs can be aggregated and transmitted by a single owner-server in the same parallel class that $U_{m}$ belongs to. This server is unique and transmits one aggregate value of its jobs to every other server in the same parallel class.

Recall that the $i$-th class is $\mathcal{P}_{i}=\{B_{i,j},j=0,\dots,q-1\}$, then, server $U_{k}\in\mathcal{P}_{i}$ transmits

[TABLE]

to another $U_{m}\in\mathcal{P}_{i}$; obviously, $U_{m}\notin X^{(j)}$.

We repeat this process for every pair $(U_{m},U_{k})$ of servers in the same class.

Example 5**.**

In Example 1, if we consider the same group as in Stage 2, i.e., $G=\{U_{1},U_{3},U_{6}\}$ then we can see that $U_{1}$ still misses values $\nu_{1,1}^{(3)},\nu_{1,2}^{(3)},\nu_{1,3}^{(3)}$ and $\nu_{1,4}^{(3)}$ of $\mathcal{J}_{3}$ or simply their aggregate $\alpha(\nu_{1,1}^{(3)},\nu_{1,2}^{(3)},\nu_{1,3}^{(3)},\nu_{1,4}^{(3)})$. Observe that all required subfiles locally reside in the cache of $U_{2}$ which can transmit the value to $U_{1}$. For the complete set of unicast transmissions see [14, Table II]. The load turns out to be $L_{\text{stage 3}}=\frac{6\times 2\times B}{JQB}=\frac{1}{2}$.

The communication load of all phases is then $L_{\text{CAMR}}=1$. Similarly, the load achieved by the CCDC scheme of [4] for the same storage fraction $\mu=1/3$ is $L_{\text{CCDC}}=1$. Nonetheless, their approach would require a minimum of $J={{6}\choose{3}}=20$ distributed jobs to be executed.

III-D Reduce phase

Using the values it has computed and received, $U_{k}$ reduces

[TABLE]

for all $k=1,\dots,K$ and $j=1,\dots,J$.

IV Communication Load Analysis

In the first stage, for each of the $J$ jobs, each of the $k$ owners computes one aggregate and is associated with a unique corresponding packet of it, of size $\frac{B}{k-1}$. As a result, the communication load exerted in this stage is

[TABLE]

The second stage involves the communication within all possible $q^{k-1}(q-1)$ groups that satisfy the desired property. In each case, $k$ workers transmit one value each, and the transmission is of length $\frac{B}{k-1}$. Then,

[TABLE]

Each server does not own $J-q^{k-2}$ jobs. For each of them, during stage 3, one transmission (of length $B$) from a server in the same parallel class is sufficient. Thus,

[TABLE]

The total load is

[TABLE]

V Comparison With Other Schemes

The technique proposed in [4] demonstrates a load of

[TABLE]

for a suitable storage fraction such that $\mu K\in\{1,\dots,K-1\}$. Our storage requirement is equal to $\mu=\frac{k-1}{K}$. For the same storage requirement, Eq. (6) yields

[TABLE]

We conclude that the loads induced by the two schemes are identical. However, their approach fundamentally relies on the requirement that the minimum number of jobs to be executed is $J_{\text{CCDC,\ min}}={{K}\choose{\mu K+1}}$. Comparing this value with our requirement for $J_{\text{CAMR}}=q^{k-1}$ and using a known bound for the binomial coefficients, we deduce that [CLRS_book]

[TABLE]

where the bound of (V) is maximum when $q=2$ and becomes stricter for $q>2$; however, as $q$ increases the bound of (V) loosens and it turns out that our requirement for the number of jobs becomes exponentially smaller than that of CCDC (cf. [14, Table III] for a numerical comparison).

Proof of Lemma 2

We shall refer to Algorithm 2 in order to show that each machine in $G$ can recover its missing data chunk. Fix a pair of machines $\{U_{m},U_{k}\}\subset G$ and the packet $\Delta_{m}$ transmitted from $U_{m}$ to $U_{k}$. By canceling out all terms of $\Delta_{m}$ with $U_{k}\in G\setminus\{U_{k^{\prime}}\}$ in Eq. (3), which $U_{k}$ locally stores, it can recover the remaining term, i.e., $\{\mathcal{D}_{[k]}[i]:U_{m}=U_{i}^{[k]}\}$. Keeping $U_{k}$ fixed, we repeat this process for every possible machine $U_{m}\in G\setminus\{U_{k}\}$. Since each of them is associated with a distinct packet of $\mathcal{D}_{[k]}$ it follows that by receiving the $k-1$ packets

[TABLE]

$U_{k}$ can recover the following packets

[TABLE]

Subsequently, $U_{k}$ concatenates them in order to recover $\mathcal{D}_{[k]}$. Since this proof holds independently of the choice of $U_{m}$, we have shown that all machines can recover their missing chunks at the end of the transmissions.

Since each chunk is assumed to be of size $B$ bits and it was split into $k-1$ packets of size $B/(k-1)$, the total amount of transmitted data is $Bk/(k-1)$.

Proof of Shuffling Correctness of Stage 3

The proof follows from stage 2 and by the resolvability property of our design. Let us fix a shuffling group of stage 2, say $G$, a subset $P=G\setminus\{U_{m}\}$ and focus on the excluded server $U_{m}$. The servers in $P$ share a batch of a job $\mathcal{J}_{j}$ whose values have transmitted to $U_{m}$. The remaining batches of $\mathcal{J}_{j}$ that $U_{m}$ still needs are locally stored at a single server (precisely the owner of the job) in the remaining parallel class, i.e., the parallel class of $U_{m}$ (cf. [Section III.A]). The fact that the design is resolvable makes that server unique, since no blocks within a parallel class can have common points (recall that points have one-to-one correspondence with the jobs). That node will transmit the uncoded aggregate to $U_{m}$. Such transmissions benefit a single machine.