Aimen Sijoumi

MyMoneyBank a dû faire fasse à l'arrêt de son logiciel de gestion de crédit (FIBOS) et en conséquence, développer l'ensemble des composants afin de le faire en interne (avec la collaboration de Sopra pour le logiciel Cassiopae). Ce projet s'intitula GROM, pour Grand Raid d'Outre Mer.

Le projet GROM durera pour moi 2 ans. Il m'a été demandé de m'impliquer à tous les niveaux afin de permettre l'élaboration de Jobs Spark pour des traitements de comptabilité (on en compte une cinquantaine). Ces derniers se sourçaient dans un DataLake sur l'EMR (Elastic Map Reduce) où étaient mis à disposition des fichiers parquet. Afin d'ordonnancer l'ensemble des traitements, j'ai participé à l'élaboration des workflow (DAG) sur Airflow.

De plus en dehors du projet GROM, il y avait des besoins de traitements singuliers (sans passer par le DataLake) ce qui a conduit à la mise en place de Batchs Java pour des besoins particuliers. Ces traitements étaient en Java (Spring).

De manière plus détaillée, j'ai principalement agit sur :

- La création de plus d'une soixantaine de Job Scala Spark récupérant des données de AWS S3 via AWS EMR ; puis de les filtrer ; les formater ; les agréger et enfin les sauvegarder dans une base de données (AWS RDS) ;

- La création (avec le métier) d'un algorithme de calcul d'impayés qui est par la suite mis à disposition de toute l'équipe Finance ;

- La mise en place d'un procédé de gestion de base de données en historisant les scripts SQL via Flyway ;

- La création d'une dizaine de Dags Airflow (Python) permettant d'ordonnancer des Jobs Spark et Batch Java (Spring) répondant à des besoins en contribuant à plus d'une trentaine de Dags Airflow maintenus par l'équipe Comptabilité ;

- La réalisation d'une dizaine de Batch Java Spring récupérant des données issues d'une base de données afin d'en générer des fichiers intégrables dans l'interpréteur comptable ;

Malt limite le nombre de caractères...

La banque postale avait souhaité lancer le projet "Vision 360" afin d'avoir un aperçu complet sur l'ensemble de ses clients. L'objectif pour eux a donc été de recruter des data ingénieurs afin de travailler sur l'alimentation d'un DataLake

De manière plus détaillée, j'ai principalement agit sur :

- La mise en place de Workflow NIFI: Apache NIFI est un orchestrateur de tâches qui permet d'automatiser ces dernières avec des séquencements propres aux besoins. Dans mon cas, le besoin était de récupérer des fichiers (textuels), de les valider, de les transformer puis de les ingérer vers un DataLake (ici HDFS) ;

- La mise en place d'un moteur d'ingestion interne: Apache NIFI ayant ses limites sur les volumétries, j'ai initié le développement d'un moteur d'ingestion interne (en Spark), permettant de lire différentes sources de fichiers, de les valider, transformer et charger dans HDFS ;

- L'implémentation de scripts HQL et de jobs Spark de transformation de données stockées sur HDFS et ingérées dans Hive ;

- La résolution d’anomalies de production et data cleaning.

Économie d'énergie est une société permettant aux français de réaliser des travaux d'isolation pour 1€ symbolique (avec l'aide du gouvernement).

Ayant plusieurs clients, et donc plusieurs documents, il s'agissait de parvenir à catégoriser l'ensemble de leurs documents en créant des modèles prédictifs pour cibler de nouveaux clients. Les documents de tout type (formulaires, factures, notices techniques, etc.) étaient transmis sous forme de scans ou images.

Mission :

Ayant 6 machines à disposition, l'objectif était de classer 700,000 documents pesant entre 500Ko à 5Mo.

La mission était séparée en 2 parties: récupération du texte issu des fichiers (data engineering) et classement des fichiers à partir de ce texte (data science).

J'ai travaillé sur la première partie: extraction du texte des documents.

La première étape consistait à créer un programme python qui prenait un fichier en entrée et qui pouvait en extraire le texte: on appelle cela l'OCR (Optical Character Recognition). Le temps de traitement d'un fichier variait de 30 secondes à 5 minutes. Il fallait donc paralléliser cela.

Afin de paralléliser les traitements sur les 6 machines, j'ai mis en place un broker Kafka afin d'envoyer des messages (localisation du fichier) dans le but de pouvoir en extraire le texte. Des conteneurs dockers ont été démarrés sur les 6 machines qui écoutent le topic Kafka afin de traiter les fichiers. Les fichiers textes ont été mis à disposition dans un NFS afin que le Data Scientist puisse les récupérer et continuer sur la seconde partie.