Les métadonnées E-MapReduce (EMR) contiennent des informations essentielles sur le stockage des données, leur structure et les 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 géré par l'utilisateur et MySQL intégré. Cette rubrique compare ces trois services afin de 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 des métadonnées entre plusieurs clusters | DLF |
| Contrôle granulaire du magasin de métadonnées avec votre propre instance RDS | ApsaraDB RDS géré par l'utilisateur |
| Test 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 opération d'exploitation et de maintenance (O&M), prend en charge tous les moteurs principaux (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 prise en charge de la haute disponibilité ni du partage entre clusters, ce qui peut entraîner une instabilité du service.
Comparaison des services de métadonnées
| Élément | DLF | ApsaraDB RDS géré par l'utilisateur | 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 la création du cluster. | Les données sont stockées dans l'instance MySQL d'un cluster EMR. |
| Applicable environment | Tests et production | Tests 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 multiversion, statistiques sur les 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 opération d'O&M requise. Mise à l'échelle automatique prise en charge. | O&M manuelle requise (mises à niveau et mise à l'échelle horizontale). Adapté à une gestion granulaire des clusters. | Augmente les coûts de mise à niveau. MySQL s'exécute sur un seul nœud du cluster. |
| Billing | Gratuit pour le moment. 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, permettant 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 géré par l'utilisateur
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 géré par l'utilisateur dans un seul cluster | Architecture de déploiement d'ApsaraDB RDS géré par l'utilisateur dans plusieurs clusters |
|---|---|
 |
 |
MySQL intégré
Les métadonnées sont stockées dans des instances MySQL déployées au sein des clusters EMR, généralement sur les nœuds maîtres. Chaque cluster disposant de sa propre base de données MySQL, le partage des métadonnées entre clusters n'est pas possible.
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 rubrique Utilisation de DLF pour unifier le stockage des métadonnées.
Pour configurer une base de données ApsaraDB RDS for MySQL gérée par l'utilisateur comme magasin de métadonnées, consultez la rubrique Configuration d'une instance RDS gérée par l'utilisateur.