Nous devrions être excités que la communauté Apache Hive ait publié la plus grande version et annoncé la disponibilité d’Apache Hive 2.0.0. Elle apporte de grandes et passionnantes améliorations dans la catégorie des nouvelles fonctionnalités, des performances, des optimisations, de la sécurité et de la convivialité. Explorons les fonctionnalités en détail ci-dessous :
HBase pour stocker les métadonnées de Hive
L’implémentation actuelle du métastore est lente lorsque les tables ont des milliers de partitions ou plus. Avec les moteurs Tez et Spark, nous poussons Hive à un point où les requêtes ne prennent que quelques secondes à s’exécuter. Mais la planification de la requête peut prendre autant de temps que son exécution. Une grande partie de ce temps est consacrée aux opérations sur les métadonnées. En raison des limitations d’échelle, nous n’avons jamais permis aux tâches de communiquer directement avec le métastore. Cependant, avec le développement du LLAP, cette exigence devra être assouplie. Si nous pouvons l’assouplir, d’autres cas d’utilisation pourraient en bénéficier. Manger notre propre nourriture pour chiens. Plutôt que d’utiliser des systèmes externes pour stocker nos métadonnées, il y a des avantages à utiliser d’autres composants du système Hadoop.
Des démons à longue durée de vie pour l’exécution de fragments de requête, les E/S et la mise en cache
LLAP est le nouveau modèle d’exécution hybride qui permet des gains d’efficacité sur l’ensemble des requêtes, tels que la mise en cache des données en colonnes, des pipelines d’opérateurs conviviaux JIT et une réduction des frais généraux pour les requêtes multiples (y compris les requêtes simultanées), ainsi que de nouvelles fonctionnalités de performance telles que les E/S asynchrones, le pre-fetching et le traitement multithread. Le modèle hybride consiste en un service à longue durée de vie interagissant avec des conteneurs élastiques à la demande servant de cadre étroitement intégré basé sur le DAG pour l’exécution des requêtes. La première version de LLAP est livrée dans la version 2.0 de Hive. Le composant a fait l’objet de nombreux exercices sur des clusters de test et des clusters réels, et a été testé, mais on s’attend à ce qu’il ait des défauts dans cette version initiale. Les limitations actuelles sont : supporté avec Tez uniquement ; ne supporte pas les tables ACID ; l’élévateur d’E/S et le cache ne supportent que le format ORC et l’exécution vectorisée.
HPL/SQL – Implémentation de SQL procédural dans Hive
Dans cette nouvelle version, nous avons l’outil PL/HQL (www.plhql.org) qui implémente le SQL procédural pour Hive (en fait n’importe quelle implémentation SQL-on-Hadoop et n’importe quelle source JDBC).Alan Gates a proposé de le contribuer à Hive sous le nom de HPL/SQL (paquet org.apache.hive.hplsql). Cela va être très utile pour les communautés SQL.
Hive sur Spark Container
Lorsque le job Hive est lancé par Oozie, une session Hive est créée et le script du job est exécuté. La session est fermée lorsque le travail Hive est terminé. Ainsi, la session Hive n’est pas partagée entre les jobs Hive, que ce soit dans un workflow Oozie ou entre les workflows. Étant donné que le parallélisme d’un travail Hive exécuté sur Spark est influencé par les exécuteurs disponibles, ces travaux Hive subiront le surcoût lié à la montée en puissance des exécuteurs. L’idée ici est d’attendre un peu pour que suffisamment d’exécuteurs puissent se présenter avant qu’un travail puisse être exécuté.
Hive sur Spark parallèle ORDER BY
C’est l’une des plus grandes fonctionnalités, car si nous avons besoin de trier les enregistrements alors nous devons manuellement définir / forcer le nombre de réducteurs à 1 pour l’avoir dans un seul fichier. Mais avec la fonctionnalité ci-dessus dans la nouvelle version, nous n’avons pas à forcer le reducer# à 1 car spark supporte le tri parallèle.
Élagage dynamique des partitions
Tez a mis en œuvre la taille de partition dynamique et c’est une belle optimisation et nous devrions mettre en œuvre la même chose dans HOS.
Hive-on-Spark Self Union/Join
Une requête Hive peut essayer de balayer la même table plusieurs fois, comme self-join, self-union, ou même partager la même sous-requête. Comme vous le savez peut-être, Spark prend en charge le cache des données RDD, ce qui signifie que Spark met en mémoire les données RDD calculées et les récupère directement de la mémoire pour la prochaine fois, ce qui évite le coût de calcul de ce RDD (et tous les coûts de ses dépendances) au prix d’une utilisation accrue de la mémoire. En analysant le contexte de la requête, nous devrions être en mesure de comprendre quelle partie de la requête pourrait être partagée, de sorte que nous puissions réutiliser le RDD mis en cache dans le travail Spark généré. Et aussi la sous-requête, qui s’est traduite par des travaux séparés, mais équivalents dans SparkWork, la combinaison de ces travaux équivalents en un seul aiderait à bénéficier de l’optimisation de la mise en cache RDD dynamique suivante.
Les améliorations de l’OCB
C’est l’une des belles améliorations TPC-DS queries 51 échoue avec Failed to breakup Windowing invocations into Groups. Au moins un groupe doit dépendre uniquement des colonnes d’entrée. Cette version vérifie également les dépendances circulaires.
Apache Parquet predicate pushdown
Lorsque l’on filtre des tables Parquet en utilisant une colonne de partition, la requête échoue en disant que la colonne n’existe pas : Il est correct que la colonne de partition ne fait pas partie du schéma Parquet. Donc, la solution devrait être de supprimer cette expression du PPD Parquet. Cette fonctionnalité aide beaucoup dans les performances et optimisations.
Métriques basées sur Codahale
Il y a un système de métriques Hive actuel qui s’accroche à un reporting JMX, mais toutes ses mesures, modèles sont personnalisés. Il s’agit de faire un autre système de métriques qui sera basé sur Codahale (c’est-à-dire yammer, dropwizard), qui a l’avantage suivant : Un modèle de métrique bien défini pour les métriques fréquemment utilisées (par exemple les métriques JVM), des mesures bien définies pour toutes les métriques (par exemple max, mean, stddev, mean_rate, etc.), et des cadres de rapport intégrés comme JMX, Console, Log, serveur web JSON. Il est utilisé pour de nombreux projets, y compris plusieurs projets Apache comme Oozie. Dans l’ensemble, les outils de surveillance devraient trouver plus facile de comprendre ces modèles communs de métrique, de mesure, de reporting. Le sous-système métrique existant sera conservé et pourra être activé si une rétrocompatibilité est souhaitée.
