Apache

Configurer Hive LLAP sur HDInsight

Sep 14, 2018

Arnaud Voisin

Azure HDInsight est un service PAAS qui permet d’instancier des plateformes préconfigurées à partir des solutions proposées par Hortonworks Data Plaform telles que Hadoop, Spark, Storm, Hbase, Kafka, Hive LLAP, R Server, etc …
Hive LLAP, appelé Interactive Query sur HDInsight, est un service dont la promesse est de fournir des performances en dessous de la seconde pour des requêtes portant sur des volumétries très importantes et sans limite puisque LLAP n’empêche en rien les capacités de mise à l’échelle d’Hadoop. Pour atteindre des niveaux de performance interactif, Interactive Query s’appuie sur Hadoop en utilisant le moteur d’exécution Tez (une évolution de Map Reduce) en rajoutant des démons LLAP pour mettre en cache les données et les exécuter en parallèle.

Une fois avoir posé le contexte on va pouvoir rentrer dans le vif du sujet.

Après avoir passé du temps à configurer LLAP sur un cluster HDInsight, j’ai jugé pertinent d’écrire cet article car la configuration n’est pas si facile et que même en suivant ce que la littérature déjà existante il est possible de s’arracher les cheveux et pas seulement pour des problèmes de performances mais surtout parce que soit Hive ne veut pas démarrer ou que les requêtes ne veulent pas s’exécuter ou que Yarn n’accepte pas de requête concurrente.

Pour bien configurer LLAP il faut tout d’abord commencer par comprendre l’architecture LLAP.

Architecture LLAP et notions clés

Un schéma proposé par Hortonworks donne une bonne vision du fonctionnement :

Toutes les notions clés y figurent :

  • Tez AM coordinator : c’est un type de container Yarn. Il permet d’orchestrer l’exécution des requêtes et pour pouvoir gérer des requêtes concurrentes il faut pouvoir en créer autant que de requête concurrente que l’on souhaite exécuter en parallèle.
  • Daemon LLAP : C’est un autre type de container Yarn, l’éxécution est faite à l’intérieur.
  • Executor : au sein d’un daemon LLAP des fragments de requêtes sont exécutés en parallèle via ces executor
  • Slider AM : Le slider AM supervise l’ensemble des daemon LLAP
  • Queue : Cette notion n’est pas présente dans le schema ci-dessus. Les queues permettent au Yarn scheduler d’attribuer/allouer/limiter les ressources entre les différentes applications soumises. Lorsque le cluster est utilisé en mode interactif il n’est possible de n’utiliser qu’une seule queue. Mais grâce aux queues hiérarchiques il est possible de créer une structure plus complexe pour prioriser les allocations de ressources de manière personnalisée entre différents types de population.

Lorsque l’on créé un cluster de type Interactive Query sur HDInsight on a le choix entre 2 types de configuration pour les headnodes et les workernodes : DS13v2 et DS14v2. Pour le headnode une configuration de type DS13v2 suffira largement. Pour les workernodes ca se discute plus. Nous avons opté pour des nœuds DS14v2 c’est à dire avec 112Go de RAM et 16 cœurs. La configuration de LLAP est liée à 100% à la configuration matériel du worker node. Donc en cas de scale down des workers nodes il faut prévoir d’appliquer un paramétrage différent. Je vais donc vous présenter le paramétrage pour des workers node DS14v2.

Ambari peut vous aider à configurer les paramètres liés aux paramètres que vous voulez modifier. Cependant dans un contexte PAAS, il est à mon sens indispensable d’automatiser la configuration afin de pouvoir tuer le cluster et le recréer avec une certaine configuration et ainsi économiser de l’argent et aussi pouvoir scale up ou scale down et modifier les configurations liées au nombre de nœud ou à la taille si l’on décide à la recréation de modifier la taille des wokernodes.

Le paramètres clés :

Avant toutes choses il faut commencer à configurer LLAP en fonction du montant de RAM disponible sur chaque Worker node et également de la mémoire maximum allouée pour Yarn (yarn.nodemanager.resource.memory-mb). Dans notre cas nous définirons 103936 MB afin de laisser un peu de mémoire pour d’autres services.

Fichiers de configuration Settings Valeur
hive-interactive-env llap_headroom_space 4105
hive-interactive-env llap_heap_size 65536
hive-interactive-env hive_heapsize 2048
hive-interactive-site hive.llap.daemon.yarn.container.mb 86015
hive-interactive-site hive.llap.io.memory.size 16374
hive-interactive-site hive.llap.io.threadpool.size 16
hive-interactive-site hive.llap.daemon.num.executors 16
hive-interactive-site hive.server2.tez.default.queues llap
hive-interactive-site hive.tez.container.size 4096
hive-site hive.tez.container.size 3584

 

Reportons ces paramétrages sur un schéma pour mieux comprendre. Avec ce schéma on comprends qu’il n’y a qu’un seul démon sur le worker node et que la mémoire du démon est partagée entre la mémoire nécessaire pour la Java virtual machine (JVM) (llap_headroom_space), la mémoire nécessaire pour les l’exécution (llap_heap_size) qui dépend elle même du nombre d’exécutor (hive.llap.daemon.num.executors) et de la mémoire requise pour chaque executor par défaut 4Gb, et de la taille du cache (hive.llap.io.memory.size)

Afin de pouvoir exécuter en parallèle le nombre de requête concurrente demandée (hive.server2.tez.sessions.per.default.queue): il faut pouvoir instancier les containers tez (tez.am.resource.memory.mb). Ces containers sont nommés les Tez AM coordinateurs et permettent d’orchestrer l’exécution de la requête. Si Yarn n’arrive pas à allouer un container conformément au nombre de requête concurrente demandée, les requêtes ne pourront pas s’exécuter comme demandé.

Schéma illustrant la répartition de la mémoire au sein des différents containers

Un autre paramètre important est le nombre de nœud à utiliser pour le cluster (num_llap_nodes). Si ce settings est laissé à 1 alors que le nombre de nœuds est passé à 16 sur Azure, alors 15 nœuds à 1,26€/H (prix à date sur la région Europe du Nord) seront facturés pour rien.
Ensuite, on peut décider de ne pas dédier tous les nœuds à un usage interactive query, parce que l’on a besoin par exemple de faire de la compaction via ACID et d’avoir des job MapReduce qui tourne en parallèle par exemple ou bien parce que l’on veut faire cohabiter LLAP avec Spark.
Dans ce cas il faudra déterminer le nombre de nœud à utiliser pour LLAP avec la propriété num_llap_nodes_for_llap_daemons.

Les settings relatifs à Interactive Query ne sont pas les seuls à modifier pour espérer avoir un cluster stable et performant. Il faut également paramétrer Yarn et activer le capacity Scheduler (CPU sceduling et CGroups), activer la préemption, et paramétrer la Queue LLAP afin de maximiser la concurrence des requêtes. Tous ces points nécessitent d’être développé lors d’un billet de blog dédié à cela.

Liens intéressants :
https://fr.hortonworks.com/blog/yarn-capacity-scheduler/
https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.3/bk_yarn-resource-management/content/setting_user_limits.html

0 commentaires

Soumettre un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Découvrez nos autres articles

Aller au contenu principal