Migrer des données HDFS sur site vers Google Cloud

Last reviewed 2024-04-17 UTC

Dans ce guide, nous décrivons le processus de transfert de données du système HDFS (Hadoop Distributed File System) sur site vers Google Cloud.

Ce document est le deuxième d'une série de quatre guides consacrés au processus de migration depuis un environnement Hadoop sur site :

Planifier le transfert des données

Les sections suivantes décrivent les bonnes pratiques pour planifier la migration de vos données HDFS sur site vers Google Cloud. Prévoyez une migration incrémentielle, qui vous laissera le temps de migrer des jobs, de procéder à des expérimentations et d'effectuer des tests après le transfert de chaque lot de données.

Choisir une méthode pour le transfert des données

Deux modèles de migration sont envisageables pour le transfert de données HDFS vers le cloud : le modèle push et le modèle pull. Dans les deux cas, vous devez exécuter la commande Hadoop DistCp pour copier des données de vos clusters HDFS sur site vers Cloud Storage, mais en suivant des approches différentes.

Le modèle push est le modèle le plus simple : le cluster source exécute les tâches distcp sur ses nœuds de données, puis envoie les fichiers directement vers Cloud Storage, comme indiqué dans ce schéma :

Migration de données HDFS à l'aide du modèle push

Le modèle pull est plus complexe, mais présente certains avantages. Un cluster Dataproc éphémère exécute les tâches distcp sur ses nœuds de données, extrait les fichiers du cluster source et les copie dans Cloud Storage, comme indiqué dans le schéma suivant :

Migration de données HDFS à l'aide du modèle pull

Le modèle push est le plus simple des deux, car le cluster source peut envoyer des données directement vers Cloud Storage : vous n'avez donc pas besoin de créer des ressources de calcul supplémentaires pour effectuer la copie. Toutefois, si vous envisagez de continuer à vous servir du cluster source pour d'autres tâches de traitement de données standards durant la migration, vous devez vous assurer que ce cluster présente suffisamment de ressources disponibles en termes de processeur, de mémoire RAM et de bande passante réseau pour effectuer en plus les tâches de copie.

Si le cluster source fonctionne déjà à sa pleine capacité de calcul et que vous ne pouvez pas augmenter ses ressources pour effectuer la copie, vous devez envisager d'utiliser le modèle pull à la place.

Bien que plus complexe que le modèle push, le modèle pull présente de nombreux avantages :

  • Ce modèle a un impact réduit sur les ressources de processeur et de RAM du cluster source, car les nœuds sources ne sont sollicités que pour la diffusion des blocs depuis le cluster. Vous pouvez également affiner les spécifications des ressources du cluster de retrait sur Google Cloud de manière à gérer les tâches de copie, puis supprimer ce cluster de retrait une fois la migration terminée.
  • Le trafic généré sur le réseau du cluster source est réduit, ce qui permet de bénéficier de bandes passantes en sortie plus élevées et d'accélérer les transferts.
  • Il n'est pas nécessaire d'installer le connecteur Cloud Storage sur le cluster source, car c'est le cluster éphémère Dataproc, sur lequel le connecteur est déjà installé, qui gère le transfert de données vers Cloud Storage.

Pour comprendre les implications de chaque modèle sur l'utilisation du réseau, vous devez savoir comment Hadoop gère la réplication de données dans HDFS. Hadoop divise chaque fichier en plusieurs blocs d'une taille généralement comprise entre 128 et 256 mégaoctets. Hadoop réplique ces blocs sur plusieurs nœuds de données et sur plusieurs racks afin d'éviter toute perte de données en cas de défaillance d'un nœud de données ou d'un rack. La configuration standard prévoit le stockage de trois instances dupliquées de chaque bloc.

Hadoop utilise également la fonctionnalité Rack Awareness, qui garantit que deux copies de chaque bloc se trouvent dans deux nœuds de données distincts du même rack afin de réduire la latence, tandis qu'une troisième copie est placée sur un autre rack pour améliorer la redondance et la disponibilité. Cette logique de réplication est résumée dans le diagramme suivant :

