Le big data apparaît dans toutes les présentations. Une base grossit, des logs s’accumulent, quelqu’un propose Hadoop, puis on cherche le problème. Je préfère partir d’une décision : par exemple, repérer chaque nuit les produits dont la demande monte plus vite que le stock.

Hadoop sépare le stockage distribué et le calcul. HDFS découpe un gros fichier en blocs placés sur plusieurs machines et répliqués. MapReduce envoie le calcul près des blocs, produit des résultats intermédiaires, puis les regroupe. Cette architecture tolère la perte d’un nœud et traite de gros volumes avec du matériel ordinaire, au prix d’une latence qui ne convient pas à chaque requête.

Un exemple de calcul distribué

Pour compter les recherches par produit dans un téraoctet de logs :

1. chaque tâche map lit ses blocs et émet (produit, 1);
2. le système trie et transfère les paires par clé;
3. chaque tâche reduce additionne les valeurs d’un produit;
4. le résultat est écrit dans un jeu de données plus petit;
5. un rapport compare ce compte au stock courant.

Le déplacement intermédiaire, appelé shuffle, peut devenir le coût principal. Compresser, filtrer tôt et agréger localement réduit le réseau. Ajouter des nœuds n’aide pas si toutes les données doivent finalement passer par une seule tâche.

Le format source compte. Un log texte sans schéma peut changer silencieusement : une colonne ajoutée décale le parseur et produit des valeurs nulles. Je conserverais la version du format, l’heure en UTC, l’identifiant de source et une zone de rejets. Le pipeline doit compter lignes lues, acceptées, rejetées et dédupliquées; sinon il peut réussir avec la moitié des données.

La cohérence et la sécurité ne disparaissent pas

HDFS est excellent pour de gros fichiers séquentiels, moins pour des millions de petits fichiers. MapReduce répond en minutes, pas en millisecondes. Une base relationnelle avec un bon index reste meilleure pour une transaction précise. Le choix dépend du volume, de la forme et du délai, pas du prestige du mot.

Les données brutes peuvent contenir comptes, adresses IP et requêtes sensibles. Les copier dans un grand cluster élargit l’accès. Il faut authentifier les nœuds, segmenter le réseau, contrôler les répertoires, chiffrer les transferts et définir une rétention. Un échantillon masqué suffit souvent au développement.

Prouver que le résultat mène à une action

Le compteur de recherches n’a de valeur que s’il modifie une décision de stock. Je choisirais dix produits, calculerais le signal à partir d’une période passée, puis simulerais la règle de réapprovisionnement. Le test compare ruptures évitées, surplus créé et délai du pipeline à une baseline simple comme la moyenne des quatre dernières semaines. Il garde les jours fériés et campagnes à part afin de ne pas attribuer leur effet au modèle. Si le signal arrive après la commande fournisseur ou coûte plus de calcul que la marge sauvée, le traitement distribué est techniquement réussi et opérationnellement inutile.

Enfin, une corrélation n’est pas une décision automatique. Une hausse de recherches peut venir d’une campagne ou d’un produit introuvable. Le résultat doit être comparé à un seuil, revu avec les opérations et suivi après action. Je commencerais avec une semaine de données et une hypothèse falsifiable. Si le calcul ne change aucune décision ou ne peut être rapproché d’un total connu, le cluster ne crée que davantage de données à gouverner.