E-MapReduce:Migration des clusters Hadoop vers des clusters DataLake

Informations générales

La console EMR Next-Gen est la plateforme open source de big data cloud-native de nouvelle génération d'E-MapReduce (EMR). Elle offre une nouvelle expérience utilisateur, une plateforme de développement, un modèle de ressource et des scénarios d'analytique. Pour plus de détails sur ses fonctionnalités, consultez l'Annonce : La console EMR Next-Gen est désormais disponible.

EMR on ECS, l'un des principaux modèles de ressource d'EMR, intègre plusieurs mises à jour fonctionnelles. En particulier, la console EMR Next-Gen introduit de nouveaux scénarios de cluster — DataLake, Dataflow, OLAP et Custom — qui améliorent considérablement l'efficacité de la gestion des clusters et les performances du moteur par rapport aux scénarios de cluster hérités (tels que Hadoop et Data Science). Les clusters DataLake constituent une version améliorée des anciens clusters de lac de données basés sur Hadoop. La mise à niveau vers des clusters DataLake vous offre de nombreux avantages. Pour une comparaison détaillée des fonctionnalités, consultez la rubrique Clusters DataLake.

Préparatifs

Examiner l'architecture du cluster hérité

Examinez votre architecture big data actuelle, clarifiez le scénario d'application du cluster hérité et notez les points suivants :

• Portée et versions des services : Notez les services et leurs versions exécutés sur chaque cluster hérité pour évaluer la compatibilité de la mise à niveau et les exigences de mise à jour des fonctionnalités.

• Type de métadonnées : Confirmez le type de métadonnées utilisé par le cluster hérité (DLF ou RDS auto-géré) afin de planifier les stratégies d'intégration et de migration pour le système de gestion des métadonnées dans la nouvelle architecture.

• Architecture de stockage des données : Analysez l'architecture de stockage des données du cluster hérité (HDFS local, OSS ou mode bloc JindoFS) pour concevoir le chemin de migration des données.

• Architecture d'authentification et d'autorisation des utilisateurs : Vérifiez si des services tels qu'OpenLDAP, Ranger ou Kerberos sont utilisés afin que la nouvelle architecture puisse hériter sans heurt des mécanismes de sécurité existants.

• Système d'ordonnancement : Confirmez votre système de développement et d'ordonnancement actuel pour maintenir une planification des tâches cohérente et fluide pendant la migration.

Si vous devez mettre à niveau plusieurs clusters hérités, migrez-les un par un pour garantir la continuité et la stabilité des activités. Établissez une séquence et un plan de migration pratiques, en fonction des besoins et des priorités réels de l'entreprise, pour assurer une transition en douceur des clusters hérités vers les nouveaux clusters.

Examiner les détails du cluster hérité

• Afficher les informations de configuration des instances de cluster

  Lors de la création d'un nouveau cluster sur la nouvelle plateforme, vous pouvez réutiliser les informations de base des instances du cluster hérité. Pour plus de détails, consultez la rubrique Créer un nouveau cluster. À l'exception des configurations logicielles et matérielles, qui nécessitent une attention particulière, vous pouvez utiliser des paramètres identiques pour les autres configurations dans les clusters hérités et nouveaux.

  Sur les pages Basic Information et Nodes du cluster EMR on ECS hérité, examinez les configurations du cluster et des groupes de nœuds, en vous concentrant sur les éléments suivants :

  Type de configuration	Nom de la configuration	Détails à examiner
  Configuration logicielle	Version du cluster Version du service Liste des composants réellement utilisés Type de métadonnées Hive	Liste des services actuellement utilisés dans le cluster et leurs versions correspondantes.
  Configuration matérielle	Zone où réside le cluster Type d'instance et méthode de facturation pour chaque groupe de nœuds	La zone du cluster et les spécifications matérielles de chaque groupe de nœuds — par exemple, CPU, mémoire, disque système et disque de données.

