WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

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

( Télécharger le fichier original )
par Sébastien Frackowiak
Université de Technologie de COmpiègne - Master 2 2017
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

5.2 Optimisation par la conception ou « design »

Si le tuning permet d'améliorer les temps d'exécutiondes requêtesde manière mécanique, l'importance de leur conception ne doit pas être occultée, en particulier lorsqu'il est question de produire un « Use Case Big Data ».

Un « Use Case Big Data » consiste à produire de nouvelles données par croisement périodiquede données sources (issues du SI mais aussi de données externes), qui pourront être consommées par des tiers, afin de répondre à un besoin métier spécifique.

Cette production de données consiste ainsi à réaliser des requêtes sur le puits de données, à éventuellement créer des tables intermédiaires, puis à stocker le résultat final pour qu'il puisse être utilisé.

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

Nous appellerons « plan de requêtes », l'ensemble des requêtes permettant d'aboutir au croisement des données du Use Case.

Un plan de requêtes qui ne tiendrait pas compte de la spécificité des données à traiter (par exemple, pour chaque table, le nombre de lignes et la répartition des clés de jointures) ne pourra pas être optimisé.

En effet, en fonction de la typologie des données à traiter, il sera possible d'utiliser différentes techniques de requêtage.

Ainsi, cette partie se propose d'étudier ces différentes techniques avec le souci d'expliquer les situations qui leur seront particulièrement adaptées.

5.2.1 Utiliser les tables partitionnées

Les tables du puits de données atteignent régulièrement plusieurs TB. Lorsqu'une requête interroge l'une d'elle, il est rarement utile d'avoir à parcourir l'intégralité des données qu'elle contient.

Ces tables de grandes tailles sont ainsi partitionnées. Le partitionnement consiste à disposer les fichiers qui les composent de manière hiérarchisée dans le HDFS. Cette hiérarchie est définie à la création de la table dont voici la syntaxe :

CREATE TABLE z_database1.table1 (field1                  string, ...)PARTITIONED BY (year                    string,month                   string, daystring);

Les champs définis dans la section « PARTITIONED BY » définissent la hiérarchie de stockage dans le HDFS.

Considérons la table « table1 » que nous venons de définir, dont les fichiers sont sous cette arborescence :

2.6TB  /apps/hive/warehouse/z_database1.db/table1

La requête suivante précise une partition à considérer :

SELECT * FROM z_database1.table1WHERE year="2018" AND month="01" AND day="01"

Les fichiers réellement considérés seront donc sous cette arborescence :

5.9GB  /apps/hive/warehouse/z_database1.db/table1/year=2018/month=01/day=05

Seuls 5.9GB des données seront ainsi manipulées au lieu des 2.6TB de départ, ce qui épargnera le cluster HDFS (le NameNode sera sollicité sur une plus faible quantité de fichiers) et le cluster YARN (il ne sera pas nécessaire d'allouer une quantité importante de containers).

Cette méthode n'est pas réservée aux tables du puits de données, il est également intéressant d'utiliser le partitionnement pour les tables qui seront produites dans le cadre d'un « Use Case ». Dans ce cas, le partitionnement devra être réalisé en considérant des colonnes de faible cardinalité. En effet, des cardinalités trop importantes impliqueraient la création de nombreux répertoires et fichiers, ce qui, nous le savons à présent, est contre-productif.

Les partitions des tables du puits sont couramment hiérarchisées par la date de chargement des données.

Le tableau suivant montre la répartition du nombre de lignes insérées par jourde chargement dans la table « table1 » (sur 6 mois de données).

 

0,25

0,5

0,75

0,9

0,95

0,99

centile

46 114 093

47 831 809

48 907 836

50 198 535

51 131 198

90 529 083

Tableau 2 :centiles du nombre de lignes chargées par jour

Avec MIN=201 789 et MAX=108 132 735

Le tableau suivant montre la même répartition mais à l'aide des dates fonctionnelles, par exemple la date à laquelle a été passée une commande dans le cas d'une table enregistrant des commandes de clients.

 

0,25

0,5

0,75

0,9

0,95

0,99

centile

16 130 510

38 035 331

42 779 757

45 833 922

47 710 421

49 173 539

Tableau 3 : centiles du nombre de lignes par date fonctionnelle

Avec MIN=2 609 997 et MAX=49 361 016

Cette répartition est moins intéressante que la première caril y a de plus grands écarts entre chaque centile. La répartition des données est donc moins régulière.

Une étude préalable de la répartition des données est donc souhaitable avant de déterminer la manière de partitionner une table.

Cette méthodologie pourra être appliquée dès lors où il est nécessaire de partitionner une table volumineuse et que plusieurs colonnes sont en concurrence pour en établir la hiérarchie.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"I don't believe we shall ever have a good money again before we take the thing out of the hand of governments. We can't take it violently, out of the hands of governments, all we can do is by some sly roundabout way introduce something that they can't stop ..."   Friedrich Hayek (1899-1992) en 1984