Réplication de blocs HDFS avec la fonctionnalité Rack Awareness

Lors de la copie d'un fichier à l'aide du modèle push (qui prévoit l'exécution de la tâche de mappage distcp sur un nœud de données du cluster source), tous les blocs du fichier sont d'abord collectés à partir des différents nœuds de données. Les blocs du fichier sont ensuite déplacés du cluster source vers Cloud Storage. Le trafic généré sur le réseau peut représenter jusqu'à deux fois la taille totale du fichier, comme illustré dans le diagramme suivant :

Utilisation du réseau avec le modèle push

Lorsque vous copiez un fichier à l'aide du modèle pull (selon lequel la tâche de mappage distcp s'exécute sur un nœud de données du cluster de retrait présent dans Google Cloud), chaque bloc n'effectue qu'un seul trajet sur le réseau en sortant directement du cluster source. Le trafic réseau global est limité à la taille totale du fichier, comme illustré dans ce diagramme :

Utilisation du réseau avec le modèle pull

Lorsque vous vous servez du modèle pull, vous devez surveiller le nombre de tâches de mappage distcp et la bande passante utilisée, afin d'éviter de surcharger le cluster source à cause d'un trop grand nombre de connexions parallèles.

Choisir la destination des données

Le résultat final de la migration Hadoop peut être une solution cloud native ou une solution hybride, selon que votre système conserve ou non des composants sur site. Avec une solution cloud native, vous hébergez vos données dans le cloud, et vous exécutez des tâches sur ces données à partir de ce même environnement. Dans une solution hybride, une partie de vos données reste sur site. Vous pouvez soumettre ces données à des tâches exécutées sur site, ou exécuter dans le cloud des tâches qui opèrent sur vos données sur site.

Une solution cloud native est l'option la plus simple à gérer, mais des impératifs commerciaux ou techniques peuvent vous obliger à conserver certaines données ou certains traitements sur site. Chaque solution hybride est étroitement liée à un cas d'utilisation particulier, y compris en ce qui concerne la combinaison de technologies et de services mise en œuvre pour répondre aux besoins de votre charge de travail.

Transférer des données vers des produits autres que Cloud Storage

Nous vous recommandons de transférer la plupart de vos données vers Cloud Storage. Vous pouvez cependant envisager de transférer des données vers un autre produit Google Cloud dans certains cas :

  • Si vous migrez des données à partir d'Apache HBase, vous pouvez les déplacer vers Bigtable, qui fournit des fonctionnalités équivalentes.

  • Si vous migrez des données à partir d'Apache Impala, vous pouvez les transférer vers BigQuery, qui fournit des fonctionnalités équivalentes.

Vous pouvez aussi envisager d'exploiter des données provenant de HBase ou d'Impala sans les stocker dans Bigtable ou BigQuery. Si votre tâche ne fait pas appel aux fonctionnalités de Bigtable ou de BigQuery, stockez les données dans Cloud Storage.

Choisir l'emplacement des données en fonction des autorisations

Les autorisations relatives aux fichiers appliquées dans Google Cloud sont moins détaillées que celles des systèmes HDFS sur site. L'approche la moins compliquée en matière d'autorisations de fichiers consiste à définir celles-ci au niveau de chaque bucket Cloud Storage. Si vous avez défini des autorisations distinctes pour différents ensembles de données HDFS, vous pouvez envisager de créer plusieurs buckets Cloud Storage en associant à chacun des autorisations spécifiques. Placez ensuite chaque ensemble de données HDFS dans le bucket bénéficiant des autorisations appropriées.

Si la structure vers laquelle vous déplacez des fichiers dans Cloud Storage est différente de celle dont vous disposez dans HDFS, veillez à garder une trace de toutes les modifications. Lorsque vous transférerez des tâches vers Dataproc, vous devrez fournir les chemins d'accès correspondant au nouvel emplacement des données.

Planifier un transfert incrémentiel

Envisagez de transférer vos données par petits fragments espacés dans le temps. Prévoyez autant de temps que possible pour transférer les tâches correspondantes vers le cloud après chaque transfert de données. Démarrez la migration en déplaçant des données à faible priorité, telles que des sauvegardes et des archives.