• (Facultatif) Exporter les configurations des composants de service du cluster

  Lors des opérations et de la maintenance courantes, les utilisateurs personnalisent souvent les configurations par défaut des composants de service ou ajoutent des paramètres personnalisés en fonction de besoins spécifiques. Pour migrer efficacement ces configurations entre les clusters, utilisez la fonctionnalité d'exportation de configuration d'EMR pour exporter par lot tous les paramètres de configuration du cluster hérité. Ensuite, lors de l'initialisation du nouveau cluster, importez ces paramètres par lot pour répliquer rapidement les configurations des composants de service. Vous pouvez également ajuster manuellement chaque configuration de service dans l'interface de gestion des services après le lancement réussi du nouveau cluster.

  1. Exportez les configurations de service.

     Consultez la rubrique Exporter et importer les configurations de service pour exporter en un clic les fichiers de configuration des composants de service ciblés.

     Remarque

     • Select Configuration Files : Sélectionnez uniquement les fichiers de configuration modifiés. Plusieurs sélections sont autorisées.

     • Export Mode : Le cluster Hadoop actuel ne prend pas en charge l'option exporting only custom or modified configurations.

     • Export Format : Sélectionnez le format JSON pour faciliter l'importation dans le nouveau cluster.

     Le tableau suivant décrit les paramètres du fichier de configuration exporté.

     Paramètre	Description
     ApplicationName	Nom du service.
     ConfigFileName	Nom du fichier de configuration.
     ConfigItemKey	Nom de l'élément de configuration.
     ConfigItemValue	Valeur spécifique définie pour l'élément de configuration.

  2. Modifiez le fichier de configuration.

     Examinez attentivement les informations de configuration exportées, conservez uniquement les éléments nécessaires applicables au nouvel environnement et supprimez les configurations inutiles.

     • Lors de l'ajustement des paramètres de ressource liés à YARN, alignez-les étroitement sur les spécifications matérielles réelles du cluster. Assurez-vous que les valeurs des paramètres importés sont raisonnables pour le nouveau cluster.

     • Si des configurations liées à JindoFS (par exemple, Credential Provider) existent, ajustez-les conformément aux configurations OSS/OSS-HDFS. Pour plus de détails, consultez la rubrique Configurer OSS/OSS-HDFS Credential Provider.

  3. Appliquez le fichier de configuration modifié à la section (Facultatif) Configuration logicielle personnalisée en tant que configurations prédéfinies pour le nouveau cluster.

• (Facultatif) Examiner les actions bootstrap

  Pendant la phase d'Affichage des informations de configuration des instances de cluster, vérifiez si des scripts bootstrap sont configurés sur le cluster hérité. Si des actions bootstrap existent, évaluez soigneusement la fonction de chaque script pour déterminer s'il doit être réutilisé dans le nouveau cluster.

  Pour les scripts nécessaires au nouveau cluster, effectuez les ajustements suivants pour garantir une exécution correcte :

  • Mettez à jour les noms et chemins des packages JAR liés aux versions des composants open source. Pour les chemins de fichiers dans les anciennes et nouvelles plateformes, consultez la rubrique Chemins de fichiers courants.

  • Si le script télécharge des fichiers depuis OSS, mettez à jour les commandes OSS correspondantes. Pour plus de détails, consultez la rubrique Scripts d'exécution des actions bootstrap.

  Après avoir modifié le script, téléchargez-le sur OSS et saisissez l'adresse OSS mise à jour lors de la création du nouveau cluster.

  Important

  Avant de déployer le script bootstrap sur un cluster de production, vérifiez-le dans un environnement de préproduction.

• (Facultatif) Examiner les règles Auto Scaling du cluster hérité

  Si des règles Auto Scaling sont configurées pour le cluster hérité, examinez-les — en vous concentrant sur le nombre maximal d'instances, le nombre minimal d'instances, l'arrêt gracieux, la méthode de déclenchement et les règles de déclenchement — et reconfigurez Auto Scaling après la création du nouveau cluster. Pour plus de détails, consultez la rubrique Créer une politique Auto Scaling personnalisée.

  1. Accédez à la page Auto Scaling.

     1. Connectez-vous à la console E-MapReduce.

     2. Cliquez sur le nom du cluster cible.

     3. Cliquez sur l'onglet Auto Scaling.

  2. Examinez les règles Auto Scaling.

     Dans l'onglet Auto Scaling, cliquez sur Configure Rule dans la colonne Actions pour le groupe de nœuds avec des règles Auto Scaling configurées. Concentrez-vous sur les éléments suivants :

     • Nombre maximal d'instances

     • Nombre minimal d'instances

     • Arrêt gracieux

     • Méthode de déclenchement

     • Règles de déclenchement (mise à l'échelle horizontale, réduction de l'échelle)

  Remarque

  Des paramètres tels que la méthode de sélection d'instance, le type de facturation, le type d'instance et l'arrêt gracieux sont configurés dans le panneau des propriétés du groupe de nœuds dans le nouveau cluster. Pour plus de détails, consultez la rubrique Gérer les groupes de nœuds.

