Conversion des DDL

Lorsque vous initiez un projet Hadoop, un sujet à traiter consiste à initialiser les structures de données sous Hive. Vous pouvez créer un script qui va lire un fichier XML ou JSON décrivant les structures à importer, mais ce dernier doit être initialisé d'une façon ou d'une autre. Et si vous devez traiter des milliers de table, l'exercice devient vite long et ingrat.

L'autre solution consiste à écrire un script ou un programme qui va convertir une table relationnelle provenant souvent d'une base Oracle en une table Hive. Vous pouvez aussi chercher un outil de conversion déjà écrit, mais je n'en ai pas trouvé un suffisamment complet pour réaliser mon cahier des charges, ni sur github, encore moins chez un éditeur, ce sujet ayant toujours été le parent pauvre des outils de base de données.

En source, vous pouvez avoir plusieurs générateurs de bases de données ( outil de conception comme Power AMC,  binaires exportant une base de données, ... ). La première étape consiste à s'assurer que les options de ces différents outils soient identiques à chaque génération de scripts DDL, le but n'étant pas d'écrire un compilateur, mais simplement d'être capable d'extraire les données utiles de la source.

On peut décomposer le programme en deux principales parties, une première partie consiste à récupérer les informations utiles ( nom de  la table, noms et types des colonnes, partitionnement, commentaires, ... ), la seconde génère la structure Hive à introduire dans le catalogue de données.

Pour la première partie, le point à retenir est de rechercher les informations utiles dans le fichier d'export initial et non pas de chercher à supprimer toutes les informations inutiles. Vous verrez rapidement, avec cette stratégie, vous obtiendrez un code plus simple et surtout vous n'aurez pas à le modifier systématiquement à chaque nouvelle base traitée. Si les outils de génération se multiplient, n'hésitez pas à traiter les fichiers par type de famille afin de conserver un code maintenable même si vous éclatez votre code.

Pour la seconde partie, la conversion, il est intéressant au préalable de créer une structure intermédiaire qui catégorise les informations utiles récupérées durant la première phase ( objets de type table, de type colonne, de type commentaire, ... ). De cette manière, la génération d'une table Hive se base sur cette structure et donc votre code de génération Hive sera indépendant des différentes sources d'export, il ne sera modifié que si de nouveaux objets sont à traiter dans le mécanisme de conversion.

Pour ma part, j'ai écrit l'utilitaire en bash, car souvent en début de projet, on ne dispose pas d'environnements de développement style Eclipse, mais il peut être écrit dans n'importe quel langage et cet exercice vaut vraiment le coup si vous voulez créer un vrai data lake sous Hadoop, l'écriture initiale vous prendra environ 2 à 3 semaines suivant la complexité de la conversion. Mais après, moyennant quelques mises à jour au fil de l'eau, vous pourrez créer des milliers de tables en quelques minutes.

Découverte du cloud

Depuis quelques mois, j'étudie les fondamentaux sur les trois principaux cloud ( aws, azure et gcp ). Pour ce faire, je me suis appuyé sur les cours de Cloud Academy.

Les cours sont intéressants, ils permettent d'acquérir une vision générale sur les principaux composants d'un cloud ( réseau, vm, bases de données, sécurité, ... ) . L'émergence de Kubernetes n'est pas ignorée. La partie managée ( ha, auto-scaling, patching, ... ) qui consiste à gérer de manière automatique l'infrastructure est traitée, tout comme les services prêts à l'emploi du style App Engine qui se généraliseront probablement à l'avenir si l'usage cible reste relativement peu complexe.

Les TPs mériteraient d'être plus consistants pour certains, mais ils deviennent plus intéressants quand vous passez au mode intermédiaire sur un cloud. Pour aws et azure, les ressources sont nombreuses et variées, pour gcp, le cataloque est en cours de fabrication, google s'étant mis à vendre son cloud sur le tard.

Quelques examens permettent de vérifier ses connaissances, il y a même des cours qui préparent à certaines certifications pour les amateurs.

LLAP

LLAP est dans les grandes lignes l'équivalent d'Impala.

Contrairement à Impala, la documentation est bien moins fournie ( outil moins utilisé ? ). Pour ma part, je vais le découvrir dans les prochaines mois ... en attendant la fusion Hortonworks-Cloudera et son futur produit, un temps appelé Unity.

Un bon point lié à cette fusion: on va effectuer une montée de version ( 2.6 -> 3.x ) d'HDP pour être par la suite candidat à une migration vers la nouvelle stack du nouvel ensemble.

Cela nous permettra d'utiliser les nouvelles fonctionnalités d'Hive 3.0 ( le mode "transactionnel" apparu avant mais qui se généralise, les vues matérialisées, les contraintes d'intégrité, ... ).

Deux bons pointeurs sur LLAP:
- Home page;
- Configuration.