eadl:bloc5:fm3:td3

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Prochaine révision		 Révision précédente
eadl:bloc5:fm3:td3 [2026/11/01 10:50] – créée jcheroneadl:bloc5:fm3:td3 [2026/11/01 17:58] (Version actuelle) – [Projet - Concevoir un pipeline Hadoop résilient et dimensionné] jcheron
Ligne 1: Ligne 1:
 ====== Projet - Concevoir un pipeline Hadoop résilient et dimensionné ====== ====== Projet - Concevoir un pipeline Hadoop résilient et dimensionné ======
- +<WRAP info round> 
-**Module :** Big Data et traitement massif   +  * **Module :** Big Data et traitement massif   
-**Durée :** 6 heures   +  * **Durée :** 6 heures   
-**Organisation :** équipes de 2 personnes   +  * **Organisation :** équipes de 2 personnes   
-**Environnement :** Hadoop sur Docker Compose (cluster fourni, identique à celui du TD2)   +  * **Environnement :** Hadoop sur Docker Compose (cluster fourni, identique à celui du TD1)   
-**Technologies autorisées :** HDFS, YARN, MapReduce Streaming et/ou Hive   +  * **Technologies autorisées :** HDFS, YARN, MapReduce Streaming et/ou Hive   
-**Technologie exclue pour ce projet :** Spark, traité dans l'autre partie du module   +  * **Technologie exclue pour ce projet :** Spark, traité dans l'autre partie du module   
-**AWS :** interdit pour ce projet (aucun risque de facturation) +  * **AWS :** interdit pour ce projet (aucun risque de facturation) 
 +</WRAP>
 ===== 1. Contexte : le lendemain de la grande promotion ===== ===== 1. Contexte : le lendemain de la grande promotion =====
  
-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.+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.+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**.+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**.
  
 ==== Besoin métier ==== ==== Besoin métier ====
  
-Chaque nuit, trois flux sont déposés :+Chaque nuit, **trois flux distincts** sont déposés par trois systèmes sources différents :
  
-  * les commandes ; +  * **les commandes**, issues de la plateforme de vente ; 
-  * les consultations de produits ; +  * **les consultations de produits**, issues du site web (journaux de navigation) ; 
-  * les annulations et retours.+  * **les annulations et retours**, issus du service client.
  
 Le traitement doit produire, pour chaque journée : Le traitement doit produire, pour chaque journée :
  
-  * le chiffre d’affaires net par catégorie ;+  * le chiffre d'affaires net par catégorie (commandes moins annulations et retours) ;
   * le nombre de commandes par catégorie ;   * le nombre de commandes par catégorie ;
   * les cinq produits les plus consultés par catégorie ;   * les cinq produits les plus consultés par catégorie ;
Ligne 34: Ligne 34:
 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. 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.
  
-==== Contraintes communiquées par l’entreprise ====+==== Contraintes communiquées par l'entreprise ====
  
-  * En moyenne, **120 Go de données compressées** arrivent chaque nuit.+  * 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**.   * 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 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 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 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 résultats agrégés doivent rester disponibles pendant **deux ans**.
   * Les identifiants clients ne doivent pas apparaître dans les rapports métier.   * 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 : **le cluster est considéré comme jetable** (créé pour le traitement, détruit ensuite). +  * 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.+  * Une interruption d'un nœud ne doit pas entraîner automatiquement la perte définitive des données ou du résultat.
  
 <WRAP question round> <WRAP question round>
-**À vous d’identifier les ambiguïtés.**+**À vous d'identifier les ambiguïtés.**
  
-Le cahier des charges ne précise pas, par exemple, si les fichiers tardifs modifient les rapports déjà publiés ni quelle règle métier appliquer à une commande annulée après la clôture de la journée. Formulez des hypothèses explicites plutôt que d’ignorer ces questions.+Le cahier des charges ne précise pas, par exemple, si les fichiers tardifs modifient les rapports déjà publiés, ni quelle règle métier appliquer à une commande annulée après la clôture de la journée, ni ce qu'il faut faire si le flux d'annulations n'est pas arrivé à 5 h. Formulez des hypothèses explicites plutôt que d'ignorer ces questions.
 </WRAP> </WRAP>
  