• (Facultatif) Examiner les métriques de charge du cluster hérité

  Examinez les métriques de charge des ressources du cluster pour observer l'utilisation quotidienne des ressources dans le cluster hérité et évaluer les exigences matérielles pour le nouveau cluster. Vous pouvez également effectuer une migration fluide en faisant correspondre initialement exactement les spécifications matérielles du cluster hérité, puis ajuster la configuration matérielle du nouveau cluster ultérieurement en fonction de l'utilisation réelle des ressources.

  • Méthode 1 : Afficher la surveillance du cluster

    Vérifiez les métriques de charge du cluster, en vous concentrant sur l'utilisation de YARN et HDFS. Pour plus de détails, consultez la rubrique Afficher les métriques de surveillance des services.

  • Méthode 2 : Afficher les rapports quotidiens EMR Doctor

    Les rapports quotidiens EMR Doctor fournissent une analyse globale des ressources de calcul, des ressources d'ordonnancement YARN et des ressources de stockage HDFS. Vous pouvez examiner le volume total de données, la distribution des données chaudes/froides et la distribution des tâches de calcul. Pour plus de détails, consultez la rubrique Afficher les rapports quotidiens et l'analyse du cluster.

    Remarque

    EMR Doctor doit être installé sur les clusters hérités. Pour plus de détails, consultez la rubrique Activer EMR Doctor (type de cluster Hadoop).

Définir le plan de migration et le calendrier

En fonction de votre charge de travail big data actuelle et de la configuration de chaque cluster hérité, définissez la cible finale de migration et clarifiez les points clés suivants. Utilisez ces informations pour planifier les ressources humaines et le calendrier en conséquence.

• Version du produit et portée des services du nouveau cluster. Pour la compatibilité des services, consultez la section Versions du produit et services facultatifs.

• Option de métadonnées du nouveau cluster (DLF ou RDS auto-géré)

• Solution de stockage du nouveau cluster (OSS-HDFS ou OSS)

Étape 1 : Construire le cluster de nouvel environnement

Créer un nouveau cluster

Pour les étapes détaillées et les descriptions des paramètres, consultez la rubrique Créer un cluster. Remplissez les paramètres en fonction des détails de configuration du cluster recueillis lors de l'Affichage des informations de configuration des instances de cluster. Portez une attention particulière aux paramètres suivants.

