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

Le socle applicatif est écrit sur la base de trois langages ( bash linux, Python, Java ).

Le bash articule le coeur du socle et de nombreuses parties, en particulier la gestion des structures de données, sont développées en shell. Pourquoi ? Il permet d'utiliser les binaires de la stack Cloudera ( beeline, hbase shell, solrctl, hbase-indexer, ... ) et de cette manière, on bénéficie de toutes les fonctionnalités pas toujours disponibles dans des API de plus haut niveau.

Le bash est bien entendu un langage difficile à appréhender, mais on peut désormais l'écrire de manière maintenable et modulable, avec pour notre part l'utilisation de "contextes" qui sont en fait des librairies réutilisables par le socle. De plus, si pour certaines opérations comme par exemple l'analyse de fichiers xml, le bash n'est pas l'outil idoine, loin de là, on fait alors appel à Python, un interpréteur très en voque dans le big data, qui a le mérite d'être plus souple qu'un langage compilé comme Java.

J'apprécie le bash car c'est un outil sans équivalent en terme d'utilitaires. Un exemple: l'utilisation de taskset pour attribuer une tâche à un CPU.

On a ajouté du Python pour des besoins ponctuels, mais aussi car c'est l'outil favori des data scientists, même si avec l'avènement de la plate-forme spark et de scala, il sera intéressant de voir si le machine/deep learning ne migrera pas dans une certaine mesure vers ce type d'infrastructure où tout est optimisé pour la parallélisation des traitements et des données ( rdd ) dans des environnements distribués.

Initialement, on a développé le socle avec des outils tels putty, notepad++, ... bref des outils peu appréciés par certains développeurs peu habitués à linux. C'est pourquoi on propose aussi de développer sur Eclipse et donc de baser le point de départ du mécanisme d'intégration continue sur cet outil. Pour faciliter la tâche des futurs développeurs du socle, on a aussi écrit quelques outils en Python histoire de nous familiariser davantage avec ce langage.

Enfin, on utilise Java car une partie du data loader repose sur un composant Java précédemment écrit chez un autre client. De plus, il faut savoir que Java est un langage incontournable chez les grands comptes français.

En tant qu'ex-consultant Oracle, je suis sensibilisé par la gestion des structures de données et le socle contient donc un outil qui permet d'assurer le déploiement des mêmes structures de données sur tous les environnements de l'infrastructure. Cela paraît anodin comme ça, mais je peux vous assurer que c'est très rare dans les faits ...

De plus, autant à terme dans le big data 2.0, vous aurez des data loader, des outils de streaming, des outils de crunching, ... en mode graphique à l'image des anciens ETL, autant la gestion des structures de données sera probablement comme pour les bases relationnelles la grande oubliée de l'histoire car peu génératrice de business ...

On gère déjà pas mal de fonctionnalités ( droits HDFS, ACL, Sentry, partitionnement, format de fichiers, ... ) et la manière dont a été conçu cet outil permettra d'ajouter d'autres fonctionnalités de manière souple, par exemple des éléments de performance si nécessaire.

Le data loader purement technique est enrichi d'une couche de tables au sens Hive compatible Impala qui permet d'avoir des référentiels de données d'une part et une historisation des données entrantes d'autre part. Il fera à terme, il faut l'espérer, le bonheur des data scientists pour leur exploration des données en mode brut.