Le choix de la région et du stockage est l’une des décisions les plus importantes avant la création d’un cluster E-MapReduce (EMR). Une région appropriée élimine les frais de transfert interrégionaux et réduit la latence. Une architecture de stockage adaptée détermine la capacité de mise à l’échelle de votre cluster, son coût et la pérennité de vos données en cas de suppression du cluster.
Sélectionner une région
Déployez votre cluster EMR dans la même région que vos données. Par exemple, si vos données source se trouvent dans un compartiment Object Storage Service (OSS) ou une instance ApsaraDB RDS situés en Chine (Shanghai), créez votre cluster en Chine (Shanghai). Si vous écrivez également des résultats dans OSS, créez ce compartiment dans la même région. La colocalisation du cluster et de ses données supprime les frais de transfert interrégionaux et réduit la latence.
Outre la localisation des données, prenez en compte les facteurs suivants lors du choix d’une région.
Critère | Vérifications à effectuer |
Disponibilité du service EMR | Vérifiez que le service EMR est disponible dans la région choisie. Certains services, tels qu’OSS-HDFS et Data Lake Formation (DLF), ne sont pas disponibles dans toutes les régions. Les types d’instances dotées de disques SSD locaux sont également spécifiques à certaines régions. |
Tarification des instances ECS | Les prix des instances Elastic Compute Service (ECS) varient selon les régions. Utilisez la Calculatrice de prix ECS pour comparer les coûts avant de vous engager. |
Topologie des services | Placez EMR dans la même région que les services dépendants, tels que Virtual Private Cloud (VPC), Server Load Balancer (SLB) et les bases de données, afin d’éviter les frais d’exploitation interrégionaux. Pour les déploiements cloud hybrides, choisissez la région la plus proche du point d’accès de votre centre de données. |
Régions prises en charge
|**Zone géographique**
|
**Régions**
| | --- | --- | |
**Asie-Pacifique - Chine**
|
Chine (Hangzhou), Chine (Shanghai), Chine (Qingdao), Chine (Pékin), Chine (Zhangjiakou), Chine (Hohhot), Chine (Ulanqab), Chine (Shenzhen), Chine (Chengdu), Chine (Hong Kong)
| |
**Asie-Pacifique - autres**
|
Japon (Tokyo), Singapour, Malaisie (Kuala Lumpur), Indonésie (Jakarta)
| |
**Europe et Amérique**
|
Allemagne (Francfort), Royaume-Uni (Londres), États-Unis (Silicon Valley), États-Unis (Virginie)
| |
**Moyen-Orient**
|
Émirats arabes unis (Dubaï)
|
Planifier le stockage
Choisir une architecture de stockage
EMR prend en charge deux architectures de stockage : la séparation calcul-stockage et l’intégration calcul-stockage.
HDFS est éphémère. Toutes les données stockées dans HDFS sont définitivement supprimées lors de la libération d’un cluster EMR. Si vous utilisez HDFS, sauvegardez les données critiques vers OSS ou OSS-HDFS avant de libérer le cluster.
Séparation calcul-stockage (OSS-HDFS ou OSS) | Intégration calcul-stockage (HDFS) | |
Cas d’utilisation | Architecture de lac de données ; analyse de données froides | Lecture et écriture à faible latence requises |
Persistance des données | Les données sont conservées après la libération du cluster | Les données sont supprimées lors de la libération du cluster |
Durabilité des données | 99,9999999999 % (douze neuf) | Repose sur un mécanisme de réplication ; aucune reprise après sinistre interrégionale |
Fiabilité des données | OSS prend en charge le stockage localement redondant (LRS) et le stockage redondant interzones (ZRS), offrant une haute fiabilité interzones | Trois réplicas pour les disques locaux, deux réplicas pour les disques cloud ; les réplicas sont confinés au cluster |
Mise à l’échelle | Ajoutez des nœuds de calcul (CN) indépendamment sans toucher au stockage | La mise à l’échelle du calcul et du stockage doit être conjointe ; la suppression des nœuds est séquentielle et nécessite un rééquilibrage |
Coût du stockage | 0,0170 USD/Go/Mois (stockage standard OSS). OSS-HDFS génère également des données auxiliaires, qui entraînent des frais de stockage OSS supplémentaires. Consultez la section Facturation OSS. | 0,051 USD/Gio/Mois Consultez les sections Facturation du stockage par blocs EBS et Tarification ECS. |
Exploitation et maintenance | Les nœuds de calcul sont sans état et peuvent être remplacés rapidement ; la capacité de stockage s’étend sans ajustement manuel du cluster | Les pannes de DataNode nécessitent un rééquilibrage manuel ; le redimensionnement du cluster requiert une intervention manuelle |
Accès |
| Cluster haute disponibilité : |
Choisir un type de disque
Chaque nœud d’un cluster EMR dispose d’un disque système et, éventuellement, d’un ou plusieurs disques de données.
|**Disque**
|
**Objectif**
|
**Types pris en charge**
| | --- | --- | --- | |
**Disque système**
|
Installe le système d’exploitation ; ne stocke pas les données métier
|
Disques cloud uniquement
| |
**Disque de données**
|
Stocke les données, les journaux locaux et les données de shuffle
|
Disques cloud et disques locaux
|
Avec une capacité de stockage identique, configurez plusieurs disques de données pour améliorer la disponibilité du service. Cette configuration permet à certains services d'offrir une tolérance aux pannes ; la fonctionnalité globale des disques de données n’est ainsi pas affectée en cas de défaillance d’un disque.
Disques cloud
Les disques cloud utilisent un mécanisme distribué à trois copies et offrent une fiabilité des données de 99,9999999 % (neuf neuf). EMR prend en charge trois types de disques cloud.
|**Type de disque**
|
**Latence**
|
**IOPS et débit**
|
**Cas d’utilisation**
| | --- | --- | --- | --- | |
[ESSD](t583241.xdita#)
|
0,2 ms
|
Élevé ; prend en charge les niveaux de performance PL0 à PL3. Consultez la section [Disques ESSD](t583241.xdita#).
|
Charges de travail sensibles à la latence ou intensives en E/S : bases de données OLTP à grande échelle, bases de données NoSQL, Elasticsearch
| |
SSD standard
|
0,5–2 ms
|
Relativement élevé
|
Applications intensives en E/S ; bases de données relationnelles et NoSQL de petite et moyenne taille
| |
Disque ultra
|
1–3 ms
|
Moyen
|
Développement et test ; disques système
|
Pour une comparaison détaillée des performances des disques cloud et des disques locaux, consultez la section Performances du stockage par blocs.
Disques locaux
Les disques locaux sont physiquement attachés au serveur hôte et offrent une latence extrêmement faible ainsi qu’un débit élevé pour le stockage de données à très grande échelle.
Dans la console EMR, les disques locaux sont attachés lorsque vous définissez le paramètre Type du groupe de nœuds sur Big Data ou Local SSD.
Les disques locaux ne sont pris en charge que sur les nœuds Core et Task, pas sur les nœuds Master.
Les données stockées sur les disques locaux peuvent être perdues en cas de défaillance matérielle de l’hôte. Configurez une politique de sauvegarde lorsque vous utilisez des disques locaux pour les données métier.
Évaluer la capacité de stockage
Après avoir sélectionné une architecture de stockage, estimez la capacité disque requise en fonction du volume de vos données et de leur tendance de croissance. Prévoyez au moins six mois de croissance des données.
|**Type de données**
|
**Description**
|
**Calcul**
| | --- | --- | --- | |
Données brutes
|
Données générées directement par votre activité, telles que les journaux
|
Espace requis = volume des données brutes
| |
Données intermédiaires
|
Données temporaires générées pendant le traitement, telles que les résultats ETL
|
Espace requis = volume des données brutes × 1,5 (à ajuster selon la complexité de la charge de travail)
| |
Données de résultat
|
Résultat final à conserver
|
Espace requis = volume des données brutes × 10 %–50 % (à ajuster selon les exigences de conservation)
|
Intégration calcul-stockage (HDFS) : Ajoutez la surcharge liée aux réplicas au total. HDFS utilise par défaut trois réplicas pour les disques locaux et deux réplicas pour les disques cloud.
Séparation calcul-stockage (OSS-HDFS ou OSS) : Les disques de données doivent uniquement accueillir les résultats de calcul temporaires, les journaux locaux et les données de shuffle. Les données métier sont stockées de manière durable dans OSS.