• Versions du produit et services facultatifs

  En fonction de la liste des services recueillie lors de l'Affichage des informations de configuration des instances de cluster, consultez les informations de compatibilité pour sélectionner la portée des services et les versions appropriées pour le nouveau cluster.

  • Notes sur la compatibilité des composants

    À mesure que les services de la communauté open source évoluent, certains services dans les scénarios DataLake utilisent des versions supérieures à celles de Hadoop. Le tableau suivant montre les plages de compatibilité descendante. Utilisez les versions logicielles de votre cluster hérité ainsi que ce tableau pour déterminer les versions de service du nouveau cluster.

    Service du cluster hérité	Plage de compatibilité descendante 1	Plage de compatibilité descendante 2	Plage de compatibilité descendante 3	Plage de compatibilité descendante 4
    Spark	2.x	3.x	-	-
    Hive	2.x	3.x	-	-
    Tez	Fully compatible across all versions	-	-	-
    Delta Lake	0,6.x	0,8.0–1.1.0	-	-
    Iceberg	0,12.x	0,13.x	-	-
    Hudi	0,6.x	0,8.x	0,9.x	0,10.x
    Sqoop	Fully compatible across all versions	-	-	-
    Ranger	1.x	2.x	-	-
    OpenLDAP	Fully compatible across all versions	-	-	-

    Remarque

    • Plage de compatibilité descendante indique que dans cette plage, les versions supérieures sont compatibles avec les versions inférieures.

    • Les informations de compatibilité ci-dessus sont fournies à titre indicatif uniquement. Reportez-vous à la documentation officielle de la communauté open source pour des détails faisant autorité.

    • En raison des changements dans l'activité de la communauté open source et l'évolution technologique, certains services open source ne sont plus pris en charge sur la nouvelle plateforme EMR.

      Par exemple, Hue, Zeppelin et Oozie. Migrez vers EMR Notebook ou EMR Workflow, ou déployez manuellement les moteurs correspondants sur le cluster.

  • Sélectionner une version de produit appropriée

    Important

    Si les exigences de version logicielle sont satisfaites, choisissez la dernière version du produit EMR pour accéder à des fonctionnalités plus riches.

    Dans les scénarios DataLake, Alibaba Cloud EMR propose deux séries : EMR-3.x et EMR-5.x. Chaque série comprend plusieurs versions de produits avec des services intégrés et des versions variés. Lors de la construction d'un nouveau cluster, sélectionnez une version de produit en fonction de votre scénario d'application de lac de données et des exigences de compatibilité des services cibles. Le tableau suivant montre la correspondance entre les versions de l'ancienne et de la nouvelle plateforme.

    Version du cluster hérité	Version correspondante du nouveau cluster
    EMR-3.35.0 : YARN 2.8.5, HDFS 2.8.5, Hive 2.3.7, Spark 2.4.7	Série EMR-3.x
    EMR-5.6.0 : YARN 3.2.1, HDFS 3.2.1, Hive 3.1.2, Spark 3.2.1	Série EMR-5.x

  • Notes sur la sélection HDFS & OSS-HDFS

    Dans les versions EMR 5.12.1 et ultérieures, et 3.46.1 et ultérieures, vous pouvez choisir HDFS ou OSS-HDFS comme méthode de stockage du cluster dans les services facultatifs.

    En fonction de la solution de stockage définie dans la section Définir le plan de migration et le calendrier, sélectionnez le service correspondant lors de la configuration des services facultatifs lors de la création du nouveau cluster.

    Méthode de stockage du cluster de la nouvelle plateforme	Sélection de service
    OSS	OSS-HDFS
    OSS-HDFS	OSS-HDFS

    Remarque

    Lorsque vous sélectionnez OSS-HDFS dans le paramètre Optional Services, configurez le Root Storage Directory of Cluster en sélectionnant un Bucket avec OSS-HDFS activé comme chemin de stockage racine du cluster.

• Sélectionner les métadonnées

  La nouvelle plateforme EMR prend en charge les options de stockage de métadonnées suivantes. Choisissez en fonction de la solution de stockage de métadonnées définie dans la section Définir le plan de migration et le calendrier. Si une migration de métadonnées est requise, consultez la section Migration des métadonnées après la création du nouveau cluster.

  Méthode de stockage des métadonnées	Description
  Métadonnées DLF unifiées (recommandé)	Les métadonnées sont stockées dans Data Lake Formation (DLF). Si la plateforme héritée utilise déjà DLF, configurez le même catalogue de données DLF. Le nouveau cluster se connecte automatiquement aux mêmes métadonnées après la création, éliminant ainsi le besoin de migration.
  RDS auto-géré	Utilisez une instance Alibaba Cloud RDS auto-gérée comme base de données de métadonnées. Lors de la sélection de cette option, configurez les paramètres RDS existants. Pour plus de détails, consultez Configurer RDS auto-géré.
  MySQL intégré	Les métadonnées sont stockées dans une base de données MySQL locale sur le cluster. Important Cette option est destinée aux tests uniquement. Ne l'utilisez pas dans des environnements de production.

• (Facultatif) Configuration logicielle personnalisée

  Si vous avez exporté les configurations de service du cluster hérité ou si vous prévoyez de préconfigurer les paramètres lors de la création du cluster, activez la configuration logicielle personnalisée dans le workflow de création du nouveau cluster et collez les configurations modifiées dans la zone de saisie. Pour plus de détails, consultez la rubrique Configurer un logiciel personnalisé.

• Configuration matérielle

  Pendant la phase d'Affichage des informations de configuration des instances de cluster, vous pouvez comprendre pleinement les configurations matérielles pour chaque nœud. Pour les différents types de nœuds — Master, Core et Task — sélectionnez les ressources matérielles appropriées en fonction des besoins métier.

  • Lors de la création d'un nouveau cluster, utilisez les dernières familles d'instances ECS et les types de disques cloud pour tirer parti des nouvelles fonctionnalités matérielles.

  • Pour ajouter davantage de groupes de nœuds avec le même rôle, utilisez la fonctionnalité d'ajout de groupe de nœuds après la création du cluster.

  • Attacher un réseau public : Activez cette option par groupe de nœuds. Une fois activée, tous les nœuds du groupe reçoivent des adresses IP publiques.

    Activez l'attachement au réseau public pour le groupe de nœuds Master afin de vous connecter au nœud maître via le réseau public ou d'utiliser les liens d'accès et les fonctionnalités de mappage de port d'EMR.

