Projet - Concevoir un pipeline Hadoop résilient et dimensionné

Vous rejoignez l'équipe data de MarchéPlus, une enseigne de commerce en ligne. Après une grande campagne promotionnelle, la direction veut recevoir chaque matin un rapport fiable avant l'ouverture des équipes commerciales.

Aujourd'hui, les données sont traitées par un script exécuté sur une machine unique. Le rapport est parfois en retard, les relances produisent des résultats incohérents et personne ne sait combien de temps les données doivent rester disponibles.

Votre équipe doit proposer et démontrer une solution Hadoop pour ce traitement. Il ne s'agit pas seulement de faire fonctionner un job : vous devez faire des choix d'architecture, les justifier et expliciter leurs limites.

Chaque nuit, trois flux distincts sont déposés par trois systèmes sources différents :

• les commandes, issues de la plateforme de vente ;
• les consultations de produits, issues du site web (journaux de navigation) ;
• les annulations et retours, issus du service client.

Le traitement doit produire, pour chaque journée :

• le chiffre d'affaires net par catégorie (commandes moins annulations et retours) ;
• le nombre de commandes par catégorie ;
• les cinq produits les plus consultés par catégorie ;
• une liste des anomalies de données à examiner.

Les équipes métier veulent consulter les résultats avant 6 h. Une journée de données peut être corrigée ou complétée le lendemain : le pipeline doit donc permettre une reprise ou un recalcul sans publier silencieusement un résultat incohérent.

• En moyenne, 120 Go de données compressées arrivent chaque nuit, tous flux confondus.
• Pendant les promotions, le volume peut atteindre 1,5 fois le volume moyen.
• Les fichiers arrivent entre minuit et 3 h ; le traitement doit se terminer avant 5 h 30, afin de laisser une marge avant la publication.
• Les trois flux n'arrivent pas à la même heure et l'un d'eux peut manquer ou arriver incomplet.
• Les données brutes doivent être conservées 90 jours.
• Les données intermédiaires de calcul ne sont nécessaires que pendant le traitement et les reprises.
• Les résultats agrégés doivent rester disponibles pendant deux ans.
• Les identifiants clients ne doivent pas apparaître dans les rapports métier.
• L'équipe dispose d'un budget limité et ne veut pas laisser un cluster actif en permanence.
• Une interruption d'un nœud ne doit pas entraîner automatiquement la perte définitive des données ou du résultat.

Un jeu de données réduit est fourni, volontairement bien plus petit que les volumes réels. Il se compose de trois fichiers CSV (avec en-tête), plus un lot correctif, dans le dossier donnees/.

Flux 1 : commandes_AAAAMMJJ.csv (une ligne par ligne de commande)

commande_id,ligne_id,client_id,produit_id,categorie,quantite,prix_unitaire,devise,statut,horodatage_commande

Flux 2 : consultations_AAAAMMJJ.csv (une ligne par page produit vue)

session_id,client_id,produit_id,categorie,url,horodatage_vue

Flux 3 : annulations_AAAAMMJJ.csv (une ligne par annulation ou retour)

annulation_id,commande_id,ligne_id,type,motif,quantite,montant_rembourse,horodatage_annulation

Remarques sur les schémas :

• type vaut ANNULATION (avant expédition) ou RETOUR (après livraison) ;
• le flux 3 ne contient pas la catégorie : il faut la retrouver en rattachant l'annulation à la ligne de commande correspondante (jointure) ;
• le flux 2 n'a aucun lien avec les commandes : il alimente uniquement le top 5 ;
• client_id est présent dans les flux 1 et 2 ; il est interdit dans les sorties métier.

Le jeu contient des cas à détecter ou à traiter :

