Stratégies d'optimisation de requêtes SQL dans un écosystème Hadoop

1 RÉSUMÉ

Le Big Data n'est plus un « buzzword », il est devenu au fil de ces dernières années une réalité.Ainsi, il n'est plus rare que les grandes entreprises disposent d'un « puits de données » contenant une énorme quantité d'informations. C'est le cas d'Orange qui utilise Hadoop.

Dans ce cadre, le moyen le plus courant de programmer des traitements Big Data est d'utiliser Hive qui émule le langage SQL. Mais cette émulation peut être trompeuse car ses mécanismes sous-jacents sont radicalement différents de ceux que nous connaissons bien, ils cachent l'utilisation du paradigme MapReduce.Popularisé par Google, ce paradigme réussit à traiter de gigantesques volumes de données de manière distribuée. C'est son fonctionnement et son application au SQL qui seront détaillés dans ce mémoire afin de pouvoir proposer des stratégies d'optimisation des requêtes.

Il en ressortira qu'une bonne optimisation ne peut se faire sans connaissance fine des données manipulées et étude statistique préalable. Mais surtout, que la multitude d'options et de techniques d'optimisation proposées au développeur nécessiteraient de sa part une compétence similaire à celle d'un administrateur de base de données. C'est l'évolution de cet aspect qui conditionnera l'avenir de Hadoop et de Hive.

LISTE DES FIGURES ET DES TABLEAUX

Figure 1 : architecture Hadoop 1.0

Source (reproduction) : https://fr.hortonworks.com/blog/apache-hadoop-2-is-ga/

Figure 2 : architecture Hadoop 2.0

Source (reproduction) : https://fr.hortonworks.com/blog/apache-hadoop-2-is-ga/

Figure 3 : répartition de trois fichiers dans un cluster HDFS

Figure 4 : phases de création des containers YARN pour l'exécution de l'application « WordCount »

Figure 5 : phases d'exécution de l'application « WordCount »

Figure 6 : architecture de Hive

Figure 7 : diagramme de traitement du parcours d'une table avec projection et restriction

Figure 8 : processus de traitement MapReduce d'une requête avec projection et restriction

Figure 9 : processus de traitement MapReduce d'une requête SQL avec agrégation

Figure 10 : graphe des dépendances d'une requête avec jointure et agrégation

Figure 11 : processus de traitement MapReduce d'une requête SQL avec jointure

Figure 12 : phase « Map » d'une jointure sur un Mapper

Figure 13 : phase « Reduce » d'une jointure sur deux Reducers

Figure 14 : mouvement de données de type « One-To-One »

Source (reproduction) : https://fr.hortonworks.com/blog/expressing-data-processing-in-apache-tez/

Figure 15 : mouvement de données de type « Broadcast »

Source (reproduction) : https://fr.hortonworks.com/blog/expressing-data-processing-in-apache-tez/

Figure 16 : mouvement de données de type « Scatter-Gather »

Source (reproduction) : https://fr.hortonworks.com/blog/expressing-data-processing-in-apache-tez/

Figure 17 : comparaison MapReduce / Tez

Source (reproduction) : https://fr.hortonworks.com/blog/expressing-data-processing-in-apache-tez/

Figure 18 : du Système d'Information au Use Case Big Data

Figure 19 : graphe des dépendances d'une requête SQL avec jointure « Map-Only » (1/2)

Figure 20 : graphe des dépendances d'une requête SQL avec jointure « Map-Only » (2/2)

Figure 21 : Reducer devant traiter une donnée « biaisée » ou « skewed »

Figure 22 : traitement MapReduce détaillant le « Partition & Sort »

Source :Tom White (2015). Hadoop: The definitive guide, page 197

Tableau 1 : temps d'accès cumulé sur 1GB de données

Tableau 2 : centiles du nombre de lignes par date de chargement

Tableau 3 : centiles du nombre de lignes par date fonctionnelle