Répartir les données

Si vous envisagez de transférer vos données de manière incrémentielle, vous devez les diviser en plusieurs parties. Dans les sections suivantes, nous décrivons les stratégies les plus courantes pour la répartition d'ensembles de données.

Répartir les données en fonction de l'horodatage

Pour répartir les données en vue d'un transfert incrémentiel, une approche courante consiste à stocker les données anciennes dans le cloud tout en conservant les données HDFS récentes dans votre système sur site. Cela vous permet de tester les tâches nouvelles ou migrées sur des données plus anciennes et moins critiques. Grâce à ce mode de répartition des données, vous pouvez commencer le transfert avec de petites quantités de données.

Remarques importantes :

  • Avez-vous la possibilité de répartir les données via une autre méthode en plus de la répartition temporelle ? Vous pouvez obtenir un ensemble de données plus ciblé en répartissant les données selon les tâches qui les utilisent ou l'organisation à laquelle elles appartiennent avant de leur appliquer une répartition temporelle.
  • Devez-vous utiliser un horodatage absolu ou relatif ? Il est parfois pertinent de répartir des données en fonction d'un moment déterminé, pour archiver toutes les données générées avant une modification importante du système, par exemple. L'utilisation d'un horodatage absolu est souvent appropriée si vous souhaitez créer des tâches de remplissage afin de tester votre système dans le cloud et de vérifier s'il est possible de traiter des données anciennes pour les adapter à vos normes actuelles. Dans d'autres cas, vous pouvez sélectionner les données à transférer vers le cloud en fonction d'un horodatage spécifique à la date actuelle. Par exemple, vous avez la possibilité de transférer toutes les données créées il y a plus d'un an ou toutes les données qui n'ont pas été modifiées au cours des trois derniers mois.
  • Quelle valeur d'horodatage utilisez-vous pour prendre la décision ? Les fichiers présentent souvent plusieurs valeurs d'horodatage. Parfois, c'est la date de création du fichier qui est la plus importante. Dans d'autres cas, vous pouvez utiliser la date et l'heure de la dernière modification ou un autre horodatage spécifié dans les métadonnées du fichier.
  • Toutes vos données présentent-elles le même format d'horodatage ? Il existe de nombreuses façons de gérer l'horodatage. Si vos données proviennent de plusieurs sources, il est possible que les valeurs d'horodatage soient stockées dans différents formats. Assurez-vous que les valeurs d'horodatage sont cohérentes avant de vous en servir pour répartir vos données.

Répartir les données par tâche

Il est parfois possible de répartir les données en fonction des tâches qui les utilisent. Cela peut être particulièrement utile si vous migrez des tâches de manière incrémentielle. Vous pouvez alors vous contenter de transférer les données utilisées par les tâches migrées.

Remarques importantes :

  • Les tâches que vous allez migrer vers le cloud sont-elles autonomes ? La répartition par tâche est une excellente option pour les tâches qui opèrent sur des unités de données autonomes, mais elle peut s'avérer difficile à gérer si les tâches font intervenir des données dispersées à l'échelle du système.
  • Les données sont-elles susceptibles de connaître les mêmes utilisations par la suite ? Réfléchissez bien avant d'isoler des données que vous pourriez être amené à exploiter de différentes manières.
  • La migration de tâches présente-t-elle un champ d'application permettant d'aboutir à des fragments de données gérables ?

Vous pouvez également utiliser des critères fonctionnels plus larges afin de baser la répartition sur les données, et non plus simplement sur des ensembles de tâches. Par exemple, vous pouvez exécuter l'ensemble du processus ETL dans le cloud, puis exécuter les tâches d'analyse et de création de rapports sur site.

Répartir les données par domaine de propriété

Dans certains cas, vous pouvez répartir vos données par domaine de propriété. L'un des avantages liés à cette approche réside dans l'alignement de l'organisation de vos données sur celle de l'entreprise. Cette approche présente un autre avantage : elle vous permet de tirer parti de la gestion des accès basée sur les rôles de Google Cloud. Par exemple, la migration des données utilisées par un rôle métier particulier vers un bucket Cloud Storage séparé facilite la configuration des autorisations.

