Comment avons-nous fait pour que notre Impala s’exécute plus rapidement ?
Donc, vous avez votre Hadoop, des téraoctets de données y entrent par jour, les ETL sont effectués 24/7 avec Spark, Hive ou dieu m’en garde – Pig. Puis, une fois que les données sont dans la forme exacte que vous souhaitez (ou même avant) et que tout est parfait, les analystes veulent les interroger. Si vous avez choisi Impala pour cette mission, cet article est pour vous.
Nous utilisons Impala pour quelques objectifs :
- Laisser les analystes interroger de nouveaux types de données sur lesquels les ingénieurs de données n’ont pas encore créé d’ETL.
- Laisser les analystes interroger des données dont la destination finale (après le processus ETL) est HDFS.
- Génération de rapports (avec nos propres outils).
- Systèmes d’alerte de surveillance & (sur les nouvelles données qui arrivent toutes les heures).
Nous avons des dizaines de milliers de requêtes par jour, chaque requête scanne en moyenne quelques gigaoctets de données et prend 10 secondes. Notre cluster n’est pas énorme en termes de matériel et de nombre de nœuds que nous avons. Sans compter que nous avons des centaines d’autres workflows (Spark, Pig, Hive) qui tournent tous les jours sur le même cluster.
Dans cet article, je partagerai les connaissances et les conclusions que nous avons tirées de notre projet d’optimisation d’Impala.
Qu’est-ce qu’Impala ?
Si vous ne savez pas ce que c’est – lisez à ce sujet dans le Guide Cloudera Impala, puis revenez ici pour les choses intéressantes.
Impala Vs. Autres solutions SQL-on-Hadoop
Il n’y a rien à comparer ici. De nos jours, Hive est seulement pour les ETL et le traitement par lots. Vos analystes obtiendront leur réponse bien plus rapidement en utilisant Impala, bien que contrairement à Hive, Impala ne soit pas tolérant aux pannes. Mais c’est ok pour un moteur MPP (Massive Parallel Processing).
Impala est plus rapide que Hive parce que c’est un moteur complètement différent et Hive est au-dessus de MapReduce (qui est très lent en raison de ses trop nombreuses opérations d’E/S sur disque).
Impala Vs. SparkSQL
Oui, SparkSQL est beaucoup plus rapide que Hive, surtout s’il n’effectue que des calculs en mémoire, mais Impala est toujours plus rapide que SparkSQL.
Il est plus rapide parce qu’Impala est un moteur conçu spécialement pour la mission de SQL interactif sur HDFS, et il a des concepts d’architecture qui l’aident à y parvenir. Par exemple, les démons ‘always-on’ d’Impala sont actifs et attendent les requêtes 24 heures sur 24, 7 jours sur 7, ce qui n’est pas le cas de SparkSQL. Et quelques autres raisons comme le mécanisme de codegen d’Impala, l’optimisation du format Parquet, les statistiques, le cache de métadonnées, etc.
Le serveur JDBC/ODBC Thrift de SparkSQL peut être un concurrent comparable à Impala, mais comme je n’ai pas pu trouver beaucoup de choses à ce sujet sur le web – je vais juste l’énoncer ici et si vous avez des connaissances et de l’expérience sur ce sujet, s’il vous plaît écrivez un post moyen à ce sujet. Je pourrais en écrire un dans un avenir proche.
Impala Vs. Presto
Presto est une technologie très similaire avec une architecture similaire. Selon presque tous les benchmarks sur le web – Impala est plus rapide que Presto, mais Presto est beaucoup plus pluggable qu’Impala. Impala est supposé être plus rapide lorsque vous avez besoin de SQL sur Hadoop, mais si vous avez besoin d’interroger plusieurs sources de données avec le même moteur de requête – Presto est meilleur qu’Impala. Il suffit de voir cette liste de connecteurs Presto. Impala peut également interroger Amazon S3, Kudu, HBase et c’est essentiellement tout.
Pour plus de lecture sur Presto- c’est un examen complet de PrestoDB que j’ai fait.
Bonnes pratiques d’Impala
Impala est plus performant lorsqu’il interroge des fichiers stockés au format Parquet. Toute la technologie sur laquelle Cloudera Impala est basée provient du livre blanc Google Dremel et dans ce document, vous pouvez trouver le concept sur lequel Parquet est basé. Donc n’oubliez pas de ne pas interroger les fichiers json, csv ou de séquence – Parquet vos fichiers avant de laisser les analystes les interroger.
Travailler avec des partitions
Partitionnez vos données en fonction des requêtes de vos analystes. Impala n’a pas d’index, c’est donc le seul moyen de réduire la quantité de données que vous traitez à chaque requête. Nous utilisons DT (date et heure) comme principale méthode de partitionnement pour la plupart de nos tables. Le surpartitionnement peut être dangereux (continuez à lire pour plus de détails).
L’instruction REFRESH
L’instruction REFRESH peut être une opération coûteuse, surtout si vous avez des milliers de tables avec des données qui s’y ajoutent chaque heure. Nous exécutons plus de 10 000 rafraîchissements par jour. Ce sont mes meilleures pratiques pour les rafraîchissements :
- Depuis Impala 2.7, vous pouvez effectuer un rafraîchissement sur une partition spécifique, utilisez cela pour rendre l’instruction REFRESH beaucoup plus légère.
- Architecture des tables chaudes & archivées – chaque table aura une version chaude et une version archivée. La version chaude contiendra les dernières 24 heures et un rafraîchissement sur cette table se produira toutes les heures et sera beaucoup plus léger. Chaque jour, la table chaude sera fusionnée avec la table archivée et un rafraîchissement plus important de cette table sera effectué. Et bien sûr un VIEW au-dessus de ces 2 qui les unions pour que les utilisateurs ne s’en rendent même pas compte.
- Ne pas avoir trop de métadonnées (fichiers et partitions) par table (voir la section ‘Taille optimale des fichiers’).
Calculer des stats
Les statistiques rendront vos requêtes beaucoup plus efficaces, surtout celles qui impliquent plus d’une table (jointures). Par conséquent, vous devriez calculer les statistiques pour toutes vos tables et maintenir un flux de travail qui les maintient à jour avec des statistiques incrémentielles. Pour plus de détails techniques, lisez la section Statistiques des tables et des colonnes de Cloudera Impala.
Taille optimale des fichiers – 256 Mo/fichier
TL;DR : Assurez-vous de ne pas avoir trop de petits fichiers – cela nuira vraiment à votre serveur de catalogue, aux rafraîchissements et aux performances des requêtes.
Nous avons remarqué que notre serveur de catalogue Impala continue de planter 4 fois par semaine et que nos requêtes prenaient trop de temps. Nous avons ensuite réalisé que nous avions beaucoup trop de fichiers et de partitions. Nous travaillions avec des partitions DT sur une base horaire, peu importe la taille des partitions.
De cette façon, après 2 ans, nous avions des tables avec 17 Go de données et 17 000 partitions – ce qui signifie que chaque partition est d’environ 1 mb. Nous avions des tables avec des partitions de la taille de 50KB. Et comme si cela ne suffisait pas, certaines de ces petites partitions contenaient plusieurs fichiers.
Au début, nous pensions que cette quantité déraisonnable de fichiers ne faisait que rendre nos métadonnées trop grosses et que c’était la raison pour laquelle les rafraîchissements étaient si lourds et que le serveur de catalogues se plantait. Mais ensuite, nous avons réalisé que la quantité de fichiers affecte également très mal les performances de nos requêtes (en raison du nombre de fils d’analyse nécessaires pour lire autant de fichiers de parquet).
À quel point ? Nous avons effectué un test sur une table réelle de 500 Mo que nous avons, avec 17 280( !) partitions et fichiers. Nous avons créé une nouvelle version fusionnée de cette table avec seulement 2 fichiers, 1 par année. La partie SCAN HDFS dans le résumé de l’exécution de la requête était 2 000 fois plus rapide. C’est la partie où nous avons compris à quel point nos petits fichiers nous nuisent.
Nous avons donc commencé à gérer nos partitions et à les fusionner dans la taille de fichier optimale qui est d’environ 256mb.
Les tables avec un partitionnement horaire sont devenues partitionnées quotidiennement, mensuellement ou annuellement. Chaque partition n’a qu’un seul fichier (sauf si sa taille est > 256mb)
Configurer des coordinateurs &Exécuteurs par daemon
Depuis Impala 2.9, vous pouvez déterminer quels daemons impala sont des coordinateurs et lesquels sont des exécuteurs. C’est un énorme changement parce qu’avant cela – tous les daemons étaient des coordinateurs et des exécuteurs et l’overhead d’être un coordinateur est très consommateur de ressources pour les gros clusters.
Cela signifie par exemple que chaque nœud garde tout le cache de métadonnées dans sa RAM. Et si vous avez par exemple, 20 Go de métadonnées et 50 nœuds – cela signifie un gaspillage de 1 To de RAM juste parce que tous les nœuds sont également des coordinateurs !
Testez quel est le meilleur taux de coordinateurs/exécuteurs pour vous et utilisez-le. Conseil : commencez avec 2 coordinateurs par cluster.
Types de données de colonne
Au début, nous avons utilisé STRING pour toutes nos colonnes dans toutes les tables. C’est une très mauvaise pratique qui a beaucoup nui aux performances. Vous devriez essayer de choisir le type le plus adapté à la colonne parmi tous les types de données pris en charge par Impala.
Les limites de requêtes Impala
Vous devriez utiliser le contrôle d’admission Impala pour définir différents pools à différents groupes d’utilisateurs afin de limiter l’utilisation de certains utilisateurs à X requêtes simultanées ou Y mémoire. Mais encore plus que cela – nous avons construit notre propre système pour gérer les utilisateurs et les requêtes problématiques.
Notre système échantillonne les requêtes en cours d’exécution toutes les 10 secondes et si une requête s’exécute pendant plus de 30 minutes – elle est tuée. Si le même modèle de requête a été tué 90% des fois le mois dernier parce qu’il prenait plus de 30 minutes – notre système le tuera immédiatement lorsqu’il reconnaîtra le modèle, afin de protéger notre infrastructure.
Tuer des requêtes n’est pas un nouveau concept – Amazon Athena l’a fait avant nous, mais tuer des requêtes uniquement par modèle problématique – c’est quelque chose que personne d’autre ne fait et c’est la seule façon de gérer des milliers d’analystes affamés.
Summary
Si vous devez laisser vos analystes exécuter des requêtes SQL ad-hoc et interactives sur votre Hadoop – Impala est une excellente solution. Vous devriez lire le Guide Cloudera Impala pour devenir un très bon administrateur Impala et n’oubliez pas de travailler selon les meilleures pratiques que j’ai expliquées ici.