• lignes dupliquées (y compris des doublons exacts et des doublons « presque identiques ») ;
• champs vides ou mal formés (dates, nombres) ;
• montants, prix ou quantités invalides (négatifs, nuls, non numériques) ;
• produits dont la catégorie diffère entre deux flux ;
• annulations orphelines (référence à une ligne de commande inexistante dans le lot) ;
• annulations dont le montant dépasse celui de la ligne de commande ;
• événements dont l'horodatage est postérieur ou antérieur à la journée traitée ;
• lignes d'en-tête répétées au milieu d'un fichier ;
• commandes annulées plusieurs fois ;
• un lot correctif (corrections_AAAAMMJJ.csv, arrivant le lendemain) qui complète ou corrige la journée.

Vous pouvez compléter le jeu ou fabriquer quelques lignes problématiques si cela vous aide à tester vos choix.

Avant de coder, décidez et documentez :

• comment calculer le chiffre d'affaires net (prix, quantité, devise, annulation partielle ou totale, retour) ;
• quelle clé identifie de manière unique une ligne de commande, et comment traiter les doublons ;
• que faire des lignes invalides ou incomplètes ;
• que faire d'une annulation orpheline ;
• à quelle journée rattacher une annulation (celle de la commande ou celle de l'annulation) ;
• comment classer les événements tardifs ;
• que faire si un flux est absent ou incomplet au moment du traitement ;
• comment départager les produits à égalité dans le top 5 ;
• quelles données peuvent apparaître dans les sorties.

Il n'y a pas nécessairement une seule réponse possible. En revanche, une règle non documentée ne pourra pas être considérée comme un choix maîtrisé.

Concevez une solution Hadoop qui répond au besoin de MarchéPlus, puis démontrez-en une version réduite sur l'environnement disponible.

Les paliers sont cumulatifs. Le palier 1 est obligatoire ; les suivants se valorisent dans la grille d'évaluation.

Définissez le chemin des données depuis leur arrivée jusqu'à la publication des résultats.

Précisez notamment :

• où se trouvent les données brutes ;
• quelles données sont stockées dans HDFS et pendant combien de temps ;
• où se trouvent les résultats qui doivent survivre à la suppression du cluster ;
• quels composants interviennent dans le traitement ;
• à quel moment un résultat peut être considéré comme publiable.

Estimez le volume à stocker dans l'espace de travail HDFS (le stockage à 90 jours et à deux ans est traité séparément, voir section D), en tenant compte :

• du volume moyen et du volume de pointe ;
• du taux de décompression (les 120 Go sont compressés : posez une hypothèse explicite) ;
• de la durée de conservation retenue pour les données de travail ;
• du facteur de réplication HDFS ;
• de la marge de capacité que vous souhaitez garder.

Expliquez pourquoi une réplication HDFS ne suffit pas à assurer la persistance des données après la destruction du cluster.

Implémentez au minimum (palier 1) :

• le nettoyage et la validation de chaque flux ;
• la jointure entre les lignes de commande et les annulations/retours, afin de rattacher la catégorie et de calculer le net ;
• une agrégation du chiffre d'affaires net par catégorie ;
• un traitement des lignes invalides, avec une sortie permettant de les examiner ;
• une vérification de la cohérence d'au moins un résultat (par exemple : brut − annulations = net, ou comptage des lignes en entrée = lignes valides + rejetées).

Le traitement peut utiliser MapReduce Streaming, Hive, ou une combinaison des deux. Expliquez pourquoi vous avez retenu cette approche, et comment vous avez réalisé la jointure (par exemple jointure côté reducer en Streaming, ou JOIN Hive) ainsi que son coût (données déplacées entre les nœuds, risque de déséquilibre si quelques clés concentrent beaucoup de lignes).

Le nettoyage des données est attendu en MapReduce Streaming, sauf justification contraire dans le registre des décisions.

N'utilisez pas Spark pour cette séance.

Persistance hors cluster. Le dossier persistant/ de la machine hôte simule le stockage objet durable (type S3). Vous devez démontrer qu'un résultat validé survit à la destruction du cluster (docker compose down -v, recréation, restauration).

Décrivez ce qui se passe si :

• le job échoue à mi-parcours ;
• le job est relancé avec le même lot ;
• des fichiers de sortie existent déjà ;
• un des trois flux est absent, vide ou incomplet ;
• un fichier tardif ou corrigé arrive le lendemain.

Proposez un mécanisme qui évite qu'un résultat incomplet ou périmé soit présenté comme le résultat officiel (par exemple : sorties temporaires et sorties validées, renommage atomique, fichier marqueur de validation, versionnage par lot). Expliquez votre logique.

Test d'échec obligatoire (palier 2). Provoquez au moins une défaillance réelle et documentez le comportement observé : arrêt d'un DataNode, interruption d'un job avec yarn application -kill, fichier d'entrée corrompu ou flux manquant. Vous devez montrer ce qui se passe, pas seulement le décrire.

Proposez une configuration cible pour le scénario réel, même si vous ne pouvez tester que sur un petit cluster.

Distinguez les rôles des nœuds et expliquez :

• dans quel cas vous ajouteriez des nœuds de calcul ;
• dans quel cas vous ajouteriez des nœuds qui stockent les blocs HDFS ;
• pourquoi ces deux décisions ne sont pas équivalentes ;
• quels indicateurs vous surveilleriez pour vérifier que le dimensionnement convient ;
• quelles limites pourraient apparaître lorsque le volume augmente (NameNode, petits fichiers, jointure déséquilibrée, entrées-sorties disque ou réseau).

Faites apparaître au moins un calcul de capacité et un calcul de débit (par exemple : quel débit de traitement faut-il pour absorber le volume de pointe dans la fenêtre disponible ?). Indiquez les hypothèses utilisées et précisez pourquoi une extrapolation à partir du jeu de données réduit reste approximative.

• Travaillez avec l'environnement local fourni (Docker Compose).
• N'utilisez pas AWS pour ce projet.
• Le cluster de démonstration ne doit pas être présenté comme équivalent à une infrastructure de production.
• Ne vous contentez pas d'un schéma théorique : votre pipeline doit produire un résultat vérifiable sur le jeu de données réduit.
• Vous pouvez vous répartir le travail, mais chaque membre de l'équipe doit être capable d'expliquer l'architecture, la jointure et les limites de la solution.

L'usage ponctuel d'un assistant IA est autorisé, comme il le serait dans un contexte professionnel. En revanche :

• vous restez responsables de tout ce que vous livrez : un script produit par une IA que vous ne savez pas expliquer sera considéré comme non maîtrisé ;
• les choix d'architecture et les règles métier doivent être les vôtres : l'IA peut servir à explorer des options ou à débloquer une syntaxe, pas à décider à votre place ;
• vérifiez systématiquement ce qu'elle propose (versions, options Hadoop, comportement réel sur votre cluster) ; une réponse plausible peut être fausse ;
• ne transmettez pas de données sensibles ;
• tracez votre usage : une demi-page indiquant pour quelles tâches vous avez utilisé l'IA, ce que vous avez corrigé ou rejeté, et une erreur ou imprécision que vous avez relevée dans ses réponses.

Les questions individuelles de la restitution orale porteront sur des éléments précis de votre solution.

Vous pouvez organiser votre travail autrement, mais réservez du temps pour les tests et la restitution.

Remettez un dossier court comprenant :

1. un schéma d'architecture montrant les données, les stockages et les traitements ;
2. un registre des hypothèses et décisions ;
3. les scripts, requêtes ou commandes nécessaires pour reproduire le traitement ;
4. une preuve d'exécution : sortie du job, nombre de lignes traitées par flux, lignes rejetées, résultat métier obtenu ;
5. la description de la jointure et la vérification de sa justesse (par exemple : nombre d'annulations rattachées et nombre d'orphelines) ;
6. un test de reprise ou d'échec, accompagné d'une explication du comportement observé ;
7. une estimation de capacité et de dimensionnement, avec vos hypothèses ;
8. une synthèse précisant ce qui devrait changer avant un déploiement réel ;
9. la note d'usage de l'IA (une demi-page).

Votre présentation doit répondre à la question suivante :

Chaque membre pourra être interrogé individuellement sur n'importe quelle partie de la solution.