The Doppler Quarterly (FRANÇAIS) L'automne 2017 | Page 31

mandations concernant le réglage des performances de
Tez sur le Web. Pour notre part, nous conseillons aux
praticiens d’intégrer les détails, de comprendre les con-
cepts sous-jacents et de faire leurs propres expérimen-
tations avec des données réelles.
Exécution de requêtes vectorisées
Le moteur d’exécution de requêtes par défaut de Hive
traite une ligne à la fois. Ce mode de traitement néces-
site plusieurs couches d’appels de méthodes virtuelles
dans la boucle imbriquée, ce qui se révèle très peu effi -
cace du point de vue des performances des processeurs.
L’exécution de requêtes vectorisées est une fonctionnal-
ité de Hive qui vise à éliminer ces ineffi cacités en effec-
tuant une lecture par lots de 1 024 lignes et en appli-
quant globalement l’opération à l’ensemble la collection
d’enregistrements, plutôt qu’individuellement. Le gain
obtenu avec cette méthode d’exécution vectorielle est
d’un ordre de grandeur supérieur à la vitesse des opéra-
tions exécutées sur les requêtes typiques, telles que les
balayages, fi ltres, agrégations et jointures. Pour pouvoir
exploiter les requêtes vectorisées, vous devez stocker
vos données dans ORC, attribuer la valeur « true » à la
propriété format.hive.vectorized.execution.enabled et
enfi n, exécuter la requête sur les tables secondées par
ORC. Étant donné que l’exécution des requêtes vec-
torisées dans les clusters EMR n’est actuellement pas
activée par défaut, ce comportement doit être confi guré
manuellement dans Hive.
Optimiseur basé sur les coûts
Le concept d’optimiseur basé sur les coûts, ou CBO
(Cost-Based Optimizer) dans Apache Hive est très sem-
blable à celui qui est employé dans l’univers des bases de
données relationnelles. On rassemble des statistiques
telles que le nombre de lignes dans une table ou une par-
tition, ainsi que les histogrammes d’une colonne présen-
tant un intérêt particulier (qui sert d’entrée pour les
fonctions de calcul des coûts d’un optimiseur de
requête), de sorte que le CBO puisse comparer différents
plans d’exécution des requêtes et sélectionner celui dont
le « coût » est le plus faible. Dans certains cas, l’obtention
d’une réponse très rapide aux requêtes n’est possible
que via l’interrogation de statistiques stockées, au lieu
de plans d’exécution à longue échéance.
Le moteur CBO de Hive utilise les statistiques contenues
dans le Metastore de Hive pour générer des plans de
requête de niveau optimum. Deux types de statistiques
sont utilisés pour cette optimisation : les statistiques de
table (qui portent sur la taille non compressée de la
table, le nombre de lignes et le nombre de fi chiers util-
isés pour stocker les données), ou bien les statistiques de
colonne.
L’inconvénient du système CBO est que vous devez
recueillir et maintenir des statistiques exactes sur vos
tables pour que le moteur d’optimisation basé sur les
coûts soit effi cace. Or, la collecte des statistiques de la
table est une opération coûteuse ; mais une fois achevée,
toutes les requêtes ultérieures impliquant la table béné-
fi cient des statistiques ainsi recueillies.
Démon LLAP (Long Live and Process)
Les performances de Hive se sont accrues à mesure que
les exigences en la matière se sont fait jour et que les div-
ers composants de la solution, y compris Tez et le moteur
CBO, sont venus compléter la donne. LLAP, le démon
longue durée qui remplace les interactions directes par
le nœud de données HDFS, élève Hive à un niveau de
maturité encore supérieur grâce, entre autres, à ses
capacités de lecture anticipée et de mise en cache de
blocs de colonnes. Un démon LLAP s’exécute sur les
nœuds de travail du cluster et traite les E/S, la mise en
cache et l’exécution des requêtes fragmentées. L’ensem-
ble de l’exécution est planifi é et surveillé par un moteur
d’exécution Hive existant (tel que Tez). Le résultat du
travail effectué par un démon LLAP peut soit faire partie
du résultat d’une requête Hive, soit être transféré vers
des tâches externes de Hive, selon la requête défi nie.
L’une des exigences clés dans de nombreux environne-
ments est de disposer d’un contrôle d’accès ultraprécis
au niveau des colonnes. Étant donné que les démons
LLAP sont utilisables par d’autres applications, et que le
démon est également ouvert à d’autres API optionnelles,
il est possible de mettre en œuvre un contrôle d’accès
affi né pour une autre infrastructure de traitement de
données via LLAP. La possibilité de charger des données
dans des entités SQL DataFrame Apache Spark issues
d’Apache Hive via le démon LLAP en est un excellent
exemple. Dans Apache Ranger, on peut défi nir des con-
trôles de niveau d’accès très précis au niveau de la ligne
ou de la colonne, ce qu’Apache Spark ne permet pas.
Conclusion
Apache Hive a considérablement évolué ces dernières
années, jusqu’à devenir une plateforme capable de pren-
dre en charge les besoins des entrepôts de données Big
Data d’une grande entreprise. Dans les premières
années, les charges de travail des requêtes qui exigeaient
des temps de réponse courts n’étaient pas adaptées à
Hive. Par comparaison, aujourd’hui, un système Apache
Hive correctement paramétré sur Tez avec une mise en
œuvre LLAP permet d’atteindre des temps de réponse
inférieurs à la seconde. Une solution d’entrepôt de don-
nées fondée sur des cas d’utilisation appropriés et une
infrastructure Apache Hive correctement conçue mérite
d’être sérieusemen