# Hadoop vs. Spark: Impact on Performance of the Hammer Query Engine for Open Data Corpora
## 6 Experimental Campaign
### Results
#### 6.2.2. Hadoop vs. Spark Comparison
\begin{table}
\begin{tabular}{l c c c c} \hline \hline \(Env_{2}\) & _max\_neigh_ & **1000 Data Sets** & **10,000 Data Sets** & **15,000 Data Sets** \\ \hline \(Conf_{1}\) & & 33.90\% & 28.42\% & 24.62\% \\ \(Conf_{2}\) & 10 & 42.04\% & 23.07\% & 22.58\% \\ \(Conf_{3}\) & & 20.11\% & 20.38\% & 22.09\% \\ \hline \(Conf_{4}\) & & 28.12\% & 17.66\% & 24.67\% \\ \(Conf_{5}\) & 100 & 25.34\% & 19.79\% & 23.00\% \\ \(Conf_{6}\) & & 21.77\% & 20.69\% & 21.28\% \\ \hline \(Conf_{7}\) & & 21.45\% & 22.67\% & 18.68\% \\ \(Conf_{8}\) & 1000 & 25.89\% & 19.19\% & 21.09\% \\ \(Conf_{9}\) & & 24.74\% & 18.19\% & 23.02\% \\ \hline \(Env_{3}\) & _max\_neigh_ & **1000 Data Sets** & **10,000 Data Sets** \\ \hline \(Conf_{1}\) & & 18.53\% & 13.99\% & 11.11\% \\ \(Conf_{2}\) & 10 & 23.01\% & 11.91\% & 11.74\% \\ \(Conf_{3}\) & & 10.74\% & 11.31\% & 12.02\% \\ \hline \(Conf_{4}\) & & 13.85\% & 8.70\% & 12.29\% \\ \(Conf_{5}\) & 1000 & 10.05\% & 9.23\% & 9.97\% \\ \(Conf_{6}\) & & 9.12\% & 9.44\% & 9.12\% \\ \hline \(Conf_{7}\) & & 9.70\% & 12.63\% & 8.73\% \\ \(Conf_{8}\) & 1000 & 10.99\% & 10.54\% & 10.01\% \\ \(Conf_{9}\) & & 12.34\% & 10.18\% & 10.25\% \\ \hline \hline \end{tabular}
\end{table} 
Table 10: Fraction of average execution times for environments \(Env_{2}\) and \(Env_{3}\) (_Spark_ technology) with respect to execution times for environment \(Env_{1}\) (_Hadoop_ technology). We can notice that parameter _max_neigh_ strongly influences execution times: we could expect this effect because by increasing the number of queries to process, the number of Map tasks to perform increases as well (as many Map tasks as queries to process, see Section 5.2). Of course, environment _Env\({}_{1}\)_ (powered by _Hadoop_ technology) is the most sensitive. Figure 6: Comparing execution times of Step 4 for each configuration, among the three different execution environments for the basic Map-Reduce algorithm. Thus, an issue we will have to deal with is to find a good compromise between effectiveness and efficiency. In fact, by generating a large number of neighbor queries, we can expect to increase recall (but precision could drop down); nevertheless, too many queries to process slow down execution. We will address this issue in our future work. Finally, notice the different behaviors exhibited by the three execution environments depending on the number of processed data sets. With 1000 data sets (Figure 6a), configurations \(Conf_{1}\), \(Conf_{2}\) and \(Conf_{3}\) exhibit execution times which are more or less stable; the same happens, more or less, with configurations \(Conf_{4}\), \(Conf_{5}\) and \(Conf_{6}\). In contrast, a strange variation is exhibited with configurations \(Conf_{7}\), \(Conf_{8}\) and \(Conf_{9}\), for all technologies: execution times increase when the minimum thresholds \(th\_krm\) and \(th\_rm\) increase. In principle, this is contradictory: by increasing the thresholds, the number of data sets selected by Step 4 and Step 5 does not increase, so even the execution time is not expected to increase. The answer is in the way we implemented the iterative computation in Step 4 (see Section 5.3: with \(th\_krm=0.2\), the algorithm finds the first data set in the early iterations and stops; with \(th\_krm=0.3\), all keywords extracted from queries to process \(nq_{i}\in Q\) must be used to retrieve data sets, so that the algorithm must work on a large number of entries in the inverted index. Recall from Section 5.3 that no data are passed to scheduled tasks, apart from query descriptors, because each task obtained directly by querying the _MongoDB_ server to get information. Thus, why the _Hadoop_ version is so slower, compared with _Spark_ versions? The reason is that task synchronization is performed by exchanging data through the HDFS. This confirms that the HDFS is the bottleneck in the _Hadoop_ implementation, even though it is marginally used by the algorithm.