Remarques importantes :

  • Les limites entre propriétaires sont-elles claires ? En règle générale, le principal propriétaire d'un élément de données est clairement établi, même si les personnes qui accèdent le plus souvent à des données n'en sont pas toujours propriétaires.
  • Y a-t-il d'autres critères de répartition que vous pourriez combiner avec la propriété ? Une répartition basée sur la seule propriété risque en effet d'engendrer de très grands ensembles de données. Il peut donc être utile d'affiner encore le ciblage par une répartition supplémentaire des données basée sur la tâche ou sur l'horodatage.

Maintenir la synchronisation des données dans une solution hybride

L'un des problèmes que pose l'utilisation d'une solution hybride est qu'une tâche a parfois besoin d'accéder à des données depuis Google Cloud aussi bien qu'à partir des systèmes sur site. Si vous devez accéder à un ensemble de données dans les deux environnements, il convient de lui attribuer un emplacement de stockage principal dans un environnement et de conserver une copie synchronisée dans l'autre.

Quel que soit l'emplacement principal que vous choisissez, les problèmes de synchronisation des données seront les mêmes. Il vous faut un moyen d'identifier le moment où les données ont changé, ainsi qu'un mécanisme permettant de propager les modifications aux copies correspondantes. S'il existe un risque de modifications conflictuelles, vous devez également développer une stratégie pour résoudre celles-ci.

Remarques importantes :

  • Assurez-vous que les copies des données sont en lecture seule, dans la mesure du possible. Chaque source potentielle de nouvelles modifications ajoute de la complexité à votre stratégie de synchronisation.
  • Dans une solution hybride, évitez de conserver plus de deux copies de données. Conservez en tout et pour tout une copie sur site et une copie dans Google Cloud.

Vous pouvez vous servir de technologies telles qu'Apache Airflow pour vous aider à gérer la synchronisation de vos données.

Transférer des données

Dans les sections suivantes, nous décrivons les considérations relatives au transfert de vos données vers Google Cloud.

Configurer l'accès aux données

Les autorisations de fichiers mises en œuvre sur Cloud Storage n'ont pas le même fonctionnement que celles de HDFS. Avant de transférer vos données vers Cloud Storage, vous devez vous familiariser avec Cloud Identity and Access Management (IAM).

Le moyen le plus simple de gérer le contrôle des accès consiste à répartir les données entre différents buckets Cloud Storage selon leurs conditions d'accès, puis de configurer votre stratégie d'autorisation au niveau du bucket. Les rôles déterminant les autorisations d'accès peuvent être attribués à des utilisateurs individuels, mais aussi à des groupes. Vous pouvez en effet accorder l'accès à des groupes, puis affectez des utilisateurs à ces groupes selon les besoins. Vous devez prendre des décisions en matière d'accès aux données lorsque vous importez et structurez ces dernières dans Cloud Storage.

Chaque produit Google Cloud possède ses propres autorisations et rôles. Assurez-vous de bien comprendre les relations entre les contrôles des accès de Cloud Storage et ceux de Dataproc. Évaluez séparément les stratégies relatives à chaque produit. Ne partez pas du principe qu'il existe une correspondance directe entre les rôles et les autorisations de ces produits.

Familiarisez-vous avec la documentation suivante afin de vous préparer à prendre des décisions stratégiques pour votre système Hadoop dans le cloud :

Si vous devez accorder des autorisations plus précises pour des fichiers individuels, Cloud Storage accepte les listes de contrôle d'accès (LCA). Toutefois, IAM est de loin l'option la plus recommandée. N'utilisez les LCA que si vos autorisations sont particulièrement complexes.

Utiliser DistCp pour copier des données sur Cloud Storage

