Magellan Final Report - Office of Science - U.S. Department of Energy

Magellan Final Report
• Merge. Some scientific application results in a merge of two or more data sources. For example,
observation data might need to be merged with simulation data. Such a merge operation results in an
output data volume that is significantly larger than the input data size.
We developed a synthetic benchmark suite to represent each of these data operations. We used the
Wikipedia data that is 6TB for our analysis. We use a subset of this data for some experiments as noted
below. For a filter operation, we constructed an index map of all the titles of the wikipedia pages and their
corresponding files. For the reorder operation, we perform a data conversion where we convert
and to to . For the merge operation, we create an index of all
lines of the wikipedia data.
Result
We summarize the results from our experiments understanding the effects of streaming, file systems, network
and replication.
Streaming. Existing scientific applications can benefit from the MapReduce framework using the streaming
model. Thus for our first experiment, we constructed the filter operation in both C and Java (using the
Hadoop APIs) and compared the two to understand the overheads of streaming. Comparing the overheads
of streaming are tricky since there is some differences in timing induced from just language choices. Hadoop
streaming also does not support Java programs since Java programs can directly use the Hadoop API. Figure
10.5a shows the comparison of the timings of both programs running on a single node. We see that the C
implementation is more efficient and also the performance improves as the data size increases. Figure 10.5b
shows the comparison of the streaming C version with the native Hadoop version for varying file sizes. We
notice that the performance through Hadoop is similar for smaller file sizes. This actually indicates that the
streaming has additional overhead since the C version is more efficient as such. As the file size increases we
see that the overhead for streaming increases.
Effect of file system. Figure 10.6 shows the comparison of performance of the data operations on both
GPFS and HDFS. For the filter operation, there is negligible difference between HDFS and GPFS performance
untill 2TB. However at 3TB HDFS performs significantly better than GPFS. For the reorder and
merge, GPFS seems to achieve better performance than HDFS and the gap increases with increasing file
sizes.
Figure 10.7 shows the comparison of HDFS and GPFS for all three data operations for a 2TB data set.
The figure shows the split of the processing time. The difference between HDFS and GPFS is negligible for
the filter operation. We notice that for the reorder and merge, GPFS seems to achieve better performance
than HDFS overall at this data size. However, HDFS performs better than GPFS at reads whereas GPFS
performs better than HDFS for the write part of the application at the given concurrency.
Our earlier results compared the performance for TeraGen on HDFS and GPFS with varying number of
maps. TeraGen is a write-intensive operation. Figure 10.8 shows the effect of varying number of mappers
on processing time for the filter operation on both HDFS and GPFS. We see that with increasing maps the
performance of GPFS goes down significantly. The clearly noticeable performance variations are likely due
to artifacts of Hadoop’s scheduling.
Thus, HDFS seems to achieve better read performance than GPFS and better write performance at
higher concurrencies.
Effect of network. Scientific applications in HPC centers traditionally use high performance, low-latency
networks. However Hadoop has traditionally been run on commodity clusters based on Ethernet networks.
The shuffle phase between the map and reduce phase is considered to be the most network intensive operation
since all the keys are sorted and data belonging to a single key is sent to the same reducer resulting in
large data movement across the network. Figure 10.9 shows the comparison of the network on various data
operations with varying file sizes. We observe that filter and reorder are not affected as much by the changes
92