Un Datalake est un produit complexe qui est le plus souvent construit sur mesure pour chaque besoin métier. Dans le retour d’expérience client que nous présentons ici, la problématique rencontrée était le remplacement d’un Datalake on premise basé sur la solution Cloudera. A l’origine de ce changement, des problèmes récurrents de scalabilité et un stockage arrivé à saturation. Nous verrons dans cet article quels services Cloud ont été choisis pour répondre à ce besoin, et quelle organisation a été retenue pour travailler avec les différents acteurs du projet.

L’organisation du travail dans le contexte d’un projet de Datalake est en effet souvent un facteur de complexité supplémentaire, du fait du nombre d’acteurs impliqués. Dans le cadre de ce projet, il s’agissait d’un travail conjoint entre la DSI historique et l’entité dédiée à l’innovation. Le premier besoin exprimé par le client était de commencer à construire le service dès le premier jour pour atteindre des résultats rapidement.

Pour répondre à ce challenge, une organisation agile a été mise en place avec l’onboarding de la DSI en parallèle du lancement de la phase de build. La cible était de construire un datalake avec Dataiku, sans capacité de calcul distribué pour garder une architecture simple, et de basculer le datalake et les usages actuels sur le Cloud AWS.

Contexte du projet

Après la mise en place d’une première version de la plateforme, la mission de l’équipe Revolve était de prendre le lead technique et d’accompagner l’équipe Datalake, composée d’internes et d’autres prestataires, dans la suite du déploiement. 

Architecture cible

L’architecture cible qui a été choisie est basée sur 3 zones de stockage basées sur autant de buckets S3 : 

• Stockage des données brutes entrantes non modifiées
• Stockage des données nettoyées et transformées
• Stockage des données affinées pour la consommation par les utilisateurs du datalake

Les flux et les traitements entre ces espaces se font par Lambda (python) et Glue.

Cas d’usage

Les données traitées par le datalake sont destinées aussi bien à l’interne (analystes et Data Scientists) que mises à disposition via des applications ou portails à destination des clients ou partenaires. 

Les données manipulées sont personnelles, nominatives et à caractère médical. Leurs traitements soulèvent des enjeux majeurs de sécurité, de conformité et de traçabilité.  Pour répondre aux contraintes RGPD et de la conformité, certaines données à caractère personnelles ont été pseudonymisées : suppression d’informations, réduction de la précision comme le code postal ou la date de naissance, hachage, etc.

L’analyse de ces données permet de répondre à deux grands types de cas d’usage : le customer churn, c’est-à-dire la détection préventive de la perte de clientèle, et la gestion et le pilotage des absences.

Le challenge d’une solution évolutive

Comme nous l’explique Tony Phe : “Nous avons déjà mis en place ce type de pipeline chez d’autres clients, mais d’un projet à l’autre une infrastructure n’est jamais identique. Elle s’adapte au contexte et aux cas d’usage, par ailleurs c’était la première fois que nous traitions des données aussi sensibles que la DSN (Déclaration Sociale Nominative). 

Notre challenge était double : répondre globalement au besoin du client d’exploiter le Cloud pour faire des économies d’échelle, et proposer très rapidement de nouveaux cas d’usage. C’est pour répondre à ces attentes que nous avons choisi d’utiliser AWS Glue, qui pourtant amène certaines contraintes sur des cas d’usage avec une forte intensité de traitements. Dans ce contexte particulier, utiliser Glue nous a permis d’accélérer la mise en place de l’architecture Cloud.  Le challenge de ce projet ne portait pas tant sur les hardskills, que sur la réflexion autour de la mise en place de la solution et de son évolution dans le temps.”

AWS Stepfunctions

Pour le Datapipeline, AWS Stepfunctions a été choisi comme orchestrateur. Stepfunctions permettait de répondre au mieux à la contrainte d’avancer très rapidement malgré la taille réduite de l’équipe en début de projet.

Si ce choix a permis d’accélérer le démarrage du projet, l’équipe étudie actuellement la possibilité d’utilisation d’une solution annexe avec Airflow  : l’idée est d’adapter au mieux l’infrastructure au cycle de vie du projet et aux besoins actuels de l’entreprise.

Comme l’explique Romain Pierlot, l’objectif poursuivi était double : “Il s’agissait d’agréger les briques déjà opérationnelles de la plateforme, et d’avoir un socle stabilisé afin de pouvoir migrer les cas d’usage existants. Nous devions donc remplacer le datalake on premise en migrant ces cas d’usage rapidement, et développer de nouveaux cas d’usage sur la plateforme Cloud. La réussite d’un projet Cloud passant aussi par l’adoption en interne, avoir des cas d’usage “quick win” est essentiel. »

Le second objectif à mener en parallèle concernait un cas d’usage spécifique, sur une application utilisée par les commerciaux sur le terrain. Ce cas d’usage devait être déployé rapidement avec des contraintes de performances élevés qui ont drivé des choix d’architecture ingénieux pour satisfaire les exigences du métier vis à vis des utilisateurs finaux. Nous avons donc construit ce cas d’usage en parallèle du socle du datalake destiné à tous les autres cas d’usage.

Une nouvelle organisation du travail avec le confinement

Le challenge de construire le datalake tout en créant un pipeline à part pour un cas d’usage spécifique a été relevé malgré les contraintes posées par le confinement.

Une nouvelle organisation a été mise en place du jour au lendemain : migration de tous les outils de pilotage et de gestion au quotidien, et remplacement de Jira par Miro, ce qui a permis de faciliter l’accès à distance et de mieux s’organiser sur la répartition des tâches et leur visibilité.

Cette nouvelle organisation a permis de tenir les délais pour livrer la plateforme et les premiers cas d’usage. L’objectif est maintenant de migrer plus de trente cas d’usage, et de continuer à renforcer et stabiliser la plateforme, tout en assurant le run.