Cloud Storage étant un système de fichiers compatible Hadoop, vous pouvez vous servir de Hadoop DistCp pour transférer des données de votre environnement HDFS sur site vers Cloud Storage. Bien que DistCp permette de transférer des données de différentes manières, nous vous recommandons la méthode suivante :

  1. Établissez une liaison privée entre votre réseau sur site et le réseau de Google à l'aide de Cloud Interconnect ou de Cloud VPN.

  2. Créez un cluster Dataproc utilisable pour le transfert de données.

  3. Servez-vous de Google Cloud CLI pour vous connecter à l'instance maîtresse de votre cluster. Exemple :

    gcloud compute ssh [CLUSTER_NAME]-m

    Où CLUSTER_NAME est le nom du cluster Dataproc que vous avez créé pour la tâche. Le suffixe -m identifie l'instance maîtresse.

  4. Sur l'instance maîtresse du cluster, exécutez les commandes DistCp pour transférer les données.

Les commandes DistCp dont vous avez besoin pour transférer vos données se présentent comme suit :

hadoop distcp hdfs://nn1:8020/20170202/ gs://bucket/20170202/

Dans cet exemple, nn1 et 8020 représentent le composant NameNode et le port sur lesquels vos données sources sont stockées, et bucket est le nom du bucket Cloud Storage dans lequel vous copiez le fichier.

Le trafic Cloud Storage est chiffré par défaut à l'aide du protocole TLS (Transport Layer Security).

Valider des transferts de données

Lorsque vous copiez ou déplacez des données entre des systèmes de stockage distincts, tels que plusieurs clusters HDFS ou entre HDFS et Cloud Storage, il est recommandé d'effectuer un certain type de validation pour garantir l'intégrité des données. Cette validation est essentielle pour s'assurer que les données n'ont pas été modifiées lors du transfert. Reportez-vous au guide Valider les transferts de données pour plus d'informations.

Augmenter le taux de demandes

Cloud Storage gère un index de clés d'objet pour chaque bucket afin de fournir une liste cohérente des objets. Cet index est stocké dans l'ordre lexicographique et est mis à jour chaque fois qu'un objet est créé dans un bucket ou supprimé d'un bucket. L'ajout ou la suppression d'objets dont toutes les clés se trouvent dans une petite plage de l'index augmente naturellement les chances de conflit.

Cloud Storage détecte ces conflits et répartit automatiquement la charge sur la plage d'index affectée entre plusieurs serveurs. Si vous créez des objets avec un nouveau préfixe et prévoyez d'atteindre un taux supérieur à 1 000 demandes d'écriture par seconde, augmentez progressivement le taux de demandes, comme indiqué dans la documentation de Cloud Storage. Sinon, votre latence et vos taux d'erreur pourraient temporairement s'accroître.

Améliorer la vitesse de migration des données

Le moyen le plus simple de transférer des données de vos clusters sur site vers Google Cloud consiste à utiliser un tunnel VPN sur le réseau Internet public. Si vous n'obtenez pas le débit requis avec un seul tunnel VPN, vous avez la possibilité de créer plusieurs tunnels VPN, auquel cas Google Cloud répartit automatiquement le trafic entre ces tunnels de manière à dégager de la bande passante supplémentaire.

Il peut cependant arriver que, même avec plusieurs tunnels VPN, la bande passante ou la stabilité de la connexion s'avère insuffisante pour répondre aux besoins de votre migration. Dans ce cas, voici les approches que vous pouvez envisager pour améliorer le débit :

  • Établissez un appairage direct entre votre réseau et les points de présence périphériques (PoP) de Google. Cette option réduit le nombre de sauts entre votre réseau et Google Cloud.

  • Faites appel à un fournisseur de services Cloud Interconnect pour établir une connexion directe au réseau de Google. Les détails du service varient selon les partenaires. La plupart des partenaires proposent un contrat de niveau de service portant sur la disponibilité et les performances du réseau. Adressez-vous directement à un fournisseur de services pour plus d'informations.

Travailler avec des partenaires Google Cloud

Google Cloud collabore avec différents partenaires pour vous aider à migrer vos données. Consultez la liste des partenaires travaillant avec Cloud Storage si vous souhaitez en savoir plus sur les services disponibles pour vous aider à mener à bien votre migration de données. Les services disponibles et leurs conditions d'utilisation varient selon les fournisseurs. Veuillez donc les contacter directement pour obtenir plus d'informations.

Étapes suivantes