Création d'un socle big data ( partie 3 )

Après avoir présenté le socle en terme d'architecture technique, détaillons un premier usage, qui ne sera pas une v360, premier usage habituel pour un data lake ( au prochain épisode ! ), mais un outil BI couplé à Hadoop.

L'idée est ambitieuse, elle consiste à vouloir remplacer progressivement un infocentre ( Oracle, puis DB2 ) par une solution Hadoop pour effectuer des requêtes analytiques plus rapidement et même de pouvoir exécuter de nouvelles requêtes qui ne se terminent pas habituellement.

Pour ce faire, le choix s'est porté sur Impala, les données étant stockées sous HDFS soit en format texte, soit en format Parquet pour optimiser le stockage et les performances. On n'a pas introduit Kudu pour de multiples raisons: manque de maturité, Kerberos à l'époque pas implémenté, PRA non disponible, ...

Impala est un service dédié à l'analytique, de nombreuses présentations sont disponibles sur slideshare pour bien cerner la technologie, par exemple : Impala internals.

La recette étant bien avancée, l'objectif est en passe d'être atteint, il reste encore sur le premier lot à réécrire quelques requêtes adaptées à l'optimiseur Oracle, mais pas à l'optimiseur Impala. Mais le nombre est restreint comparé au nombre de requêtes migrées.

Une première remarque, n'oubliez pas de calculer les statistiques sur les tables suite à une mise à jour importante, il n'existe pas encore une fonctionnalité permettant le recalcul automatique des statistiques si nécessaire.

Impala est un système effectuant des scans en parallèle sur plusieurs noeuds, la scalabilité étant assurée par l'ajout de noeuds si les performances se dégradent. De plus, il nécessite une quantité de RAM non négligeable ( 256 GB RAM par noeud ).

Par conséquent, le tuner ne dispose pas d'index pour optimiser ses requêtes. Il doit donc porter une attention toute particulière au choix de ses jointures. Heureusement, Cloudera dispose d'une grammaire riche dans ce domaine et vous vous apercevrez vite que parfois, il faudra changer le type de jointure pour éviter des temps de réponse trop élevés.

Pour des tables de grande volumétrie, il vous faudra aussi penser à partitionner vos tables pour éviter des jointures trop importantes.

Il n'existe pas encore de livres sur le tuning Impala de la qualité de ceux disponibles sur Oracle ( J.Lewis, Antognini, ... ). La seule documentation est celle offerte par Cloudera, heureusement de qualité. Le point de départ est ici.

Pour finir, un dernier tip: il existe bien des hints pour Impala et le hint STRAIGHT_JOIN vous permettra de reprendre la main sur les jointures.