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

Depuis plus d'un an, je pilote un socle applicatif autour de la stack Cloudera afin de la rendre disponible à des usages ( = applicatif métier utilisant les données centralisées dans un data lake ).

La stack Cloudera est un package de multiples services ( hive, impala, solr, spark, ... ) administrable et déployable via un outil de management, cloudera manager, bien utile pour les équipes d'infrastructure, mais en terme applicatif, tout reste à  faire !

L'idée générale est de créer des patterns ( = services ), des fonctions réutilisables pour l'ensemble des usages leur permettant de pouvoir traiter de la data par de multiples canaux divers et variés.

Bien entendu, ces patterns doivent être déployables sur des infrastructures multi-noeuds, plus précisément un environnement logique composé d'un ensemble de patterns est susceptible d'être installé sur plusieurs environnements multi-noeuds.

Pour ce faire, on a écrit un outil de génération d'environnement en bash s'appuyant sur maven et on utilise un outil d'intégration continu propre au client pour déployer de manière automatique un environnement logique sur toutes les plates-formes disponibles ( qqes centaines de cpu, qqes TB RAM et qqes centaines de TB disque pour vous donner une idée de ce qu'est une infra big data ).

Tout cela pour vous dire que tout est à créer dans le big data 1.0 en mode non cloud !

Bon, revenons à nos patterns. On peut distinguer plusieurs types de patterns, ceux qui permettent de manager le socle ( outil de déploiement, outil de gestion des structures de données, ... ), ceux qui perment d'alimenter le data lake ( loader en mode batch, streaming de flux de données, reprise de données via sqoop ... ), ceux qui permettent d'épurer la donnée loin d'être très propre ( crunching via un outil comme Talend ) et ceux qui offrent  enfin ( ! ) une plus-value pour les usages ( batch de traitement des données en map/reduce, traitement BI via des outils comme Impala et Kudu, V360, data science pour les plus avancés, ... ).

La genèse d'un tel système est tout sauf une sinécure. Après une phase d'architecture pour bien poser l'infrastructure et les besoins des usages, on peut alors d'une part commander l'infrastructure, l'installer et la rendre opérationnelle ( plusieurs mois ) et d'autre part sur des machines mono-noeuds construire les premiers patterns pour alimenter le data lake ( structures de données, chargement des données ).

Une fois l'infra posée, on peut réfléchir à l'outil de construction et de déploiement des patterns tout en commençant à nettoyer et à enrichir les données présentes dans le data lake. A ce moment-là, les usages commencent à avoir accès aux données via JDBC pour effectuer des requêtes en mode SQL ( hive, impala, ... )  et commencer à aller plus loin via des outils de dataviz comme Tableau ou SAS.