-===== 2. Données et environnement mis à disposition =====+===== 2. Données mises à disposition =====
  
-==== Environnement fourni ====+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/''.
  
-  * un fichier ''docker-compose.yml'' de cluster Hadoop (1 NameNode, 1 ResourceManager, 2 à 3 DataNodes/NodeManagers), identique à celui du TD1 ; +==== Schémas des trois flux ====
-  * un dossier hôte ''persistant/'' monté dans le conteneur client : il **simule le stockage externe durable** (équivalent d'un object storage type S3). Ce qui n'est pas dans ''persistant/'' est considéré comme perdu quand le cluster est détruit ; +
-  * un jeu de données réduit ''marcheplus_lot_J.csv'' (quelques milliers de lignes) et un second fichier ''marcheplus_lot_J_correctif.csv'' simulant l'arrivée tardive ; +
-  * un squelette de scripts (''mapper.py'', ''reducer.py'' et un exemple de requête Hive) qui compte simplement les lignes par catégorie : il sert de point de départ, pas de solution.+
  
-==== Format des données ====+**Flux 1 : ''commandes_AAAAMMJJ.csv''** (une ligne par ligne de commande)
  
-Un seul format de fichier CSV pour les trois flux :+<sxh text> 
 +commande_id,ligne_id,client_id,produit_id,categorie,quantite,prix_unitaire,devise,statut,horodatage_commande 
 +</sxh> 
 + 
 +**Flux 2 : ''consultations_AAAAMMJJ.csv''** (une ligne par page produit vue)
  
 <sxh text> <sxh text>
-date_evenement,commande_id,client_id,produit_id,categorie,type_evenement,montant,horodatage+session_id,client_id,produit_id,categorie,url,horodatage_vue
 </sxh> </sxh>
  
-^ Colonne ^ Description ^ +**Flux 3 : ''annulations_AAAAMMJJ.csv''** (une ligne par annulation ou retour) 
-| date_evenement | Jour métier auquel l'événement est rattaché (AAAA-MM-JJ) | + 
-| commande_id | Identifiant de la commande (vide pour une consultation) | +<sxh text> 
-| client_id | Identifiant client (donnée à ne pas exposer dans les rapports) | +annulation_id,commande_id,ligne_id,type,motif,quantite,montant_rembourse,horodatage_annulation 
-| produit_id / categorie | Produit et sa catégorie | +</sxh> 
-| type_evenement | ''COMMANDE'', ''CONSULTATION'', ''ANNULATION'' ou ''RETOUR'' | + 
-| montant | Montant en euros (vide attendu pour ''CONSULTATION'') ; pour ''ANNULATION'' et ''RETOUR'', montant remboursé, positif | +Remarques sur les schémas : 
-| horodatage | Date et heure réelles d'enregistrement de l'événement |+ 
 +  * ''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.
  
-Un événement est dit **tardif** lorsque son ''horodatage'' est postérieur à la fin de la journée désignée par ''date_evenement'' (ou à la clôture de lot que vous définirez).+==== Anomalies présentes dans le jeu ====
  
 Le jeu contient des cas à détecter ou à traiter : Le jeu contient des cas à détecter ou à traiter :
  
-  * lignes dupliquées ; +  * lignes dupliquées (y compris des doublons exacts et des doublons « presque identiques ») ; 
-  * champs vides (certains attendus, d'autres anormaux : à vous de distinguer) ; +  * champs vides ou mal formés (dates, nombres) ; 
-  * montants invalides (négatifs, non numériques, aberrants) ; +  * montants, prix ou quantités invalides (négatifs, nuls, non numériques) ; 
-  * événements tardifs ; +  * produits dont la catégorie diffère entre deux flux ; 
-  * lignes d'en-tête ; +  * **annulations orphelines** (référence à une ligne de commande inexistante dans le lot) ; 
-  * annulations ou retours associés à une commande, y compris une annulation dont la commande est absente du 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. Vous pouvez compléter le jeu ou fabriquer quelques lignes problématiques si cela vous aide à tester vos choix.
Ligne 95: Ligne 105:
 Avant de coder, décidez et documentez : Avant de coder, décidez et documentez :
  
-  * comment calculer le chiffre d’affaires net ; +  * comment calculer le chiffre d'affaires net (prix, quantité, devise, annulation partielle ou totale, retour) ; 
-  * comment traiter les doublons (qu'est-ce qui identifie un doublon ?) ;+  * 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 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 ;   * 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 ;   * comment départager les produits à égalité dans le top 5 ;
   * quelles données peuvent apparaître dans les sorties.   * 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é.+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é.
  
 ===== 3. Votre mission ===== ===== 3. Votre mission =====
  
-Concevez une solution Hadoop qui répond au besoin de MarchéPlus, puis démontrez-en une version réduite sur l’environnement fourni.+Concevez une solution Hadoop qui répond au besoin de MarchéPlus, puis démontrez-en une version réduite sur l'environnement disponible.
  
-Le travail est organisé en **paliers**. Le palier 1 est obligatoire ; les paliers 2 et 3 sont à traiter dans l'ordre selon le temps disponible. Une équipe qui réussit parfaitement le palier 1 et documente bien ses choix vaut mieux qu'une équipe qui survole les trois.+==== Paliers de réalisation ====
  
-==== Palier 1 (obligatoire) : un pipeline qui marche et dont on peut vérifier le résultat ====+Les paliers sont cumulatifs. **Le palier 1 est obligatoire** ; les suivants se valorisent dans la grille d'évaluation.
  
-=== A. Architecture et parcours des données ===+^ Palier ^ Contenu ^ Statut ^ 
 +| 1 | Nettoyage des flux, **jointure commandes/annulations**, CA net par catégorie, sortie des rejets, un contrôle de cohérence | Obligatoire | 
 +| 2 | Nombre de commandes par catégorie, mécanisme de publication fiable, test d'échec et de relance | Attendu | 
 +| 3 | Top 5 des produits consultés par catégorie, traitement du lot correctif, tests de montée en charge | Extension |
  
-Définissez le chemin des données depuis leur arrivée jusqu’à la publication des résultats. Précisez notamment :+==== A. Architecture et parcours des données ==== 
 + 
 +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 ;   * où se trouvent les données brutes ;
   * quelles données sont stockées dans HDFS et pendant combien de temps ;   * 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 (dans ce projet : le dossier ''persistant/'') ; +  * où se trouvent les résultats qui doivent survivre à la suppression du cluster ; 
-  * quels composants interviennent dans le traitement (rôle de HDFS, de YARN, du moteur de traitement) ;+  * quels composants interviennent dans le traitement ;
   * à quel moment un résultat peut être considéré comme publiable.   * à quel moment un résultat peut être considéré comme publiable.
  
-=== B. Traitement et qualité des données ===+==== B. Stockage et capacité ====
  
-Implémentez au minimum :+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 :
  
-  * une agrégation du chiffre d’affaires net par catégorie ; +  * du volume moyen et du volume de pointe ; 
-  * un traitement des lignes invalides, avec une sortie séparée permettant de les examiner (aucune ligne ne doit disparaître sans trace) ; +  * du **taux de décompression** (les 120 Go sont compressés : posez une hypothèse explicite) ; 
-  * une vérification de la cohérence d’au moins un résultat (par exemple : lignes en entrée = lignes valides + lignes rejetées + doublons écartés ; ou total du CA recalculé par une seconde méthode).+  * 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.
  
-Le traitement peut utiliser **MapReduce Streaming**, **Hive**, ou une combinaison des deux. Expliquez votre choix. **Attendu : le contrôle et le rejet des lignes invalides doivent passer par du MapReduce Streaming, ou le choix contraire doit être explicitement justifié.**+Expliquez pourquoi **une réplication HDFS ne suffit pas à assurer la persistance des données après la destruction du cluster**.
  
-**N’utilisez pas Spark pour cette séance.**+==== C. Traitement et qualité des données ====
  
-==== Palier 2 : résilience, relance et publication ====+Implémentez au minimum (palier 1) :
  
-=== C. Relance et publication des résultats ===+  * 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).
  
-Décrivez **et démontrez** ce qui se passe si :+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 job échoue à mi-parcours ; +Le nettoyage des données est attendu en **MapReduce Streaming**, sauf justification contraire dans le registre des décisions.
-  * le job est relancé avec le même lot ; +
-  * des fichiers de sortie existent déjà ; +
-  * un fichier tardif ou corrigé arrive le lendemain (utilisez le fichier correctif fourni).+
  
-Proposez un mécanisme qui évite qu’un résultat incomplet ou périmé soit présenté comme le résultat officiel. Pistes possibles (non imposées) : séparation sorties temporaires / validées, renommage de répertoire, fichier marqueur de validation, répertoires versionnés par lot. Expliquez votre logique et ses limites.+**N'utilisez pas Spark pour cette séance.**
  
-**Pour rendre l'échec concret**, provoquez-le réellement, par exemple : ''yarn application -kill'' en cours de job, arrêt d'un DataNode (''docker stop''), ou ligne piégée qui fait planter le reducer. Décrivez ce que vous observez (état YARN, fichiers laissés dans HDFS, comportement à la relance).+==== D. Relance et publication des résultats ====
  
-=== D. Persistance indépendante du cluster ===+**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émontrez que vos résultats validés survivent à la destruction du cluster : copie vers ''persistant/'', puis ''docker compose down -v'', recréation du cluster, et restauration ou republication depuis ''persistant/''.+Décrivez ce qui se passe si :
  
-Expliquez pourquoi **une réplication HDFS ne suffit pas à assurer la persistance des données après la destruction du cluster**.+  * 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.
  
-==== Palier 3 : dimensionnement et extensions ====+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.
  
-=== E. Stockage et capacité (scénario réel) ===+**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.
  
-Estimez le volume à stocker **dans l’espace de travail HDFS** (et non dans le stockage externe de 90 jours / 2 ans, que vous traiterez séparément en une ligne), en tenant compte :+==== E. Dimensionnement et montée en charge ====
  
-  * du volume moyen et du volume de pointe ; +Proposez une configuration cible pour le scénario réel, même si vous ne pouvez tester que sur un petit cluster.
-  * du **taux de décompression** que vous supposez (les 120 Go sont compressés : le volume décompressé est bien plus grand, précisez votre hypothèse) ; +
-  * 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.+
  
-=== F. Dimensionnement et montée en charge === +Distinguez les rôles des nœuds et expliquez :
- +
-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 de calcul ;
Ligne 175: Ligne 196:
   * pourquoi ces deux décisions ne sont pas équivalentes ;   * pourquoi ces deux décisions ne sont pas équivalentes ;
   * quels indicateurs vous surveilleriez pour vérifier que le dimensionnement convient ;   * quels indicateurs vous surveilleriez pour vérifier que le dimensionnement convient ;
-  * quelles limites pourraient apparaître lorsque le volume augmente. +  * 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 : débit nécessaire pour traiter 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.+
  
-=== G. Extensions (si le temps le permet) === +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.
- +
-  * top 5 des produits les plus consultés par catégorie, avec règle de départage documentée ; +
-  * nombre de commandes par catégorie ; +
-  * liste d'anomalies enrichie (annulation sans commande, montants aberrants, etc.) ; +
-  * pseudonymisation ou suppression de ''client_id'' avant toute sortie métier.+
  
 ===== 4. Contraintes de réalisation ===== ===== 4. Contraintes de réalisation =====
  
-  * Travaillez avec l’environnement local fourni. +  * Travaillez avec l'environnement local fourni (Docker Compose). 
-  * **N’utilisez pas AWS** pour ce projet.+  * **N'utilisez pas AWS** pour ce projet.
   * Le cluster de démonstration ne doit pas être présenté comme équivalent à une infrastructure de production.   * 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. +  * 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 et les limites de la solution (des questions individuelles seront posées à l'oral).+  * 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. 
 + 
 +===== 5. Usage de l'IA générative ===== 
 + 
 +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.
  
-===== 5. Déroulé indicatif de la séance =====+===== 6. Déroulé indicatif de la séance =====
  
 ^ Durée indicative ^ Travail attendu ^ ^ Durée indicative ^ Travail attendu ^
 | 30 min | Lire le cas, relever les ambiguïtés et formuler les hypothèses | | 30 min | Lire le cas, relever les ambiguïtés et formuler les hypothèses |
-| 30 min | Dessiner l’architecture, répartir les tâches | +| 45 min | Dessiner l'architecture, choisir l'approche pour la jointure et répartir les tâches | 
-| 1 h 45 | Palier 1 : mise en œuvre du traitement et de la qualité des données | +| 2 h 15 | Mettre en œuvre le traitement (palier 1, puis 2) | 
-| 1 h 15 | Palier 2 : échec, relance, publication, persistance externe | +| 1 h | Tester les erreurs, la relance et la cohérence des résultats | 
-| 45 min | Palier 3 : estimation de capacité, scaling, limites | +| 45 min | Estimer la capacité, discuter le scaling et les limites | 
-| 1 h 15 | Rédaction finale du dossier, puis restitution (10 à 15 min par équipe, dont questions individuelles) |+| 30 min | Finaliser le dossier et préparer la restitution | 
 +| 15 min par équipe | Présentation et questions individuelles |
  
-Vous pouvez organiser votre travail autrement, mais réservez du temps pour les tests et la restitution. Les paliers 2 et 3 peuvent être menés en parallèle par des sous-groupes différents.+Vous pouvez organiser votre travail autrement, mais réservez du temps pour les tests et la restitution.
  
-===== 6. Livrable =====+===== 7. Livrable =====
  
 Remettez un dossier court comprenant : Remettez un dossier court comprenant :
  
-  - un schéma d’architecture montrant les données, les stockages et les traitements ;+  - un schéma d'architecture montrant les données, les stockages et les traitements ;
   - un registre des hypothèses et décisions ;   - un registre des hypothèses et décisions ;
   - les scripts, requêtes ou commandes nécessaires pour reproduire le traitement ;   - les scripts, requêtes ou commandes nécessaires pour reproduire le traitement ;
-  - une preuve d’exécution : sortie du job, nombre de lignes traitées et résultat métier obtenu ; +  - une preuve d'exécution : sortie du job, nombre de lignes traitées par flux, lignes rejetées, résultat métier obtenu ; 
-  - un test de reprise ou d’échec, accompagné d’une explication du comportement observé ; +  - la description de la jointure et la vérification de sa justesse (par exemple : nombre d'annulations rattachées et nombre d'orphelines) ; 
-  - la preuve de survie des résultats après recréation du cluster ;+  - un test de reprise ou d'échec, accompagné d'une explication du comportement observé ;
   - une estimation de capacité et de dimensionnement, avec vos hypothèses ;   - une estimation de capacité et de dimensionnement, avec vos hypothèses ;
-  - une synthèse précisant ce qui devrait changer avant un déploiement réel.+  - une synthèse précisant ce qui devrait changer avant un déploiement réel ; 
 +  - la note d'usage de l'IA (une demi-page).
  
 ==== Registre des hypothèses et décisions ==== ==== Registre des hypothèses et décisions ====
Ligne 223: Ligne 251:
 ^ Sujet ^ Hypothèse ou choix ^ Justification ^ Conséquence ou limite ^ ^ Sujet ^ Hypothèse ou choix ^ Justification ^ Conséquence ou limite ^
 | Fichier tardif | | | | | Fichier tardif | | | |
-| Annulation après clôture | | | | +| Doublons et clé d'unicité | | | | 
-| Doublons | | | | +| Annulation orpheline | | | | 
-| Lignes invalides | | | |+| Rattachement d'une annulation à une journée | | | | 
 +| Flux manquant ou incomplet | | | | 
 +| Choix de la jointure | | | |
 | Données conservées dans HDFS | | | | | Données conservées dans HDFS | | | |
-| Données conservées hors cluster | | | | 
 | Relance du job | | | | | Relance du job | | | |
 | Publication du résultat | | | | | Publication du résultat | | | |
-| Taux de décompression | | | | 
 | Dimensionnement | | | | | Dimensionnement | | | |
  
Ligne 241: Ligne 269:
 </WRAP> </WRAP>
  
-===== 7. Critères d’évaluation =====+Chaque membre pourra être interrogé individuellement sur n'importe quelle partie de la solution. 
 + 
 +===== 8. Critères d'évaluation =====
  
 ^ Critère ^ Insuffisant ^ Satisfaisant ^ Excellent ^ ^ Critère ^ Insuffisant ^ Satisfaisant ^ Excellent ^
-| Cohérence de l’architecture | Schéma flou ou composants mal placés | Parcours complet, rôles corrects | Parcours complet, justifié par les contraintes (budget, rétention, cluster jetable) | +| Cohérence de l'architecture | Schéma générique, composants mal reliés | Parcours complet et cohérent avec les contraintes | Choix justifiés par les contraintes, alternatives discutées | 
-| Compréhension de Hadoop | Confusion HDFS / YARN / moteur | Rôles correctement distingués | Rôles distingués et illustrés par des observations sur le cluster | +| Compréhension de Hadoop | Confusion entre rôles HDFS, YARN, moteur de calcul | Rôles correctement distingués | Impact de chaque composant sur la reprise et le scaling expliqué | 
-| Qualité du traitement | Résultat non vérifiable, lignes perdues | CA net correct, rejets tracés, un contrôle de cohérence | Réconciliation complète des lignes, règles toutes documentées et testées | +| Qualité du traitement | Résultats non vérifiables, rejets ignorés | Résultats vérifiés, rejets tracés, jointure correcte | Contrôles de cohérence multiples, orphelins et écarts expliqués | 
-| Gestion de la reprise | Reprise seulement décrite | Échec provoqué, relance sans doublon de résultat | Mécanisme de publication clair, cas du fichier tardif traité, limites identifiées | +| Gestion de la reprise | Relance écrase ou duplique les sorties | Sorties temporaires/validées, relance idempotente | Échec réellement testé, flux manquant et lot correctif gérés | 
-| Dimensionnement | Chiffres sans hypothèses | Calcul de capacité avec hypothèses explicites | Capacité et débit, distinction calcul/stockage argumentée, indicateurs de supervision | +| Dimensionnement | Chiffres sans hypothèses | Calculs de capacité et de débit expliqués | Limites identifiées (NameNode, déséquilibre de jointure, I/O) et marges justifiées | 
-| Prise de recul | Prototype présenté comme production | Limites listées | Limites hiérarchisées, évolutions réalistes avant déploiement | +| Prise de recul | Prototype présenté comme production | Limites du prototype listées | Plan chiffré et priorisé avant déploiement réel | 
-| Défense des choix | Réponses récitées, un seul membre répond | Chacun explique sa partie | Chacun explique l'ensemble et les compromis, y compris les alternatives écartées |+| Maîtrise et usage de l'IA | Code non expliqué, aucune trace | Usage tracé, sorties vérifiées | Erreurs de l'IA identifiées et corrigées, décisions clairement humaines | 
 +| Défense des choix | Un seul membre répond | Chacun explique sa partie | Chacun explique l'ensemble et les compromis |
  
 <WRAP tip round> <WRAP tip round>
-Une solution qui traite le petit fichier le plus rapidement possible n’est pas nécessairement la meilleure. Vous serez aussi évalués sur votre capacité à distinguer **stockage temporaire et persistant**, **calcul et stockage**, **résultat calculé et résultat validé**, et à expliquer les compromis retenus.+Une solution qui traite le petit fichier le plus rapidement possible n'est pas nécessairement la meilleure. Vous serez aussi évalués sur votre capacité à distinguer **stockage temporaire et persistant**, **calcul et stockage**, **résultat calculé et résultat validé**, et à expliquer les compromis retenus.
 </WRAP> </WRAP>
  • eadl/bloc5/fm3/td3.1793526612.txt.gz
  • Dernière modification : il y a 3 jours
  • de jcheron