Database Reference
In-Depth Information
relatively constant and does not depend on problem size. This tells us that the
percentage overhead associated becomes amortized. From this we can conclude
that as long as the file size is reasonably large, the cost of adding more tasks
from the same data will not produce a heavy negative impact on our execution
times provided the adaptability to heterogeneity is necessary.
Further, we expect similar performance for the one task per node and two
tasks per node schemas in most cases. The reason that we expect this is because
two tasks per node does not allow much room for adaptability to heterogeneity.
To illustrate the inability to adapt at this level of taks granularity, we present
Fig. 3 . In the figure, the execution time of workloads is presented relative to their
execution time on the original (unupgraded) cluster. The trend of the data pre-
sented is that the execution times for the slightly upgraded clusters(25 % and 50 %
upgraded) are relatively consistent. These results also indicate a slight increase in
execution time for smaller file sizes relative to larger file sizes. This illustrates both
the overhead and the inability to adapt to heterogeneity at this level of task granu-
larity. In order to realize heterogeneity adaptability from such a small difference in
the number of tasks, the degree of heterogeneity would have to be high. In particu-
lar, for a cluster to be able to utilize the creation of one additional task per worker,
a fast node would have to be able to reliably complete two tasks before the slowest
node finished one task. Otherwise, the slowest node would be able to request its
second task and the entire job would complete only once the slowest node com-
pletes its second task. In short, an upgraded node would have to be roughly twice
as fast as an non-upgraded node in order to see an improvement in execution time
when there are two tasks per node.
This has been partially addressed by Ahmad et al. [ 11 ] when considering
clusters that have both extremely fast and extremely slow nodes. In particu-
lar, they consider a heterogeneous cluster of Intel Xeon server class hardware
and Intel Atom hardware. They discover that in Hadoop [ 1 ], “work stealing”
occurs, and is especially a problem toward the end of the
phase. In this
scenario, the Xeon nodes speculatively execute tasks whose data are local to
the Atom nodes. The non-local status of the data associated with the task is
the cause of this “work stealing” happening at the end of the
map
phase, since
Hadoop's speculative execution prefers local tasks to remote ones. As a result of
“work stealing”, the Xeon nodes prevent the Atom nodes from preforming their
fair share of work. Tarazu [ 11 ], a Hadoop enhancement suite mitigated this prob-
lem by adding in communication aware speculative execution of tasks. However,
this late
map
phase “work stealing” is not a problem in our framework. Due to
the data visibility afforded to MARLA by use of a networked file system, the
concept of remote tasks does not exist. Additionally, MARLA has no preference
for local tasks over remote tasks, as all data is visible to all nodes. The Tarazu
enhanced Hadoop has not been analyzed within the context of upgrading clus-
ters as we have presented here; it focuses on the disparity between computation
capabilities of Xeon and Atom based hardware, a drastic difference. We believe
that a single node being upgraded to a node whose hardware is slightly more
powerful is a more plausible scenario for existing data centers, as opposed to
replacing one brawny node with eight wimpy ones.
map
Search WWH ::




Custom Search