Les métadonnées E-MapReduce (EMR) contiennent les informations essentielles relatives au stockage des données, à leur structure et aux autorisations d'accès au sein des clusters EMR. EMR prend en charge trois services de métadonnées : Data Lake Formation (DLF), ApsaraDB RDS autogéré et MySQL intégré. Cette rubrique compare ces trois services pour vous aider à choisir celui qui correspond le mieux à votre charge de travail.
Quel service utiliser ?
| Situation | Service recommandé |
|---|---|
| Nouveau cluster destiné aux tests ou à la production | DLF |
| Clusters existants nécessitant un partage de métadonnées inter-clusters | DLF |
| Contrôle précis du magasin de métadonnées avec votre propre instance RDS | ApsaraDB RDS autogéré |
| Tests de concept (POC) à court terme sur un seul cluster | MySQL intégré |
Pour la plupart des charges de travail, privilégiez DLF. Ce service ne nécessite aucune exploitation ni maintenance (O&M), prend en charge tous les principaux moteurs (y compris MaxCompute et Hologres) et offre une haute disponibilité (HA) intégrée.
N'utilisez pas MySQL intégré dans des environnements de test ou de production. La base de données MySQL s'exécute sur un seul nœud maître sans haute disponibilité ni prise en charge du partage inter-clusters, ce qui peut entraîner une instabilité du service.
Comparaison des services de métadonnées
| Élément | DLF | ApsaraDB RDS autogéré | MySQL intégré |
|---|---|---|---|
| Backend storage | Les données sont stockées dans DLF. | Les données sont stockées dans des instances ApsaraDB RDS for MySQL. Achetez et configurez une instance avant de créer le cluster. | Les données sont stockées dans l'instance MySQL d'un cluster EMR. |
| Applicable environment | Test et production | Test et production | Tests POC sur un seul cluster uniquement |
| Cross-cluster metadata sharing | Pris en charge | Pris en charge | Non pris en charge |
| Engine compatibility | Hive, Spark, Presto, MaxCompute et Hologres | Hive, Spark et Presto | Hive, Spark et Presto |
| Metadata management | Récupération visualisée des métadonnées, gestion des métadonnées, gestion multi-version, statistiques de données et gestion du cycle de vie | Aucune | Aucune |
| High availability | Reprise après sinistre primaire/secondaire | Reprise après sinistre primaire/secondaire | Non pris en charge |
| O&M cost | Aucune O&M requise. Mise à l'échelle automatique prise en charge. | O&M manuelle requise (mises à niveau et extension horizontale). Adapté à la gestion fine des clusters. | Augmente les coûts de mise à niveau. MySQL s'exécute sur un seul nœud de cluster. |
| Billing | Actuellement gratuit. Consultez la section Facturation pour plus de détails. | Facturé selon les ressources de calcul et de stockage. Consultez la section Éléments facturables pour plus de détails. | Gratuit |
Vérifiez les régions prises en charge avant de sélectionner un service de métadonnées. Pour connaître les régions prises en charge par DLF, consultez la page Régions et endpoints pris en charge .
Architecture de déploiement
DLF
Les métadonnées sont stockées dans DLF et partagées entre plusieurs clusters. Le SDK client DLF expose des API compatibles avec Hive Metastore, ce qui permet aux moteurs d'accéder directement aux métadonnées via le SDK. Pour plus d'informations, consultez la documentation relative à l'Présentation du produit.
| Architecture de déploiement de DLF dans un seul cluster | Architecture de déploiement de DLF dans plusieurs clusters |
|---|---|
 |
 |
ApsaraDB RDS autogéré
Les métadonnées sont stockées dans des instances ApsaraDB RDS for MySQL et partagées entre plusieurs clusters via Hive Metastore.
| Architecture de déploiement d'ApsaraDB RDS autogéré dans un seul cluster | Architecture de déploiement d'ApsaraDB RDS autogéré dans plusieurs clusters |
|---|---|
 |
 |
MySQL intégré
Les métadonnées sont stockées dans des instances MySQL déployées dans les clusters EMR, généralement sur les nœuds maîtres. Comme chaque cluster dispose de sa propre base de données MySQL, les métadonnées ne peuvent pas être partagées entre les clusters.
Les identifiants par défaut pour MySQL intégré sont le nom d'utilisateurrootet le mot de passeEMRroot1234.
| Architecture de déploiement de MySQL intégré dans un seul cluster | Architecture de déploiement de MySQL intégré dans plusieurs clusters |
|---|---|
 |
 |
Étapes suivantes
Pour basculer vers DLF afin d'unifier le stockage des métadonnées, consultez la page Utiliser DLF pour unifier le stockage des métadonnées.
Pour configurer une base de données ApsaraDB RDS for MySQL autogérée en tant que magasin de métadonnées, consultez la page Configurer RDS autogéré.