Fiche d'étude Hadoop

Un framework open source pour stocker et traiter de très grands volumes de données sur des clusters de machines standard. Ses modules centraux sont HDFS (stockage distribué), YARN (gestion des ressources), MapReduce (un modèle de traitement batch) et Hadoop Common (bibliothèques partagées).

Stocker et traiter des données trop volumineuses pour une seule machine, à moindre coût, en répartissant données et calculs sur de nombreux serveurs bon marché et en tolérant les pannes matérielles de façon logicielle plutôt qu'en achetant du matériel spécialisé et coûteux.

Des articles de Google sur le Google File System (2003) et MapReduce (2004). Doug Cutting et Mike Cafarella ont implémenté ces idées pour le projet de recherche Nutch ; Yahoo! a beaucoup investi, et Hadoop est devenu un projet Apache de premier niveau en 2008.

Déplacer le calcul vers les données (localité), supposer que le matériel tombe en panne et le gérer en logiciel (réplication, relance des tâches), monter en charge horizontalement avec des machines standard, privilégier le débit plutôt que la latence, et stocker les données en écriture unique, lectures multiples.

Planifier les tâches sur les nœuds (ou racks) qui contiennent déjà les blocs qu'elles lisent, pour que les données ne transitent pas par le réseau. C'était crucial quand le réseau était le goulot d'étranglement.

core-site.xml (réglages communs comme le système de fichiers par défaut fs.defaultFS), hdfs-site.xml (réglages HDFS comme la réplication et les répertoires du NameNode), yarn-site.xml (ResourceManager et NodeManager) et mapred-site.xml (réglages MapReduce).

Hadoop 1 combinait la gestion des ressources et MapReduce dans le modèle JobTracker/TaskTracker. Hadoop 2 a introduit YARN, qui sépare la gestion des ressources pour accueillir d'autres moteurs, ainsi que la haute disponibilité du NameNode. Hadoop 3 a ajouté l'erasure coding, plus de deux NameNodes, l'exigence de Java 8+, le timeline service v2 de YARN et d'autres améliorations.

Historiquement Cloudera, Hortonworks (fusionnée avec Cloudera en 2019) et MapR (rachetée par HPE). Aujourd'hui Cloudera Data Platform est la principale distribution commerciale, et les services cloud (Amazon EMR, Google Dataproc, Azure HDInsight) proposent des écosystèmes Hadoop gérés.

L'ensemble des projets construits autour de Hadoop : Hive (SQL), HBase (NoSQL), Pig (scripts), Spark (traitement rapide), Kafka (streaming), ZooKeeper (coordination), Oozie (workflows), Sqoop et Flume (ingestion), Ranger et Atlas (sécurité et gouvernance), Impala et Presto/Trino (SQL interactif), entre autres.

Le stockage objet cloud (S3, ADLS, GCS) sépare stockage et calcul de façon plus économique et élastique, Spark a remplacé MapReduce pour le traitement, et les entrepôts et lakehouses gérés (Snowflake, Databricks, BigQuery) suppriment l'exploitation de clusters. Les clusters Hadoop sont complexes à exploiter et à régler.

Oui, pour maintenir et migrer les clusters existants (fréquents dans les banques, les télécoms et les grandes entreprises), et parce que ses concepts — systèmes de fichiers distribués, blocs, réplication, localité des données, gestionnaires de ressources, partitionnement, shuffle — expliquent le fonctionnement de Spark, de Hive et des lakehouses modernes.

Un cluster de serveurs standard et relativement bon marché avec des disques locaux, par opposition à des machines haut de gamme spécialisées ou à des SAN. Hadoop s'attend à ce que des nœuds tombent en panne et le compense.

Les fichiers sont écrits une fois puis surtout lus ; HDFS accepte l'ajout en fin de fichier mais pas les mises à jour aléatoires au milieu. Cela simplifie la cohérence et favorise l'analytique batch.

Horizontalement : on ajoute des DataNodes pour le stockage et des NodeManagers pour le calcul ; HDFS rééquilibre les données et YARN utilise la nouvelle capacité. La mémoire du NameNode limite le nombre de fichiers, ce que résout la fédération.

Les bibliothèques et utilitaires partagés utilisés par les autres modules Hadoop : abstractions de système de fichiers, RPC, sérialisation, configuration, sécurité et outils en ligne de commande.

