2.2 Projet PER-MARE
2.2.2 Contributions
2.2.2.1 Prise en compte du contexte d’exécution sur la plateforme Hadoop
Apache Hadoop [265] est une plateforme particulièrement conçue pour la réalisation et le déploiement d’applications de type MapReduce sur de grilles de calcul. Grâce à Hadoop, un concepteur de ce type d’application peut se concentrer uniquement sur la conception des fonctions map et reduce qui seront exécutées par la plateforme sur l’ensemble de ressources disponibles dans une grille de calcul. La distribution des données ainsi que le déploiement du code sur les nœuds disponibles demeurent sur l’entière responsabilité de la plateforme (contrairement à ce qui se passe avec d’autres APIs de calcul réparti comme MPI8 et OpenMP9). Le concepteur n’a alors plus besoin de s’occuper de ces aspects, son code ainsi que ses données sont automatiquement répartis dans la grille de calcul par la plateforme elle-même. Cette facilité d’usage lui a valu un franc succès qui a fait de cette plateforme une de plus utilisées pour le développement d’applications Big Data. Aujourd’hui, même si l’usage de Hadoop s’est nettement réduit, cédant la place à des nouvelles plateformes comme Spark10 ou Mahout11, entre autres, Hadoop reste la base de tout un écosystème open source dédié aux applications Big Data, comme l’illustre la Figure 22.
Figure 22. Ensemble d'outils pour le Big Data basés sur le framework Hadoop (illustration d’après [12]).
Apache Hadoop a été conçu pour s’exécuter sur des grilles de calcul « traditionnelles », autrement dit, des environnements de calcul homogènes, comptant un nombre stable de ressources disponibles. Cette plateforme n’a pas été conçue à la base pour s’exécuter sur des environnements hétérogènes et
8https://www.open-mpi.org/ 9https://www.openmp.org 10https://spark.apache.org 11https://mahout.apache.org
enabling high velocity capture, discovery and/or analysis (Feblowitz, 2012), while ensuring their veracity by an automatic quality control in order to obtain a big value .
These technologies are essentially
-source software for reliable, scalable, distributed computing (Hadoop, 2013).
The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage. Rather than rely on hardware to deliver high-availability, the library itself is designed to detect and handle failures at the application layer, so delivering a highly-available service on top of a cluster of computers, each of which may be prone to failures (Hadoop, 2013).
Fig. 2. Big Data technologies are based on Hadoop Ecosystem (Hadoop is an Open source project) III. Big Data in the Oil & Gas Upstream Sector
1. Overview
Upstream is no stranger to Big Data. Oil & Gas companies use thousands of sensors installed in subsurface wells and surface facilities to provide continuous data-collecting, real-time monitoring of assets and environmental conditions (Brulé, 2013).
The data volume is coming from sensors, spatial and GPS coordinates, weather services, with specific applications used to manage surveying, processing and imaging, exploration planning, reservoir modeling, production, and other upstream activities. But much of this data is
-62 dynamiques (c’est-à-dire, des environnements dont la composition et l’état varient dans le temps), tels que les grilles pervasives. Selon Hagras [100], la nature dynamique et ad-hoc des environnements pervasifs demande une certaine adaptation à des conditions d’opération changeantes et aux variations sur les préférences et le comportement des utilisateurs afin de favoriser un fonctionnement plus efficace et effectif, tout en prévenant des défaillances dans le système. Or la plateforme Hadoop, dans sa configuration originale, est incapable d’adapter dynamiquement son fonctionnement à un environnement variable, dans lequel les ressources sont de nature hétérogène et peuvent entrer ou sortir de l’environnement à tout moment. L’exécution de la plateforme Hadoop dans ce genre d’environnement va ainsi amener à un certain nombre d’inconvénients, liés notamment à l’allocation de ressources, entraînant le plus souvent une performance dégradée.
Figure 23. Overview de l'architecture Hadoop (d'après [45])
Une des raisons pour expliquer cette perte de performance repose sur la structure même de la plateforme. Celle-ci s’organise en deux parties, YARN12, responsable de la gestion de ressources disponibles dans la grille de calcul, et HDFS13, responsable de la distribution des données dans la grille. Tous les deux respectent une architecture « maître-esclave », dans laquelle un nœud « maître » (le
ResourceManager pour le premier, le NameNode pour le second) gère un ensemble de nœuds
« esclaves » (les NodeManager pour YARN, et les DataNode pour HDFS, comme on peut voir sur la Figure 23). Le NameNode se charge de répliquer sur l’ensemble des nœuds les données soumises par une application à la plateforme, alors que le ResourceManager va s’occuper de l’exécution des tâches
map et reduce soumises par l’application. Une même fonction map (ou reduce) sera ainsi lancée par le ResourceManager à chaque ressource (nœud) disponible sur un bloc distinct des données. Dans
chaque nœud (cf. Figure 23), le NodeManager va assurer l’exécution de l’application (organisée par la plateforme en ApplicationMaster et container), alors que le DataNode va gérer les données présentes localement (aussi bien celles produites localement que les répliques des données distantes).
Le traitement des données est ainsi réparti entre l’ensemble de ressources. Chaque ressource est configurée de manière statique, à l’aide d’un fichier XML et le ResourceManager considère que les tâches (correspondant aux fonctions map et reduce) auront toutes à peu près le même temps
12https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/YARN.html 13https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
The rest of the paper is organized as follows: Section II
introduces MapReduce model and the basis of Apache Hadoop
framework. Section III discusses related works, focusing on
context-awareness and on other improved Hadoop schedulers.
Section IV analyzes and evaluates Hadoop scheduling
mech-anism. Section V presents our proposal of context-aware
scheduling, while Section VI presents experiments and first
results. We conclude in Section VII.
II. A
BOUTH
ADOOPThe Apache Hadoop is a framework that has the purpose
of facilitating distributed processing through the MapReduce
model. MapReduce [1] divides computation into two phases:
map and reduce. During map, input data is split into smaller
slices of data, whose analysis is distributed over the
partici-pating nodes. Each participant computes one (or more) slice
of data, generating intermediary key/values results. During
reduce phase, intermediary values concerning a given key
are put together and analyzed, generating final key/values
results. Hadoop framework is in charge of distributing data
and map/reduce tasks over the available nodes. As a result,
programmers need only to focus on map and reduce functions,
since data and task distribution becomes transparent.
Apache Hadoop has two main components (see Fig. 1),
which are Hadoop Distributed FileSystem (HDFS) and Yet
Another Resource Negotiator (YARN). These components
are respectively responsible for the data management on a
distributed file system and for MapReduce tasks and job
processing. YARN manages tasks and jobs distribution over the
available nodes and it is in charge of scheduling jobs according
to nodes capacity. Each node information is controlled by an
individual NodeManager, while overall cluster information is
centralized by the ResourceManager.
YARN integrates a scheduler that is responsible for
dis-tributing tasks over the available nodes. Current YARN
struc-ture (Fig. 1) aims at acquiring and using each
NodeMan-ager resource information to improve the performance of
its default scheduler, the CapacityScheduler. Basically, each
NodeManager consults configuration files, in order to discover
node declared capacity, and inform ResourceManager about
its existence. This information is transferred to the scheduler
that uses it for deciding an appropriate job scheduling. The
CapacityScheduler has the role of centralizing the information
about NodeManager’s capacities on the "master" node, keeping
track of them in a global pool of resources and distributing
them according to the ApplicationMasters requests.
In order to deploy Hadoop on a cluster, every node must
have some XML configuration files available in their local
Hadoop installation. In fact, given Hadoop huge dependence
on XML files, even the nodes resources are set by these files.
This peculiarity makes a more adaptive environment something
hard to achieve with the default Hadoop distribution.
III. R
ELATEDW
ORKBecause Hadoop performance is tightly dependent on the
computing environment, but also on the application
char-acteristics, several researchers focused on bringing
context-awareness to Hadoop. Their works can be roughly classified
Client ResourceManager NameNode NodeManager ApplicationMaster Client DataNode NodeManager Container DataNode NodeManager DataNode NodeManager DataNode NodeManager Container DataNode NodeManager DataNode Container ApplicationMaster Container Container YARN / App HDFS YARN Hadoop 2.x daemon architecture
Figure 1: General Hadoop 2.x (YARN) Architecture.
as: (i) job or task schedulers, whose purpose is changing the
Hadoop scheduling, and (ii) resource placement facilitators.
In the first case, we find works like Kumar et al. [6],
Tian et al. [13] or Rasooli [14]. Those assume that most
jobs are periodic and demand similar CPU, network and disk
usage characteristics. As a consequence, these works propose
classification mechanisms that first analyze both jobs and
nodes with respect to its CPU or I/O potential, allowing an
optimized matching of applications and resources when a job
is submitted. For instance, Kumar et al. [6] and Tian et al.
[13] classified both jobs and nodes in a scale of I/O and
CPU potential, while Rasooli et al. [14] go beyond I/O and
CPU potential and propose a full classification of jobs in
order to match these jobs with nodes belonging to the same
classification. Similarly, Isard et al. [15] proposes a
capacity-demand graph that helps in the calculation of the optimum
scheduling from a global cost function.
While the previous works focus on the improvement of
the overall cluster performance through an offline knowledge
about the applications and the resources, other works focus
on individual tasks in order to ensure a smooth operation. For
instance, works like Zaharia et al. [16] and Chen et al. [17]
focus on improving tasks deployment inside a job, as a way
to reduce the response time in large clusters, executing many
jobs of short duration. These works rely on heuristics to infer
the job estimated progress and decide whether to launch a
speculative task on another possibly faster machine. Similarly,
Chen et al. [17] propose using historical execution traces to
improve its predictions. They propose a re-balancing of data
across the nodes, leaving more data to faster nodes and less
data on slower nodes.
Finally, works like Xie et al. [18] aim at providing better
performance on jobs through better data placement, using
mainly the data locality as decision making information. The
performance gain is achieved by the data re-balancing in nodes,
feeding faster nodes with more data. This lowers the cost
of speculative tasks and also of data transfers through the
network.
We may observe that most of these works rely on the
cate-gorization of jobs and nodes, which is hard in a dynamic
envi-ronment like pervasive grids. Even when runtime parameters
such as elapsed time or data placement are considered, they
assume a controlled and well-known environment. Because
253 Copyright (c) IARIA, 2014. ISBN: 978-1-61208-353-7
d’exécution quelque soit le nœud. Si une tâche prend plus de temps que les autres, le
ResourceManager pourra déclencher une tâche spéculative, c.a.d. ordonner la réexécution d’une
même tâche (map ou reduce) sur le même ensemble de données, mais sur un autre nœud. Or en présence des ressources hétérogènes, non seulement certaines tâches peuvent présenter des performances inférieures à d’autres (à cause de l’hétérogénéité des nœuds), mais également le nombre des tâches spéculatives peut augmenter de manière significative, dégradant ainsi la performance globale de l’application et consommant des ressources inutilement.
Cette possible perte de performance peut être observée à la Figure 24, issue de [46], dans laquelle on compare l’exécution d’une même application dans un environnement dédié (cas A) et dans un environnement hétérogène (cas B), où les capacités des nœuds impliqués évoluent pendant l’exécution des tâches. Une telle évolution peut s’expliquer, par exemple, par l’usage de ressources partagées avec d’autres applications et non par un usage exclusif de la grille de calcul. Dans la Figure 24, le cas A illustre une exécution dans un environnement homogène et dédié, correspondant donc à une grille de calcul traditionnelle. Par contre, dans le cas B, on simule une grille pervasive en réduisant la mémoire disponible de certains nœuds pendant l’exécution. La perte de performance est très significative, accompagnée d’une augmentation du nombre de tâches en exécution (représentée par l’intensité du dégradé dans le graphique), ce qui peut être expliqué par l’augmentation du nombre de tâches spéculatives.
Figure 24. Scénarios d'exécution d'un benchmark Big Data (application TestDFSIO) dans un cluster homogène dédié (cas A) et dans un environnement pervasif, sans prise en compte du contexte (cas B) et avec prise en compte du contexte
d'exécution (cas C et D) [46].
Afin de pallier ce problème, nous avons proposé, au sein du projet PER-MARE, d’adapter la plateforme Hadoop pour qu’elle puisse prendre en considération ces environnements hétérogènes. Nous avons ainsi modifié le ResourceManager et le NodeManager propres à Hadoop (cf. Figure 23) pour qu’ils puissent capturer des informations sur le contexte d’exécution des nœuds (nombre de cœurs disponibles, mémoire disponible, etc.). Pour cela, nous avons intégré le ContextCollector illustré par la Figure 25 au NodeManager pour que celui-ci puisse observer la situation courante de chaque nœud à la place de la configuration statique originellement proposée. Cet élément ContextCollector a été inspiré par nos travaux précédents sur la modélisation de contexte [137] (voir chapitre 1). Il considère
application. The charts also corroborate this analysis: in all experiments, cases A and C have much lighter tones than the others, meaning that less containers are running simultaneously. It is also worth noting that case C takes approximately twice the time case A used to complete the execution, a result to be expected since case C had half the resources of case A.
The analysis of the number of speculative tasks also gives interesting insights. In the case of TeraSort, the number of speculative tasks is reduced and almost similar in all scenarios. TestDFSIO and WordCount, on the other hand, deploy many more speculative tasks when the system is overloaded (scenarios B and D). This may be due to the factors that trigger a speculative task: a speculative task is
launched only after all the tasks for a job have been launched, and then only for tasks that have been running for some time (at least a minute) and have failed to make as much progress, on average, as the other tasks from the job. In the case of TeraSort, tasks evenly require both memory, CPU and I/O, so their execution time is less subject to specific resource depletion. TestDFSIO and WordCount, on the contrary, rely on more specific resources and thus are more subject to resource overload. In all the cases, the use of context-awareness on scenario D helps minimizing the number of speculative tasks when comparing to the ‘‘context-unaware’’ scenario B.
Concerning the execution flow, as illustrated by the Gantt charts, it is possible to note that both cases B and D Fig. 4 Gantt charts of the TeraSort experiments
Fig. 5 Gantt charts of the TestDFSIO experiments
340 G. W. Cassales et al.
64 l’information de contexte comme étant observée à travers des éléments de contexte auxquels on associe un ensemble de valeurs dans un modèle orienté objets. En outre, chaque élément de contexte est associé à un concept précis d’une ontologie de contexte, telle que proposée par [170] (voir chapitre 3). L’intérêt de combiner, dans la modélisation de contexte, une approche orientée objets avec une approche par ontologie réside dans la possibilité d’avoir une description sémantique des éléments de contexte tout en gardant les avantages d’une implémentation orientée objet. Dans le cas du projet PER-MARE, le caractère léger de cette implémentation est particulièrement important puisque, s’agissant d’applications de type « haute performance » (i.e. cherchant atteindre des hauts niveaux de performance lors de leur exécution), la gestion de contexte ne devrait pas avoir un impact significatif sur la performance de l’application. L’approche mixte utilisée par le ContextCollector, inspirée également par les travaux du projet MUSIC [262], permet de garder une implémentation orientée objets légère, plus performante, tout en gardant la possibilité d’utiliser, à l’avenir, des mécanismes de raisonnement basés sur les ontologies.
Figure 25. ContextCollector responsable par l'observation du contexte d'exécution d'un nœud [45].
Ainsi, dans un premier moment [45], nous utilisons l’information de contexte capturée par le
ContextCollector pour remplacer le fichier de configuration statique utilisé par Hadoop, permettant
une configuration automatique de chaque nœud à partir sur des informations réelles, collectées directement par le ContextCollector. Puis, nous avons modifié le ResourceManager [46] pour qu’il puisse utiliser ces informations de contexte dans son algorithme de schedulling (ordonnanceur). Celui-ci utilise alors des informations de contexte obtenues en temps réel pour ses déCelui-cisions concernant la distribution des tâches de calcul. Les résultats obtenus [45, 46] avec différentes applications (des benchmarks exigeant différents types de ressources : CPU, mémoire et I/O) démontrent un gain de performance significatif par rapport à un environnement hétérogène où la plateforme n’a pas été adaptée. La Figure 24 illustre un de ces résultats pour l’application TestDFSIO (benchmark particulièrement gourmant en I/O). On peut observer une réduction significative du temps d’exécution entre le cas B et les cas C et D, où le ContextCollector a été utilisé dès le début de l’exécution (cas C) ou à mi-parcours (cas D).