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

4.2 La commande « EXPLAIN »

Tout comme dans les SGBDR classiques, Hive propose la commande EXPLAIN qui permet d'obtenir le plan d'exécution de la requête à exécuter. Dans notre environnement distribué, le plan d'exécution liste l'ensemble des étapesqui seront exécutées sur le cluster Hadoop.

Nous allons tirer parti de cette commande pour constituer notre connaissance du fonctionnement de Hive. Ce qui nous permettra plus tard, d'optimiser nos requêtes. Nous jugeons fondamental de proposer une méthode d'interprétation des résultats d'un EXPLAIN. En effet, c'est un outil que tout utilisateur de Hive doit pouvoir s'approprier afin d'en faire de même. Nous espérons que nos explications détaillées pourront ainsi servir de modèle. En effet, il nous a été nécessaire d'analyser le code source de l'EXPLAIN ( https://github.com/apache/hive) pour le comprendre pleinement, n'ayant trouvé aucun document réellement explicatif à son propos.

Commençons donc à construire notre compréhension du fonctionnement de Hive en utilisant la commande EXPLAIN EXTENDED sur une requête que nous complexifierons au fur et à mesure.

Le rajout du mot clé « EXTENDED » permet d'obtenir notamment l'arbre syntaxique abstraitde la requête ainsi que des informations issues du metastore, relatives auxtables manipulées.

En outre, le résultat d'un « EXPLAIN » étant relativement verbeux, nous le limiterons dans nos exemples aux informations que nous jugerons pertinentes.

Enfin, pour des raisons de confidentialité d'entreprise, le nom des bases, des tables et des champs ont été anonymisés.

4.2.1 Explication d'une projection simple

La commande suivante permet d'expliquer une requête simpleeffectuant une projection :

EXPLAIN EXTENDED

SELECT field1FROM z_database1.table1;

Le résultat de l' « EXPLAIN EXTENDED » est :

ABSTRACT SYNTAX TREE:

TOK_QUERY

TOK_FROM

TOK_TABREF

TOK_TABNAME

z_database1

table1

TOK_INSERT

TOK_DESTINATION

TOK_DIR

TOK_TMP_FILE

TOK_SELECT

TOK_SELEXPR

TOK_TABLE_OR_COL

field1

STAGE DEPENDENCIES:

Stage-0 is a root stage

STAGE PLANS:

Stage: Stage-0

Fetch Operator

limit: -1

Processor Tree:

TableScan

alias: table1

Statistics:

Num rows: 38877279

Data size: 95714574567

Basic stats: COMPLETE

Column stats: NONE

GatherStats: false

Select Operator

expressions: field1 (type: varchar(10))

outputColumnNames: _col0

Statistics:

Num rows: 38877279

Data size: 95714574567

Basic stats: COMPLETE

Column stats: NONE

ListSink

Explications :

Le résultat d'un « EXPLAIN EXTENDED » contient 3 parties.

· (1) L'arbre syntaxique abstrait

Il décrit un ensemble de blocs « TOK_* » symbolisant les tokens (des mots clé) reconnus par le parser.

Dans notre exemple, nous remarquons notamment les tokens suivant :

- TOK_QUERY : la racine de l'arbre

o TOK_FROM : la base et la table interrogées

o TOK_INSERT : la destination du résultat dans un fichier temporaire

o TOK_SELECT : les champs sélectionnés

· (2) Les dépendances entre étapes

Cette partie décrit le plan de dépendances entre chaque étape où une étape peut :

- êtreracine (« is a root stage »)

- dépendre d'une autre étape (« depends on stage... »)

- consister à déclencher une autre étape (« consists of stage... »)

Dans notre exemple, il ne figure qu'une seule étape :

- Stage-0 : l'étape racine

· (3) Le plan d'étapes

Cette partie décrit la séquence des étapes qui seront réalisées où chaque étape peut être de type :

- Map Reduce

- Fetch Operator (lire les données d'une table)

- Move Operator (déplacer un fichier du HDFS)

Une étape peut contenir un ou plusieurs arbres de traitements, dont chacun peut contenir un ou plusieurs traitements.

Dans notre exemple :

- Stage-0

o est de type « Fetch Operator »

o contient un arbre de traitements « Processor Tree » décrivantla séquence de traitements suivants :

§ TableScanSelect OperatorListSink

Où :

- TableScan : « balaye » la table ligne par ligne

- Select Operator : projette le champ sélectionné vers un fichier temporaire

- ListSink : transmetles données du fichier temporaire à l' « executor »

Une simple projection n'implique ni opération « Map », ni opération « Reduce » carelle ne requiert aucune manipulation des données. Les informations fournies par le metastore(l'emplacement des fichiers contenant la table et la définition de chacun de ses champs) suffiront pour demander directement au cluster HDFS (NameNode + Datanodes) de transmettre à l' « executor », les données projetées de la table, sans solliciter le cluster YARN (ResourceManager + NodeManagers).