Une API Java qui permet aux applications Hadoop de travailler avec différents systèmes de stockage via une interface unique, avec des implémentations pour HDFS (hdfs://), les fichiers locaux (file://), S3 (s3a://), Azure (abfs://), Google Cloud Storage (gs://) et d'autres.

L'ETL batch, le traitement de journaux, l'entreposage de données avec Hive, la préparation de features de machine learning avec Spark, l'indexation pour la recherche et le stockage de données brutes dans un data lake central.

Les données sont stockées en fichiers sans imposer de schéma à l'écriture ; un schéma (par exemple une définition de table Hive) est appliqué à la lecture. L'ingestion devient souple, mais la validation est reportée sur les consommateurs.

Des machines passerelles avec les bibliothèques clientes et la configuration Hadoop mais sans rôle de DataNode ni de NodeManager, d'où les utilisateurs soumettent des jobs, lancent des outils en ligne de commande et hébergent des applications clientes sans toucher aux nœuds de travail.

Il a été conçu pour parcourir de gros volumes en batch, où le temps total de traitement compte plus que le temps de réponse de chaque requête ; HDFS lit de gros blocs séquentiellement et les jobs MapReduce mettent plusieurs secondes à démarrer.

Le Hadoop Distributed File System : un système de fichiers distribué et tolérant aux pannes qui découpe les fichiers en gros blocs et stocke des réplicas de chaque bloc sur des machines différentes, offrant un accès à haut débit à de gros volumes.

Le NameNode (maître qui détient l'espace de noms et l'emplacement des blocs), les DataNodes (travailleurs qui stockent les blocs sur disques locaux) et, en haute disponibilité, un NameNode standby, des JournalNodes et des ZooKeeper Failover Controllers.

L'espace de noms du système de fichiers (répertoires, fichiers, droits, blocs composant chaque fichier) en mémoire, persisté sous forme d'un point de contrôle fsimage et d'un journal edits. L'emplacement des blocs n'est pas persisté ; il provient des block reports des DataNodes.

Il stocke les blocs sous forme de fichiers sur ses disques locaux, sert les requêtes de lecture et d'écriture des clients, envoie des heartbeats et des block reports au NameNode, et réplique des blocs vers d'autres DataNodes sur instruction.

128 Mo dans Hadoop 2 et 3 (64 Mo dans Hadoop 1). De gros blocs réduisent les métadonnées du NameNode, minimisent le temps de positionnement par rapport au temps de transfert et donnent à chaque tâche map une quantité de données significative.

Le nombre de copies de chaque bloc, 3 par défaut (dfs.replication), configurable par fichier. Plus de réplicas signifie plus de durabilité et de parallélisme en lecture, mais plus de stockage.

Le NameNode sait dans quel rack se trouve chaque DataNode (via un script de topologie) et place les réplicas pour survivre à la perte d'un rack : par défaut le premier réplica sur le nœud de l'écrivain, le deuxième sur un nœud d'un autre rack et le troisième sur un autre nœud de ce second rack.

Un assistant qui fusionne périodiquement le journal edits dans le fsimage (checkpointing) pour que le journal ne grossisse pas indéfiniment et que les redémarrages du NameNode soient plus rapides. Malgré son nom, ce n'est pas un standby et il ne peut pas prendre le relais en cas de panne.

Deux NameNodes (ou plus avec Hadoop 3) tournent : un actif, les autres en standby. Ils partagent le journal d'edits via un quorum de JournalNodes ; les DataNodes rendent compte à tous. Les ZooKeeper Failover Controllers surveillent la santé et déclenchent le basculement automatique, avec un fencing pour éviter deux NameNodes actifs (split brain).

Plusieurs NameNodes indépendants, chacun gérant une partie de l'espace de noms (par exemple /user et /data), partageant les mêmes DataNodes. Elle fait monter l'espace de noms en charge au-delà de la mémoire d'un NameNode et isole les charges. ViewFs ou la fédération par routeurs offrent une vue unifiée.

Un NameNode en lecture seule (Hadoop 3) qui sert les lectures avec un état cohérent, déchargeant le NameNode actif dans les clusters à fort trafic de lecture de métadonnées.

Les DataNodes envoient un heartbeat toutes les quelques secondes pour signaler qu'ils sont vivants, et périodiquement un block report complet listant leurs blocs. Si les heartbeats cessent une dizaine de minutes, le NameNode déclare le nœud mort et re-réplique ses blocs.

Un état en lecture seule dans lequel entre le NameNode au démarrage pendant qu'il charge l'espace de noms et attend que les DataNodes déclarent assez de réplicas. Il en sort automatiquement une fois un seuil de blocs atteint, ou un administrateur peut l'en faire sortir.

Toutes les métadonnées résident dans sa mémoire : environ 150 octets par fichier, répertoire et bloc. Des centaines de millions d'objets exigent beaucoup de heap, et chaque opération de métadonnées passe par lui. La fédération, les observer NameNodes et la chasse aux petits fichiers aident.

Une politique de stockage de Hadoop 3 qui stocke les données avec de la parité (par exemple Reed-Solomon 6+3) au lieu de trois copies complètes, offrant une tolérance aux pannes comparable avec 50 % de surcoût de stockage au lieu de 200 %. Les lectures et la reconstruction coûtent plus de CPU et de réseau : on la réserve aux données froides.

fsimage est un point de contrôle de tout l'espace de noms à un instant donné ; edits est le journal de toutes les modifications depuis ce point. Au démarrage, le NameNode charge le fsimage puis rejoue les edits.

Un petit quorum de démons (généralement trois ou cinq) qui stockent le journal d'edits partagé des NameNodes en HA ; le NameNode actif écrit sur une majorité, et les standby lisent depuis eux pour rester synchronisés.

Des mécanismes qui garantissent qu'un ancien NameNode actif ne puisse plus modifier l'espace de noms après un basculement (par exemple tuer son processus ou faire accepter par les JournalNodes les écritures d'une seule époque d'écrivain), pour éviter le split brain.

Il n'utilise que l'espace disque nécessaire ; un fichier de 1 Mo ne consomme pas 128 Mo. Mais il coûte toujours un objet de métadonnées complet dans le NameNode, ce qui est le vrai problème des petits fichiers.

La hiérarchie de répertoires et de fichiers, avec droits, propriétaires, quotas et dates de modification, maintenue par le NameNode, comparable à l'arborescence d'un système de fichiers classique.

Le client demande au NameNode de créer le fichier ; pour chaque bloc, le NameNode renvoie une liste de DataNodes. Le client envoie les données par paquets au premier DataNode, qui les transmet au deuxième, qui les transmet au troisième (un pipeline). Les acquittements remontent, et le fichier devient visible une fois fermé.

Le client demande au NameNode l'emplacement des blocs du fichier, puis lit chaque bloc directement depuis le DataNode le plus proche qui en possède un réplica, en vérifiant les sommes de contrôle ; si un DataNode tombe, il passe à un autre réplica.

Chaque bloc a des sommes de contrôle calculées à l'écriture ; les clients les vérifient à la lecture, et les DataNodes exécutent un scanner de blocs en arrière-plan. Les réplicas corrompus sont signalés au NameNode, qui re-réplique à partir d'une copie saine.

Le NameNode ne reçoit plus ses heartbeats, le déclare mort après un délai et planifie la re-réplication de ses blocs à partir des réplicas restants pour rétablir le facteur de réplication.

Un outil qui déplace des blocs entre DataNodes pour équilibrer l'utilisation des disques dans le cluster, généralement après l'ajout de nœuds. Le disk balancer équilibre l'utilisation entre les disques d'un même DataNode.

L'ajouter au fichier d'exclusion et rafraîchir le NameNode (hdfs dfsadmin -refreshNodes) ; le NameNode re-réplique ses blocs ailleurs et, une fois le retrait terminé, le nœud peut être enlevé sans risque.

hdfs dfs -ls /data/raw
hdfs dfs -mkdir -p /data/raw/orders/dt=2026-10-15
hdfs dfs -put orders.csv /data/raw/orders/dt=2026-10-15/
hdfs dfs -get /data/curated/report.parquet .
hdfs dfs -du -h /data
hdfs dfs -rm -r -skipTrash /tmp/old
hdfs dfs -setrep -w 2 /data/archive

Il vérifie la santé des fichiers et des blocs : blocs manquants, corrompus, sous-répliqués ou mal répliqués, et peut lister l'emplacement des blocs (hdfs fsck /chemin -files -blocks -locations). Il ne lit que les métadonnées et ne corrige rien lui-même.

La capacité du cluster, l'espace utilisé et libre, et l'état de chaque DataNode (vivant, mort, en retrait), utile pour un contrôle de santé rapide.

Quand elle est activée (fs.trash.interval), les fichiers supprimés vont dans un dossier .Trash du répertoire de l'utilisateur et sont définitivement supprimés après l'intervalle, ce qui protège des suppressions accidentelles. -skipTrash la contourne.

Des copies en lecture seule d'un répertoire à un instant donné (activées par répertoire par un administrateur), peu coûteuses car elles n'enregistrent que les changements ; on les utilise pour se remettre d'erreurs utilisateur et pour des sauvegardes cohérentes.

Des quotas de noms (nombre maximal de fichiers et répertoires) et d'espace (octets maximaux, réplicas compris) définis par répertoire, pour éviter qu'une équipe épuise le cluster.

Un outil qui copie de gros volumes de données entre clusters HDFS ou entre HDFS et un stockage objet, en utilisant MapReduce pour copier en parallèle, avec des options de mise à jour incrémentale et de conservation des attributs.

Des règles qui placent les réplicas sur différents types de stockage (DISK, SSD, ARCHIVE, RAM_DISK) selon la « température » : Hot, Warm, Cold, All_SSD, One_SSD et Lazy_Persist. L'outil mover déplace les données existantes pour respecter une politique.

Quand le client tourne sur le même nœud que le DataNode qui détient un bloc, il lit le fichier directement sur le disque local via un descripteur partagé, sans passer par le chemin réseau du DataNode, ce qui accélère les lectures.

Des millions de fichiers bien plus petits que la taille de bloc consomment la mémoire du NameNode (chaque fichier et bloc est un objet), ralentissent les listages et créent de nombreuses tâches minuscules. Solutions : compacter les fichiers (INSERT OVERWRITE Hive, repartition Spark), utiliser des formats conteneurs (SequenceFile, Parquet, ORC), ou archiver en fichiers HAR.

Avec hdfs dfs -setrep -w <n> <chemin>, qui modifie la réplication des fichiers et attend que les réplicas soient ajoutés ou supprimés.

Le nombre de pannes de disque qu'un DataNode tolère avant de s'arrêter ; zéro par défaut, mais les gros nœuds à nombreux disques sont souvent configurés pour continuer avec un ou deux disques en panne.

hdfs dfs -put/-copyFromLocal pour téléverser, hdfs dfs -get/-copyToLocal pour télécharger, et hdfs dfs -getmerge pour concaténer un répertoire de fichiers de parties en un seul fichier local.

Le nombre de répertoires, de fichiers et d'octets sous un chemin, et avec -q les quotas de noms et d'espace, utile pour trouver les répertoires contenant trop de petits fichiers.

Une API REST d'HDFS sur HTTP qui permet à des clients dans n'importe quel langage de lire, écrire et gérer des fichiers sans les bibliothèques Hadoop ; HttpFS en fournit une version passerelle.

Yet Another Resource Negotiator : le gestionnaire de ressources du cluster Hadoop. Il alloue CPU et mémoire sous forme de conteneurs aux applications (MapReduce, Spark, Tez, Flink), en séparant la gestion des ressources du moteur de traitement.

Le ResourceManager (ordonnanceur et gestionnaire d'applications du cluster), les NodeManagers (agents par nœud qui lancent et surveillent les conteneurs), les ApplicationMasters (un par application, qui négocient les ressources et coordonnent les tâches) et les conteneurs (lots alloués de mémoire et de vcores).

Le client la soumet au ResourceManager, qui démarre l'ApplicationMaster dans un conteneur sur un nœud. L'ApplicationMaster demande des conteneurs pour les tâches en tenant compte de la localité des données ; les NodeManagers les lancent ; l'ApplicationMaster suit l'avancement et signale la fin.

L'ordonnanceur FIFO (premier arrivé, premier servi), le Capacity Scheduler (files hiérarchiques avec capacités garanties et élasticité, par défaut dans la plupart des distributions) et le Fair Scheduler (partage équitable des ressources entre applications et files en cours).

Les files sont configurées avec des pourcentages garantis de la capacité du cluster (par exemple etl 50 %, analytics 30 %, adhoc 20 %), peuvent emprunter la capacité inutilisée jusqu'à un maximum, ont des limites par utilisateur et peuvent préempter des conteneurs pour rendre la capacité garantie.

Quand une file est sous sa part garantie et que d'autres en utilisent plus, l'ordonnanceur peut tuer des conteneurs des applications en surconsommation pour libérer des ressources et respecter les garanties.

Avec yarn.nodemanager.resource.memory-mb et .cpu-vcores (ressources offertes par un nœud), yarn.scheduler.minimum-allocation-mb et maximum-allocation-mb (tailles de conteneur autorisées), et les demandes de chaque application (par exemple mapreduce.map.memory.mb ou la mémoire des executors Spark plus l'overhead).

Le NodeManager le tue (« Container killed by YARN for exceeding memory limits ») et la tâche est relancée. On corrige en augmentant la mémoire ou l'overhead du conteneur, ou en réduisant la mémoire par tâche (plus de partitions, moins de cache).

Des étiquettes qui partitionnent les nœuds (par exemple gpu ou high-memory), pour restreindre files et applications à des groupes de nœuds précis.

Un ResourceManager actif et un standby se coordonnent via ZooKeeper ; l'état est conservé dans un state store pour que le standby prenne le relais et que les applications en cours continuent (redémarrage conservant le travail).

Un service qui stocke et sert l'historique des applications et de leurs tâches (heures de début, durées, compteurs) pour la supervision et le débogage après leur fin. Spark a son propre History Server.

yarn application -list -appStates RUNNING
yarn application -status application_1729000000000_0042
yarn logs -applicationId application_1729000000000_0042 | less
yarn application -kill application_1729000000000_0042

En mode client, le driver Spark tourne sur la machine qui a soumis le job (un edge node), utile pour le travail interactif ; en mode cluster, le driver tourne dans le conteneur de l'ApplicationMaster sur le cluster, mieux adapté aux jobs de production qui doivent survivre à la déconnexion du client.

Des cœurs CPU virtuels annoncés par les NodeManagers, une unité abstraite que YARN utilise pour planifier le CPU ; la rigueur de son application dépend du calculateur de ressources et de la configuration des cgroups.

Un calculateur de ressources YARN qui tient compte de la mémoire et du CPU lors de la planification (la ressource dominante de chaque demande), au lieu de celui par défaut qui ne regarde que la mémoire.

Une fonction qui met en cache les ressources des applications (JAR, fichiers) sur les nœuds d'une application à l'autre, réduisant le temps et la bande passante passés à rapatrier encore et encore les mêmes dépendances.

Avec les limites des files de l'ordonnanceur : capacité maximale par file, facteurs de limite par utilisateur, nombre maximal d'applications par utilisateur et par file, et listes de contrôle d'accès sur les files.

Un modèle de programmation et un moteur d'exécution pour le traitement batch : une fonction map transforme les enregistrements d'entrée en paires clé-valeur intermédiaires, le framework regroupe toutes les valeurs par clé (shuffle et tri), et une fonction reduce agrège les valeurs de chaque clé en résultats.

Le mapper lit les lignes et émet (mot, 1) pour chaque mot. Le shuffle regroupe les paires par mot. Le reducer reçoit (mot, [1, 1, 1, …]) et émet (mot, somme). Un combiner peut additionner localement après le map pour réduire les données du shuffle.

Un morceau logique de l'entrée attribué à une tâche map, correspondant généralement à un bloc HDFS. Le nombre de splits détermine le nombre de tâches map.

Le composant qui lit un InputSplit et le transforme en enregistrements clé-valeur pour le mapper ; par exemple LineRecordReader donne (décalage en octets, ligne).

Les sorties des maps sont partitionnées par clé, triées et déversées sur disque local ; les reducers récupèrent leurs partitions auprès de tous les mappers via le réseau, les fusionnent en ordre et fournissent les clés regroupées à la fonction reduce. C'est généralement la phase la plus coûteuse.

Un « mini-reducer » optionnel exécuté sur la sortie du map avant le shuffle pour pré-agréger les valeurs par clé et réduire les transferts réseau. Il doit pouvoir s'appliquer zéro, une ou plusieurs fois sans changer le résultat (opérations associatives et commutatives comme la somme ou le max).

La fonction qui décide quel reducer reçoit chaque clé, par défaut hash(clé) % nbReducers. Des partitioners personnalisés contrôlent la distribution, par exemple pour éviter le déséquilibre ou regrouper des clés liées.

Assez pour paralléliser le travail de reduce en gardant une entrée raisonnable par reducer, typiquement autour de 0,95 ou 1,75 fois les slots de reduce ou selon la taille de la sortie ; zéro reducer donne un job map seul.

Quand certaines tâches sont bien plus lentes que les autres (retardataires), le framework lance des tentatives en double sur d'autres nœuds et garde celle qui finit la première. Elle aide face à du matériel lent mais gaspille des ressources, et doit être désactivée en cas d'effets de bord non idempotents.

Des nombres nommés que les tâches incrémentent (intégrés, comme les enregistrements lus, octets écrits ou enregistrements déversés, et personnalisés, comme « lignes invalides »), agrégés sur tout le job pour la supervision et la validation.

Un mécanisme pour envoyer des fichiers en lecture seule (tables de correspondance, JAR, configuration) à chaque nœud qui exécute des tâches d'un job, afin que les tâches les lisent localement.

Une jointure côté reduce étiquette les enregistrements des deux jeux, les émet par clé de jointure et joint dans le reducer (générale, mais tout passe par le shuffle). Une jointure côté map charge le petit jeu en mémoire via le distributed cache et joint dans le mapper (rapide, mais un côté doit tenir en mémoire).

MapReduce écrit les résultats intermédiaires sur disque entre chaque étape et exprime les pipelines complexes comme des chaînes de jobs, ce qui est lent et verbeux. Spark garde les données en mémoire entre les étapes, optimise des DAG entiers et propose des API de haut niveau (SQL, DataFrames) dans plusieurs langages.

Un utilitaire qui permet d'écrire mappers et reducers dans n'importe quel langage lisant stdin et écrivant stdout (Python, bash), Hadoop gérant la distribution ; il était populaire avant PySpark.

Aux transformations qui n'ont pas besoin de regroupement, comme le filtrage, la conversion de format ou l'analyse de journaux, avec zéro reducer pour que la sortie du mapper soit écrite directement.

Une sous-classe de Mapper avec une méthode map(), une sous-classe de Reducer avec reduce(), et un driver qui configure le Job (formats et chemins d'entrée et de sortie, types de clés et de valeurs, nombre de reducers) et le soumet.

InputFormat définit comment l'entrée est découpée et lue (TextInputFormat, SequenceFileInputFormat, KeyValueTextInputFormat, CombineFileInputFormat pour de nombreux petits fichiers) ; OutputFormat définit comment les résultats sont écrits (TextOutputFormat, SequenceFileOutputFormat).

À regrouper de nombreux petits fichiers dans moins de splits, pour qu'un job sur des milliers de petits fichiers ne lance pas des milliers de minuscules tâches map.

Il rend la sortie d'un job atomique : les tâches écrivent dans des répertoires temporaires et le committer déplace les résultats vers l'emplacement final quand le job réussit, pour que les tentatives en échec ou spéculatives ne laissent pas de sorties partielles.

Une technique pour que les valeurs arrivent au reducer triées selon un champ secondaire, à l'aide d'une clé composite, d'un partitioner personnalisé sur la clé naturelle et d'un comparateur de regroupement.

Démarrer une tâche a un coût (lancement de la JVM, planification) ; des tâches très courtes passent plus de temps à démarrer qu'à traiter. Des splits plus gros ou des petits fichiers regroupés rendent les tâches efficaces.

Le texte (CSV, JSON), SequenceFile (clé-valeur binaire), Avro (par lignes avec schéma intégré, bon pour l'ingestion et l'évolution de schéma), Parquet et ORC (en colonnes, compressés, avec statistiques, les meilleurs pour l'analytique).

Un format que différentes tâches peuvent lire par morceaux indépendants. Le texte brut, SequenceFile, Avro, Parquet et ORC sont découpables ; un fichier texte compressé en gzip ne l'est pas, donc une seule tâche doit le lire en entier, ce qui limite le parallélisme.

Snappy et LZ4 (rapides, compression modérée), gzip/Deflate (meilleure compression, plus lents, non découpables pour le texte), bzip2 (découpable, lent), LZO (découpable avec un index) et ZSTD (bon taux et bonne vitesse). Dans Parquet et ORC, la compression se fait par bloc : les fichiers restent découpables.

ORC (Optimized Row Columnar) a été créé pour Hive : stockage en colonnes avec index légers, statistiques et filtres de Bloom, et prise en charge des tables ACID de Hive. Parquet est plus répandu dans les autres moteurs.

Le schéma est stocké avec les données et prend en charge l'évolution (ajout de champs avec valeur par défaut, renommage via des alias), et son format compact par lignes convient au streaming et à l'ingestion, souvent avec un schema registry dans Kafka.

Un fichier binaire plat de paires clé-valeur, découpable et compressible, utilisé comme sortie intermédiaire de MapReduce et pour regrouper de nombreux petits fichiers dans un conteneur.

Les Hadoop Archives : un moyen de regrouper de nombreux petits fichiers dans une archive unique (un index plus des fichiers de parties) pour réduire les objets du NameNode tout en gardant les fichiers accessibles via un chemin har://.

Les fichiers contiennent des groupes de lignes ; chaque groupe stocke des tronçons de colonnes, découpés en pages encodées et compressées ; le pied de fichier contient le schéma et les statistiques (min/max, nombre de nulls) par groupe et colonne, ce qui permet l'élagage de colonnes et la poussée des prédicats.

Les fichiers sont découpés en stripes (typiquement 64 à 256 Mo) contenant des flux par colonne, des index légers toutes les 10 000 lignes (min/max), des filtres de Bloom optionnels et un pied avec les statistiques par stripe, ce qui permet aux moteurs de sauter stripes et groupes de lignes.

Généralement oui, avec un codec rapide comme Snappy ou LZ4 (mapreduce.map.output.compress), car cela réduit les E/S disque et réseau pendant le shuffle pour un faible coût CPU.

Avro pour les écritures par lignes, le streaming et les messages dont on lit les enregistrements complets et dont le schéma évolue souvent ; Parquet pour l'analytique où les requêtes lisent quelques colonnes de nombreuses lignes.

Un système d'entrepôt de données sur Hadoop qui permet d'interroger des données dans HDFS (et dans un stockage objet) avec un dialecte SQL (HiveQL). Les requêtes sont compilées en jobs MapReduce, Tez ou Spark, et les métadonnées des tables sont stockées dans le Hive Metastore.

Un service adossé à une base relationnelle (MySQL, PostgreSQL) qui stocke les définitions de tables, colonnes, partitions, emplacements et formats. Hive, Spark, Impala, Presto/Trino et d'autres l'utilisent, et l'AWS Glue Data Catalog lui est compatible.

Hive possède les données des tables gérées : supprimer la table supprime les fichiers. Les tables externes pointent vers des données gérées ailleurs : les supprimer n'efface que les métadonnées. Les tables externes sont courantes dans les data lakes partagés.

Des sous-répertoires par valeur de colonne (/sales/dt=2026-10-15/) ; les requêtes qui filtrent sur les colonnes de partition ne lisent que les répertoires correspondants. Le partitionnement dynamique crée les partitions à partir des résultats d'une requête.

La répartition des données d'une table ou d'une partition dans un nombre fixe de fichiers selon le hachage d'une colonne, ce qui permet un échantillonnage efficace et des bucket map joins quand les tables sont « bucketées » sur la clé de jointure.

MapReduce (historique, déprécié), Apache Tez (basé sur des DAG, défaut habituel de Hive 2/3) et Spark (Hive on Spark). Hive LLAP ajoute des démons persistants avec cache pour les requêtes interactives.

Des tables ORC transactionnelles (les tables gérées de Hive 3) qui prennent en charge INSERT, UPDATE, DELETE et MERGE avec isolation par snapshot, grâce à des fichiers delta fusionnés par des compactions (mineures et majeures).

Une optimisation fondée sur Apache Calcite qui utilise les statistiques de tables et de colonnes (ANALYZE TABLE … COMPUTE STATISTICS) pour choisir l'ordre et la stratégie des jointures ; sans statistiques, les plans peuvent être médiocres.

Une jointure où la petite table est chargée en mémoire sur chaque mapper (broadcast), évitant le shuffle ; Hive convertit automatiquement les jointures quand la petite table est sous un seuil de taille (hive.auto.convert.join).

LOAD DATA INPATH (déplace les fichiers dans l'emplacement de la table), INSERT INTO/OVERWRITE … SELECT, CREATE TABLE AS SELECT, ou en écrivant directement des fichiers à l'emplacement d'une table externe puis en ajoutant les partitions.

Une commande qui parcourt l'emplacement de la table à la recherche de répertoires de partition non enregistrés dans le metastore et les ajoute.

Des sérialiseurs/désérialiseurs qui définissent comment les lignes sont lues et écrites : LazySimpleSerDe pour le texte délimité, OpenCSVSerde, des SerDe JSON, RegexSerDe, et la prise en charge intégrée d'ORC, Parquet et Avro.

HiveQL est presque du SQL, mais avec des fonctions propres à Hadoop (partitions, buckets, LATERAL VIEW explode, SerDe, INSERT OVERWRITE DIRECTORY), des transactions et sous-requêtes historiquement limitées, et une sémantique de schéma à la lecture.

Le service qui accepte les connexions clientes (JDBC/ODBC, Beeline) et exécute les requêtes HiveQL avec authentification, concurrence et sécurité, remplaçant l'ancienne CLI Hive pour l'accès multi-utilisateurs.

Le client JDBC en ligne de commande pour HiveServer2, utilisé pour lancer requêtes et scripts sur Hive avec la bonne authentification.

Une construction Hive qui transforme des colonnes de type tableau ou map en plusieurs lignes, comparable à UNNEST dans d'autres dialectes SQL.

SELECT o.order_id, item
FROM orders o
LATERAL VIEW explode(o.items) t AS item;

ORDER BY produit un ordre total via un seul reducer ; SORT BY trie au sein de chaque reducer ; DISTRIBUTE BY contrôle quel reducer reçoit chaque clé ; CLUSTER BY combine DISTRIBUTE BY et SORT BY sur les mêmes colonnes.

Le traitement de lots de lignes (généralement 1 024) à la fois avec des opérations en colonnes plutôt que ligne par ligne, ce qui accélère les lectures, filtres et agrégations sur des données ORC.

ANALYZE TABLE t PARTITION (dt) COMPUTE STATISTICS pour les statistiques de table et de partition, et … FOR COLUMNS pour celles des colonnes, utilisées par l'optimiseur basé sur les coûts ; hive.stats.autogather collecte les statistiques de base à l'insertion.

INSERT OVERWRITE TABLE t PARTITION (dt) SELECT …, dt FROM src crée les partitions à partir des valeurs des données. Des limites (hive.exec.max.dynamic.partitions) évitent de créer des milliers de partitions par accident, et de nombreuses partitions avec peu de lignes produisent de petits fichiers.

Une base NoSQL distribuée orientée familles de colonnes, inspirée de Google Bigtable, qui tourne sur HDFS. Elle offre des lectures et écritures aléatoires en temps réel sur des milliards de lignes par clé de ligne, avec une cohérence forte par ligne.

Des tables de lignes triées par clé ; chaque ligne a des familles de colonnes (définies à la création de la table), chaque famille contient un nombre quelconque de colonnes (qualifiers), et chaque cellule conserve des versions identifiées par horodatage. Les colonnes clairsemées ne coûtent rien.

Le HMaster (attribue les régions, gère les changements de schéma et l'équilibrage), les RegionServers (servent lectures et écritures des régions), les régions (plages contiguës de clés d'une table) et ZooKeeper (coordination et localisation de la table meta).

Le RegionServer ajoute la modification au write-ahead log (WAL) dans HDFS pour la durabilité, puis l'écrit dans la MemStore en mémoire. Quand la MemStore est pleine, elle est vidée dans un HFile immuable sur HDFS.

Des processus d'arrière-plan qui fusionnent les HFiles : les compactions mineures fusionnent quelques petits fichiers ; les majeures réécrivent tous les fichiers d'un store en un seul en supprimant les cellules effacées et expirées. Les compactions majeures sont lourdes en E/S et souvent planifiées hors pointe.

Tout accès se fait par clé, et les lignes sont triées et découpées en régions par clé. Des clés croissantes (horodatages, séquences) envoient toutes les écritures vers une seule région (hotspotting). Utilisez le salage, le hachage ou l'inversion de champs, et concevez les clés selon les principaux modes d'accès.

HBase pour des lectures et écritures aléatoires à faible latence par clé (profils utilisateurs, recherches de séries temporelles, compteurs) ; Hive pour l'analytique SQL batch sur de grosses lectures.

Une couche SQL au-dessus de HBase qui compile le SQL en scans HBase, avec des index secondaires et un accès JDBC.

Quand une région dépasse une taille configurée, le RegionServer la découpe en deux régions sur une clé médiane, et le HMaster peut les déplacer pour équilibrer la charge. Pré-découper les tables évite les points chauds initiaux.

Un groupe de colonnes stockées ensemble dans les mêmes fichiers avec des réglages communs (compression, versions, TTL). Chaque famille a sa propre MemStore et ses fichiers : de nombreuses familles multiplient les vidages et compactions ; deux ou trois est typique.

Utiliser Get pour des lignes isolées par clé et Scan avec des clés de début et de fin pour les plages, ajouter des filtres pour réduire les données renvoyées, régler caching et batching des scans, et éviter les scans complets sur les chemins sensibles à la latence.

Une structure par fichier de store qui indique si une ligne (ou ligne et colonne) pourrait exister dans le fichier, ce qui permet aux lectures de sauter les fichiers qui ne la contiennent certainement pas et réduit les lectures disque des gets aléatoires.

Une durée de vie définie par famille de colonnes ; les cellules plus anciennes que le TTL sont supprimées lors des compactions, utile pour les séries temporelles et les caches.

Un service de coordination centralisé offrant un stockage clé-valeur hiérarchique (znodes), des watches et du consensus (protocole ZAB). Les composants Hadoop l'utilisent pour l'élection de leader (HA du NameNode et du ResourceManager), la configuration et la découverte de services ; les anciennes versions de Kafka l'utilisaient aussi.

Un langage de flux de données de haut niveau (Pig Latin) qui compilait des scripts en jobs MapReduce ou Tez, populaire pour l'ETL avant la maturité de Spark et Hive ; il est rarement utilisé pour de nouveaux travaux.

Un outil de transfert de données entre bases relationnelles et Hadoop (import vers HDFS/Hive, export retour) par des tâches MapReduce parallèles. Il a été retiré dans l'Apache Attic en 2021 ; Spark JDBC, des outils de type DMS et des outils de CDC l'ont remplacé.

Un service pour collecter, agréger et déplacer de gros volumes de journaux depuis de nombreuses sources vers HDFS ou HBase, avec des sources, des canaux et des sinks. Kafka l'a largement remplacé.

Un ordonnanceur de workflows pour les jobs Hadoop (MapReduce, Hive, Pig, Sqoop, shell) définis en XML, avec des coordinateurs pour les déclenchements temporels et par données. La plupart des équipes sont passées à Airflow ou à d'autres orchestrateurs.

Des moteurs SQL MPP qui interrogent directement les données de HDFS et du stockage objet avec des démons persistants, offrant une latence interactive par rapport à Hive sur MapReduce. Trino (anciennement PrestoSQL) est très utilisé et sous-tend Amazon Athena.

Spark tourne sur YARN (driver en mode client ou cluster, executors dans des conteneurs YARN), lit et écrit HDFS, utilise le Hive Metastore pour les tables et profite de la localité des données.

Un journal de messages durable et scalable qui ingère des flux (événements, CDC) et découple producteurs et consommateurs ; les données sont ensuite écrites dans HDFS ou un stockage objet par Kafka Connect, Spark Streaming ou Flink.

Un framework d'exécution en DAG sur YARN qui exécute les jobs Hive et Pig comme un seul graphe de tâches, évitant les écritures disque par étape et les coûts de démarrage de MapReduce.

Un outil web pour provisionner, gérer et superviser les clusters Hadoop (installation des services, configuration, alertes), surtout utilisé avec les distributions Hortonworks ; Cloudera Manager joue le même rôle chez Cloudera.

Un service REST pour soumettre des jobs et des sessions interactives Spark à un cluster, utilisé par les notebooks et les applications qui ne peuvent pas exécuter eux-mêmes un driver Spark.

Un stockage objet distribué et scalable pour Hadoop avec une API compatible S3, conçu pour dépasser les limites d'HDFS sur les petits fichiers et l'espace de noms tout en restant compatible avec les applications Hadoop.

Avec Kerberos : utilisateurs et services obtiennent des tickets auprès d'un Key Distribution Center, que les services Hadoop vérifient. Sans Kerberos (mode « simple »), Hadoop fait confiance au nom d'utilisateur déclaré par le client, ce qui n'est pas sûr.

Des jetons émis par les services (NameNode, ResourceManager) après une authentification Kerberos, transmis aux tâches exécutées sur le cluster pour qu'elles accèdent à HDFS sans disposer elles-mêmes d'identifiants Kerberos.

Avec des droits de type POSIX propriétaire/groupe/autres sur fichiers et répertoires, plus des ACL pour un contrôle plus fin. Les politiques fines et centralisées sont généralement gérées avec Apache Ranger.

Un framework de sécurité centralisé pour Hadoop qui définit et audite des politiques d'accès (chemins HDFS, bases, tables et colonnes Hive, filtres de lignes et masquage, HBase, Kafka) avec des plugins qui les appliquent dans chaque service.

Un service de métadonnées et de gouvernance qui fournit catalogue de données, lignage, classification (tags comme PII) et intégration avec Ranger pour des politiques fondées sur les tags.

Une passerelle qui offre un point d'entrée unique et sécurisé (API REST, interfaces) aux services Hadoop pour les utilisateurs hors du cluster, en gérant l'authentification et le SSL.

En transit avec le chiffrement RPC, TLS pour les interfaces web et le chiffrement du transfert de données ; au repos avec le chiffrement transparent HDFS par zones de chiffrement dont les clés sont gérées par le Hadoop Key Management Server (KMS).

Un fichier contenant les clés d'un principal Kerberos, utilisé par les services et les jobs batch pour s'authentifier sans mot de passe ; les keytabs doivent être protégés comme des mots de passe.

Une configuration qui permet à un service de confiance (HiveServer2, Livy, Oozie) d'agir au nom des utilisateurs finaux, pour que les droits et les audits reflètent l'utilisateur réel et non le compte de service.

Les journaux d'audit HDFS du NameNode enregistrent chaque accès aux fichiers ; Ranger collecte les événements d'audit de tous ses plugins dans Solr ou HDFS, et Atlas enregistre le lignage.

À partir du volume de données (taille brute × facteur de réplication × croissance, plus l'espace temporaire), des besoins de traitement (CPU et mémoire pour les jobs simultanés) et des objectifs de débit ; en gardant de la marge pour les pannes et le rééquilibrage (on garde souvent les disques sous 70 à 80 %).

Le déséquilibre des données (quelques reducers avec la plupart des clés), trop de petits fichiers, un parallélisme insuffisant ou excessif, des déversements sur disque dus à des tampons mémoire trop petits, des entrées compressées non découpables, l'absence de localité et la contention dans les files YARN.

Fixer mapreduce.map.memory.mb et mapreduce.reduce.memory.mb pour la taille des conteneurs et -Xmx dans mapreduce.map.java.opts à environ 80 % du conteneur, et ajuster mapreduce.task.io.sort.mb pour réduire les déversements.

Avec des combiners, des partitioners personnalisés, le salage des clés chaudes, des jointures côté map pour les petites tables, les optimisations de skew join de Hive (hive.optimize.skewjoin) ou une pré-agrégation.

Avec les interfaces web du NameNode et du ResourceManager, les métriques JMX, Cloudera Manager (ou historiquement Ambari), des exporteurs Prometheus et Grafana, et des alertes sur la capacité HDFS, les nœuds morts ou lents, les blocs sous-répliqués, le heap du NameNode, la latence RPC et l'usage des files.

Planifier avec les notes de version et des vérifications de compatibilité, sauvegarder les métadonnées du NameNode, utiliser les mises à jour progressives (rolling) quand c'est possible (NameNodes en HA, DataNodes un par un), tester les jobs sur un cluster de préproduction et garder la possibilité de revenir en arrière jusqu'à la finalisation.

Avec des snapshots pour les erreurs utilisateur, distcp vers un autre cluster ou un stockage objet pour la reprise après sinistre, et des sauvegardes des métadonnées du NameNode (fsimage et edits). La réplication interne au cluster n'est pas une sauvegarde.

De longues pauses de GC sur le NameNode ou les RegionServers les rendent muets, provoquant timeouts, basculements ou heartbeats manqués. Dimensionnez soigneusement les heaps, utilisez des collecteurs modernes (G1) et surveillez les journaux de GC.

L'interface et les API du ResourceManager YARN (mémoire-secondes et vcore-secondes par application), les métriques des files, les history servers Spark et MapReduce, et les rapports d'usage des outils de gestion.

Repérer les répertoires volumineux et anciens (hdfs dfs -du -h), vider la corbeille, supprimer les données temporaires obsolètes et les vieux snapshots, réduire la réplication des données froides ou appliquer l'erasure coding, compresser ou convertir en formats en colonnes, et ajouter de la capacité si nécessaire.

Il fixe la fraction de maps qui doivent être terminés avant que les reducers commencent à récupérer les sorties ; démarrer les reducers trop tôt gaspille des slots en attente, trop tard retarde le shuffle.

HDFS couple stockage et calcul sur les mêmes nœuds, offre la localité des données et une cohérence forte, et exige de gérer un cluster. S3 est un stockage objet géré, scalable indépendamment, moins cher et très durable, accessible par le réseau ; il est aujourd'hui lui aussi fortement cohérent. La plupart des data lakes cloud utilisent le stockage objet plutôt que HDFS.

Le connecteur de système de fichiers Hadoop (s3a://) qui permet à Hadoop, Hive et Spark de lire et écrire S3 comme un système de fichiers, avec des optimisations pour les envois multipart, des committers qui évitent les renommages lents et des fournisseurs d'identifiants.

Les stockages objet n'ont pas de vrais répertoires ; un « renommage » est une copie suivie d'une suppression de chaque objet, ce qui est lent et non atomique. Les committers de sortie Hadoop qui reposent sur des renommages sont lents ou dangereux sur S3 ; on utilise les committers S3A (magic, staging) ou des formats de table (Iceberg, Delta).

Une plateforme big data gérée sur AWS qui exécute Hadoop, Spark, Hive, HBase, Presto/Trino, Flink et d'autres sur EC2, EKS ou en serverless, avec S3 (EMRFS/S3A) comme stockage principal et le Glue Data Catalog comme metastore, en clusters éphémères ou persistants.

Un cluster créé pour un job ou un pipeline puis arrêté, les données étant conservées dans un stockage objet. On évite de payer des clusters inactifs et les environnements deviennent reproductibles.

Inventorier données, jobs et dépendances ; copier les données vers le stockage objet avec distcp ou des services de transfert ; convertir les tables en formats ouverts (Parquet, puis Iceberg ou Delta) ; passer le metastore à un catalogue géré (Glue, Unity Catalog) ; porter les jobs Hive et MapReduce vers Spark ou des moteurs SQL ; remplacer Oozie par Airflow ; recréer la sécurité avec l'IAM cloud et les droits du catalogue ; et valider les résultats en parallèle avant de décommissionner.

HDFS → stockage objet (S3, ADLS, GCS) ; YARN → Kubernetes ou calcul serverless géré ; MapReduce → Spark, Flink, moteurs SQL ; Hive Metastore → Glue, Unity Catalog, Polaris et d'autres catalogues ; tables Hive → Iceberg, Delta, Hudi ; Oozie → Airflow, Dagster ; Ranger/Atlas → gouvernance native du cloud (Lake Formation, Unity Catalog).

Iceberg, Delta Lake et Hudi ajoutent une couche de métadonnées transactionnelle au-dessus de fichiers Parquet, résolvant les problèmes des tables Hive (pas d'ACID sur stockage objet, listage lent des partitions, écritures concurrentes risquées, évolution de schéma pénible). Ce sont les successeurs modernes des tables de style Hive.

L'implémentation par Amazon EMR du système de fichiers Hadoop pour S3, avec des fonctions comme la vue cohérente (historiquement), le chiffrement et le mappage de rôles IAM ; les versions récentes d'EMR prennent aussi en charge S3A.

En partie : Spark et Flink tournent nativement sur Kubernetes, le Hive Metastore et Trino tournent comme services, et le stockage passe sur des stockages objet. Faire tourner HDFS et YARN sur Kubernetes est possible mais en vaut rarement la complexité.

Des services Hadoop et Spark gérés sur Google Cloud et Azure, comparables à EMR, qui créent des clusters en quelques minutes avec un stockage objet (GCS, ADLS) comme stockage principal. Azure oriente de plus en plus les nouveaux projets vers Fabric et Databricks.

Les clusters on-premise ont des coûts fixes élevés (matériel, centres de données, équipes) et sont dimensionnés pour les pics ; les lakes cloud ont un stockage et un calcul payés à l'usage qui peuvent descendre à zéro, mais exigent une gouvernance des coûts pour éviter les dérives.

Via l'API FileSystem de Hadoop et les input formats : chaque bloc HDFS (ou plage de groupes de lignes Parquet) devient une partition, et YARN planifie les executors avec des préférences de localité proches des blocs.

Avec enableHiveSupport() (ou la configuration du catalogue), Spark lit dans le metastore les définitions de tables, partitions et emplacements : spark.table("db.table") et Spark SQL fonctionnent sur des tables Hive, et Spark peut créer des tables visibles par Hive.

spark-submit \
  --master yarn --deploy-mode cluster \
  --queue etl \
  --num-executors 20 --executor-cores 4 --executor-memory 8g \
  --conf spark.executor.memoryOverhead=1g \
  --conf spark.sql.shuffle.partitions=400 \
  jobs/curate_orders.py --date 2026-10-15

Une fonction où Spark demande et libère des executors selon les tâches en attente, pour que les executors inactifs rendent leurs ressources à YARN ; elle nécessite le service de shuffle externe (ou le suivi du shuffle) pour que les fichiers de shuffle survivent à la suppression des executors.

Un service exécuté dans chaque NodeManager qui sert les fichiers de shuffle écrits par les executors, pour que ceux-ci puissent être supprimés (allocation dynamique) ou tomber en panne sans perdre leur sortie de shuffle.

Équilibrer cœurs et mémoire : environ 4 à 5 cœurs par executor pour un bon débit HDFS, une mémoire par cœur adaptée à la charge, de l'overhead pour les besoins hors heap, et des ressources laissées au NodeManager et au système sur chaque nœud.

À court terme, j'augmente le heap et je redémarre pendant une fenêtre de maintenance (avec la HA, je bascule). À long terme, je réduis le nombre d'objets : trouver et compacter les petits fichiers, supprimer les données inutilisées et les vieux snapshots, utiliser des fichiers HAR, et envisager la fédération ou des observer NameNodes.

Le filtre ne porte pas sur la colonne de partition, l'enveloppe dans une fonction, la compare à un autre type, ou les partitions ne sont pas enregistrées et la requête retombe sur l'emplacement de la table. Je vérifie le plan avec EXPLAIN et je corrige filtres ou partitions.

Augmenter spark.executor.memoryOverhead (mémoire hors heap pour les workers Python et les tampons), réduire les cœurs par executor, augmenter les partitions pour réduire les données par tâche, éviter les gros collects et le cache, et vérifier le déséquilibre.

Temporairement, c'est attendu : le NameNode re-réplique les blocs du nœud mort. Surveillez la progression ; si cela persiste, vérifiez le manque de capacité, les contraintes de racks, des problèmes de retrait ou une limitation réseau (dfs.namenode.replication.max-streams).

Extraire avec Spark JDBC (en parallèle par plages de clés) ou un outil de CDC, écrire en Parquet ou ORC dans un répertoire d'atterrissage daté, enregistrer les partitions dans le metastore, transformer vers des tables curées avec Hive ou Spark, lancer des contrôles de qualité et orchestrer avec Airflow ou Oozie.

C'est une façon de stocker et de traiter d'énormes volumes de données en les répartissant sur de nombreux ordinateurs ordinaires qui travaillent ensemble, de sorte que le système continue de fonctionner même si certaines machines tombent en panne.

Faire un repartition ou un coalesce avant l'écriture pour produire des fichiers proches de la taille de bloc, lancer des jobs de compaction périodiques sur les anciennes partitions, envisager un format de table qui compacte, et alerter sur le nombre de fichiers par répertoire.

La configuration et la contention des files (ETL qui déborde sur les heures ouvrées), de grosses requêtes ad hoc sans filtre de partition, la charge de HiveServer2 et du metastore, des statistiques manquantes, et le besoin éventuel de LLAP ou de capacité supplémentaire pour les utilisateurs interactifs.

À court terme : supprimer les données temporaires et la corbeille, réduire la réplication des données froides, imposer des quotas. À long terme : hiérarchiser les données (erasure coding, stockage archive), déplacer les données froides vers un stockage objet, compresser et convertir en formats en colonnes, appliquer des politiques de rétention et planifier la capacité.

Classer les tables par taille, usage et dépendances ; copier les données avec distcp vers le stockage objet ; convertir en Iceberg ou Delta (procédures de migration sur place ou CTAS) ; les enregistrer dans le nouveau catalogue ; traduire les jobs HiveQL en Spark SQL ou dbt ; migrer par vagues et par domaine en validant comptages et sommes de contrôle, et garder l'ancien cluster en lecture seule jusqu'à la bascule des consommateurs.

Les clients configurés avec l'adresse d'un seul NameNode au lieu du nameservice HA échouent ; les jobs en pleine opération de métadonnées peuvent recevoir des erreurs. Utilisez le nameservice logique (hdfs://nameservice1) avec des proxies de basculement côté client, et des relances dans les applications.