(Facultatif) Créer une nouvelle Gateway

Les Gateways sont principalement utilisées pour soumettre des jobs aux clusters de calcul et fournir une isolation. Si vous utilisiez un cluster Gateway sur l'ancienne plateforme, créez une Gateway sur la nouvelle plateforme comme suit.

La nouvelle plateforme offre des options de déploiement Gateway plus flexibles, permettant de déployer des Gateways sur des instances ECS existantes avec une synchronisation automatique des configurations du cluster de calcul. Pour simplifier le déploiement des Gateways, EMR fournit un outil appelé EMR-CLI, qui vous aide à configurer facilement une Gateway sur des instances Alibaba Cloud ECS existantes. Pour plus de détails, consultez la rubrique Utiliser EMR-CLI pour personnaliser le déploiement Gateway.

Étape 2 : Migration et validation

Après avoir construit l'environnement du nouveau cluster, migrez les métadonnées, les données et les jobs du cluster hérité.

Migration des métadonnées

Les anciennes et nouvelles plateformes EMR prennent en charge trois méthodes de gestion des métadonnées : RDS auto-géré, DLF et MySQL intégré. Pour la nouvelle plateforme, nous recommandons vivement d'utiliser le service de métadonnées DLF. En fonction des méthodes de gestion des métadonnées utilisées dans les clusters hérités et nouveaux, utilisez les approches de migration suivantes.

Migration des données

Après avoir créé le nouveau cluster, utilisez les méthodes de migration suivantes en fonction des différences de stockage entre les clusters hérités et nouveaux pour garantir une migration des données précise et réussie.

Validation de l'exactitude des données

Après avoir terminé la migration des données, validez l'exactitude des données HDFS et des bases de données/tables Hive. Si une incohérence des données est détectée, prenez des mesures immédiates — telles que la réexécution des jobs affectés ou la restauration des données manquantes.

Choisissez une méthode de validation en fonction de vos exigences spécifiques.

Migration des jobs

Pour garantir que les jobs du cluster hérité s'exécutent correctement sur le nouveau cluster, appliquez les stratégies de migration suivantes en fonction de votre système d'ordonnancement et de votre environnement :

• Si vous utilisez l'ancien Data Studio d'EMR, migrez vers EMR Workflow. Pour plus de détails, consultez l'Annonce : Migrer depuis l'ancien Data Studio EMR.

• Si vous utilisez un autre environnement de développement (par exemple, Alibaba Cloud DataWorks ou une plateforme auto-construite), suivez le guide de migration fourni par cet environnement.

  Reportez-vous attentivement à la documentation de migration spécifique à votre plateforme et ajustez les configurations — telles que le changement des informations du cluster de calcul — pour garantir que les jobs s'ordonnancent et s'exécutent correctement sur le nouveau cluster.

Étape 3 : Validation en double exécution parallèle

Pour minimiser l'impact potentiel sur les activités en direct lors de la migration du cluster, effectuez une validation en double exécution entre les clusters hérités et nouveaux. Cela implique de répliquer le trafic en direct vers le nouveau cluster et d'exécuter des jobs simultanément pour valider de manière complète la cohérence des données et l'exactitude métier.

Étant donné que les méthodes de validation en double exécution varient en fonction de votre environnement de développement, des caractéristiques métier et des besoins de traitement des données, nous recommandons vivement de concevoir un plan de validation en double exécution flexible adapté à votre scénario et à vos exigences spécifiques.

Étape 4 : Mettre hors service le cluster hérité

Après avoir validé avec succès les données et les opérations métier, procédez au basculement. Déplacez progressivement les charges de travail des jobs du cluster hérité vers le nouveau cluster, en augmentant progressivement le volume de traitement sur le nouveau cluster jusqu'à ce que toutes les activités s'exécutent de manière stable dessus.

Une fois que toutes les activités sont entièrement migrées et que le cluster hérité est inactif, mettez-le hors service en toute sécurité en suivant la procédure de Libérer un cluster.