[JSS 2014] Session : Deep Dive : Hive

Speaker : David Joubert & Julien Buret
Level : 400

Objectif : Découvrir la technologie Hive et démontrer la convergence Datawarehouse et Big Data

Introduction :
Intégré par défaut sur la plateforme Hadoop, Hive est un lien manquant entre SQL et Big Data dans l’éco-système.
Langage, stockage, exécution, cet entrepôt de données Big Data s’est toujours inspiré de ses équivalents relationnels dans son évolution.
Nous allons présenter Hadoop dans un premier temps puis Hive et son historique, type de stockage et quelques comparaisons de performance.
Le Big Data n’est pas au programme de cette session, ainsi que l’analyse en temps réel.

Hadoop :
Hadoop est un Framework permettant de développer des applications distribuées et scalables. Ce n’est pas une base. Hadoop utilise un système de fichiers distribués (HDFS) et le moteur de calcul MapReduce.
Sa mauvaise performance sur les données en temps réel est un inconvénient. Beaucoup d’évolutions dépendent de cette problématique.

Hive :
Historiquement, Hive était un projet interne à Facebook lancé en 2007. Il a été rendu open source en 2009. Aujourd’hui, il est possible de requêter en SQL sur Hadoop (HiveQL).
Hive n’est pas un moteur de base de données. C’est une application cliente de Hadoop qui permet de générer des jobs MapReduce à partir d’un langage plus performant.
Hive se compose de 2 principaux modules :

  • Hive METASTORE : base relationnelle pour indiquer comment est structurée une table dans Hadoop (HDFS)
  • Hive DRIVER : interprête les requêtes SQL fournies par le client et les transforme en job MapReduce (M/R)

DeepHive_HiveFonctionnementGlobal

Exemple de plan d’exécution :

DeepHive_MR

Démo Hive : Création d’une table, dite externe (ne copie pas les données sur disque)
Petite comparaison SQL VS Hive

Une démo rapide pour montrer la création d’une table externe :
CREATE EXTERNAL TABLE tableName (

);

Quel usage de Hive ?
On stocke le maximum de données dans Hadoop. Hive permet de traiter les use-cases complexes qu’on ne peut pas gérer dans les datawarehouses. L’inconvénient, c’est qu’il est très difficile d’avoir des requêtes interactives dues à ses latences.
Plusieurs projets ont été développés afin de gérer ces requêtes interactives (Presto, Apache, HawQ, …).

DeepHive_QuelUsage
« schema on read » = il n’y a pas de validation à l’insertion. Elle se fait à la lecture

Nouveaux moteurs :
MapReduce, c’est fini pour Hadoop. De nouveaux moteurs d’exécution ont fait leur apparition : Tez, Spark, etc. Nous allons nous focaliser sur Tez.
Tez supporte le M/R et les jointures. Il permet de construire des plans d’exécutions plus complexes que M/R (pipelining, utilisation de la mémoire à la place du disque, multiple étapes de Reduce). L’idée est de ne garder que les M/R sans écrire dans HDFS.

Démo : Hive M/R VS Hive Tez
Petite comparaison de performance entre les deux moteurs.
Résultat : Tez est environ 2 fois plus rapide que M/R.

Hive sur les données brutes :
Hive peut analyser des formats de type Text. Par contre, le parsing est coûteux et il y a un problème de compression.
Le format orienté colonne (Oriented Row Columnar, ORC) permet de stocker les données en colonne. Cela améliore les performances en lecture, écriture et traitement, notamment grâce à la compression et l’encodage des données. Grâce à cela, le traitement massif des données est plus adapté pour Hive.

Démo : Stockage natif VS Stockage en colonne

  • Création de table de type ORC : ajouter « STORED AS ORC » à la fin de la requête CREATE TABLE
  • Gain de temps d’environ 4 fois plus en stockage colonne

Vectorization :
Hive traite les données ligne à ligne alors qu’avec la Vectorization, c’est bloc à bloc.
Le Query Engine a été modifié pour traiter des « vecteurs de colonne ». Nous avons une meilleure utilisation du CPU et des caches.
L’arbre d’exécution a été optimisé (Partition pruning, Projection pruning, filter push/down). Il n’y a pas d’optimisation liée à la donnée. L’ordre des tables dans les jointures est très important.

Cost-Based Optimizer (CBO) :
Le CBO utilise les statistiques de base de données pour générer plusieurs plans d’exécution et choisir le moins coûteux.

Démo : Performance avec et sans CBO

  • Ajouter « EXPLAIN » devant la requête pour afficher le plan d’exécution
  • On désactive CBO, active le moteur Tez, sans vectorization : 136s pour 164 lignes
  • On désactive CBO, active le moteur Tez, avec vectorization : 80s pour 164 lignes
  • On créé les stats, active CBO : 69s pour 164 lignes
    • le plan d’exécution est différents des 2 précédentes configurations
    • il y a moins de mapper

Pourquoi convergence ?

DeepHive_Convergence

Futur du SQL sur Hadoop :

  • SQL 20XX
    • Supporter les fonctionnalités analytics
    • WINDOWS, ROOLUP, CUBE
  • Transaction
  • Hive LLAP
  • Materialized views

Foudhil BABA ALI & David TANG

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s