2 La migration de HDFS vers le stockage objet est l’un des projets de plateforme de données les plus courants de ces dernières années. Les organisations qui ont construit des clusters Hadoop il y a une décennie font face à un matériel vieillissant, à un couplage étroit entre calcul et stockage, à une exploitation complexe et, parfois, à des changements dans le support des éditeurs. Déplacer les données du système de fichiers distribué Hadoop vers un stockage objet compatible S3 sépare le stockage du calcul, ouvre la voie aux moteurs et formats de tables modernes et simplifie l’exploitation. C’est aussi un projet vaste et délicat, qui porte souvent sur des pétaoctets de données et des centaines de traitements conçus pour le comportement de HDFS. Cet article explique pourquoi les organisations quittent HDFS pour le stockage objet, les différences qui comptent, les approches et outils de migration, la gestion des tables, de la sécurité et de la validation, et le phasage du projet. Pour l’architecture cible, consultez notre guide sur l’exploitation d’un data lakehouse sur un stockage objet sur site. Pourquoi quitter HDFS Calcul et stockage couplés : HDFS stocke les données sur les mêmes nœuds que le calcul ; augmenter le stockage oblige à ajouter du calcul, et inversement. Surcoût de la réplication : HDFS conserve traditionnellement trois répliques des données, ce qui triple la capacité brute. Le codage à effacement des versions récentes de HDFS aide, mais ajoute de la complexité. Le stockage objet utilise généralement le codage à effacement en natif. Complexité d’exploitation : la haute disponibilité du NameNode, l’équilibrage, les mises à niveau et la gestion des versions de l’écosystème exigent des compétences spécialisées. Limites du NameNode : les métadonnées HDFS résident dans la mémoire du NameNode, ce qui limite le nombre de fichiers et rend les petits fichiers coûteux. Moteurs modernes : les moteurs distribués de requêtes et de traitement, souvent exécutés sur des plateformes de conteneurs, fonctionnent naturellement avec le stockage compatible S3 et les formats de tables ouverts. Renouvellement du matériel : des clusters Hadoop vieillissants sont l’occasion de changer d’architecture plutôt que de remplacer à l’identique. Les différences clés entre HDFS et le stockage objet Renommages Dans HDFS, les renommages sont des opérations de métadonnées rapides et atomiques, et de nombreux traitements Hadoop écrivent dans un répertoire temporaire puis le renomment à la fin. Le stockage objet n’offre pas de renommage atomique de répertoire : renommer revient à copier puis supprimer des objets. Les traitements doivent utiliser des committers conçus pour le stockage objet, comme les committers S3A de Hadoop, ou des formats de tables ouverts qui évitent totalement les renommages. Listes de répertoires HDFS liste rapidement les répertoires. Sur le stockage objet, le listage peut être plus lent pour de très grands préfixes. Les formats de tables qui suivent les fichiers dans leurs métadonnées, plutôt que par listage, évitent ce problème. Autorisations HDFS utilise des autorisations de type POSIX et souvent des politiques Ranger ou Sentry. Le stockage objet utilise des politiques de bucket et d’objet et des identités de type IAM. Les modèles d’accès doivent être transposés et repensés. Localité des données Hadoop rapprochait le calcul des données sur les mêmes nœuds. Avec le stockage objet, le calcul lit les données via le réseau : la bande passante entre calcul et stockage devient critique. Les approches de migration Migration à l’identique avec DistCp L’outil DistCp de Hadoop copie les données en parallèle de HDFS vers un stockage compatible S3 via le connecteur S3A. C’est la méthode standard pour déplacer de gros volumes, et il peut être exécuté de façon incrémentale pour rattraper les modifications. Planifiez la bande passante et copiez par lots, jeu de données par jeu de données. Modernisation table par table Plutôt que de copier les fichiers à l’aveugle, migrez les tables vers un format moderne. Les anciennes tables organisées en répertoires peuvent être converties en format de table ouvert, soit en enregistrant les fichiers existants sur place, soit en créant de nouvelles tables et en copiant les données. La plupart des formats de tables ouverts proposent des procédures pour créer des tables à partir de fichiers de données existants. Période hybride La plupart des migrations font fonctionner HDFS et le stockage objet côte à côte pendant un temps. Les traitements basculent vers la lecture et l’écriture sur le stockage objet jeu de données par jeu de données, tandis que HDFS reste disponible jusqu’à la migration de toutes les charges de travail. Migrer les traitements, pas seulement les données Les données ne représentent que la moitié de la migration. Chaque traitement, pipeline et requête doit être mis à jour : Chemins : remplacer les chemins hdfs:// par s3a:// ou l’équivalent pour chaque moteur. Committers : activer les committers pour stockage objet dans les traitements qui écrivent des résultats. Configuration : points de terminaison, accès par chemin, identifiants et TLS pour chaque moteur. Mise à niveau des moteurs : beaucoup d’équipes passent en même temps des anciens moteurs batch aux moteurs SQL et de traitement distribués modernes. Ordonnancement : mettre à jour l’orchestration pour pointer les traitements vers les nouveaux emplacements. Dressez tôt l’inventaire des traitements et de leurs dépendances ; cela prend généralement plus de temps que le déplacement des données. Sécurité et gouvernance Transposez les utilisateurs, groupes et politiques HDFS en identités et politiques de bucket du stockage objet. Définissez l’organisation des buckets par domaine ou par niveau de sensibilité, appliquez le chiffrement et la journalisation d’audit, et intégrez les fournisseurs d’identité existants. Si Ranger ou des outils similaires servent au contrôle d’accès fin, vérifiez leur intégration avec les nouveaux moteurs et le stockage. L’article sur les politiques d’accès S3 (en anglais) traite de leur conception. Valider la migration Les sommes de contrôle calculées par HDFS ne sont pas directement comparables aux ETags du stockage objet, surtout pour les téléversements en plusieurs parties. Les approches de validation comprennent : Le nombre et la taille des fichiers par jeu de données et par partition. Des empreintes de contenu calculées indépendamment sur les fichiers source et cible pour les jeux de données critiques. Le nombre de lignes et des agrégats pour les tables, en comparant les résultats des requêtes sur la source et la cible. La comparaison des résultats des traitements pendant les exécutions en parallèle. Consignez les résultats de validation pour l’audit, en particulier dans les environnements réglementés. Gérer les petits fichiers et les données froides Les environnements Hadoop contiennent souvent un très grand nombre de petits fichiers issus de traitements en flux, de journaux et de pipelines mal configurés. Les copier tels quels vers le stockage objet transporte le problème, avec plus de requêtes et des requêtes plus lentes. Une migration est le bon moment pour regrouper les petits fichiers en fichiers plus gros, pendant la copie ou lors de la conversion des tables en format ouvert. Les données froides qui n’ont pas été lues depuis des années méritent aussi un examen : certaines peuvent passer vers un niveau ou un bucket moins coûteux avec des règles de cycle de vie, et d’autres peuvent être supprimées selon la politique de conservation au lieu d’être migrées. Réduire ce qui doit être déplacé raccourcit le projet et abaisse le coût de la plateforme cible. Bande passante et durée de copie Planifiez la durée de copie de façon réaliste. Déplacer 5 Po à un débit soutenu de 10 Go par seconde demande environ six jours de transfert continu, et les débits réels sont généralement plus faibles une fois pris en compte les charges de production, la validation et les reprises. Beaucoup d’équipes programment les copies la nuit et le week-end sur plusieurs mois, en commençant par les jeux de données chauds pour que les charges les plus utilisées puissent migrer tôt. Des exécutions incrémentales de DistCp rattrapent les modifications avant chaque bascule. Compétences et équipes Passer de Hadoop à un lakehouse change les compétences autant que la technologie. Les administrateurs Hadoop deviennent des ingénieurs plateforme qui exploitent le stockage objet, les plateformes de conteneurs et les moteurs modernes. Les ingénieurs de données adoptent les formats de tables ouverts et de nouveaux outils. Planifiez la formation tôt et associez l’équipe d’exploitation au pilote, pour qu’elle soit prête à exploiter la nouvelle plateforme avant le retrait de l’ancienne. Phaser le projet Évaluer : inventorier données, tables, traitements, utilisateurs et dépendances ; repérer les données froides qui n’ont peut-être pas besoin d’être déplacées. Construire : déployer le stockage objet, le réseau, les moteurs et le catalogue. Piloter : migrer de bout en bout un jeu de données non critique et ses traitements. Migrer par vagues : déplacer jeux de données et traitements par domaine, en validant chaque vague. Basculer : faire basculer les charges restantes et geler les écritures sur HDFS. Décommissionner : retirer HDFS après une période de sécurité définie. Dimensionner la cible Dimensionnez le stockage objet pour les données migrées et la croissance, avec le surcoût du codage à effacement au lieu de la triple réplication HDFS. Beaucoup d’organisations constatent qu’il leur faut nettement moins de capacité brute après avoir quitté un HDFS triplement répliqué. Dimensionnez la bande passante réseau pour les débits de lecture analytiques, puisque le calcul ne lit plus de disques locaux. Considérations régionales et réglementaires De nombreux environnements Hadoop appartiennent à des banques, des opérateurs télécoms, des administrations et des fournisseurs d’énergie soumis à des exigences strictes de localisation des données. Migrer vers un stockage objet sur site garde les données dans le pays tout en modernisant la plateforme, et évite l’examen réglementaire que pourrait déclencher un passage vers un cloud public étranger. Liste de contrôle : migration de HDFS vers le stockage objet Inventorier données, tables, traitements, utilisateurs et dépendances. Décider quelles données migrer, archiver ou supprimer. Choisir entre migration à l’identique et modernisation des tables, souvent les deux. Activer les committers pour stockage objet ou passer à un format de table ouvert. Transposer les autorisations en politiques de bucket et en identités. Dimensionner la bande passante réseau entre calcul et stockage. Copier les données par vagues avec DistCp ou des outils au niveau des tables. Valider avec des comptages, des empreintes et des comparaisons de requêtes. Faire fonctionner HDFS et le stockage objet en parallèle pendant la transition. Décommissionner HDFS après une période de sécurité. En résumé La migration de HDFS vers le stockage objet sépare le stockage du calcul, réduit le surcoût de la réplication et permet d’adopter des moteurs et formats de tables modernes. Les principales difficultés ne tiennent pas à la copie des octets, mais à l’adaptation des traitements à la sémantique du stockage objet, à la refonte de la sécurité et à la validation des résultats. Faites un inventaire rigoureux, migrez par vagues, utilisez des committers ou des formats de tables ouverts pour éviter les problèmes de renommage, dimensionnez correctement le réseau et gardez HDFS disponible jusqu’à ce que chaque charge de travail ait été migrée et vérifiée. Questions fréquentes Pourquoi migrer de HDFS vers le stockage objet ? Pour séparer le calcul du stockage, réduire le surcoût de la réplication, simplifier l’exploitation et adopter des moteurs et formats de tables modernes. Quel outil copie les données de HDFS vers un stockage compatible S3 ? Hadoop DistCp avec le connecteur S3A est l’outil standard, exécuté en parallèle et de façon incrémentale. Les traitements Hadoop fonctionnent-ils sans modification sur le stockage objet ? Souvent non. Les chemins, les committers, la configuration et parfois les moteurs doivent changer, en particulier pour les traitements qui reposent sur les renommages. Comment valider une migration HDFS ? Comparez le nombre et la taille des fichiers, calculez des empreintes de contenu indépendantes pour les données critiques et comparez le nombre de lignes et les résultats des requêtes sur les tables. Aurai-je besoin de moins de capacité après la migration ? Souvent oui, car le stockage objet utilise généralement le codage à effacement au lieu de la triple réplication HDFS. Pour aller plus loin Data lakehouse sur site Formats de tables ouverts sur S3 sur site Performances des moteurs SQL sur stockage objet Data lakes souverains Stockage objet pour les data lakes (en anglais)
