Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Versions AMI 2.x et 3.x d'Amazon EMR
**Note**
AWS met à jour la configuration TLS pour tous les points de terminaison d' AWS API vers une version minimale de TLS 1.2. Les versions 3.10 et antérieures d'Amazon EMR ne prennent en charge que les connexions TLS 1.0/1.1. Après le 4 décembre 2023, vous ne pourrez plus créer de clusters avec Amazon EMR 3.10 ou version antérieure.
Si vous utilisez Amazon EMR 3.10 ou une version antérieure, nous vous recommandons de tester et de migrer immédiatement vos charges de travail vers la dernière version d'Amazon EMR. Pour plus d'informations, consultez le [Blog sur la sécurité d'AWS](https://aws.amazon.com/blogs//security/tls-1-2-required-for-aws-endpoints/).
Les versions Amazon EMR 2.x and 3.x, appelées *versions AMI*, sont disponibles pour les solutions pré-existantes qui en ont besoin pour des raisons de compatibilité. Il est déconseillé de créer de nouveaux clusters ou de nouvelles solutions avec ces versions. Elles ne sont pas dotées des fonctions présentes dans les versions plus récentes et contiennent des packages d'application obsolètes.
Nous vous recommandons d'utiliser la version la plus récente d'Amazon EMR pour créer des solutions.
Il existe des différences significatives entre les versions 2.x et 3.x et les versions récentes d'Amazon EMR. Ces différences s'appliquent à différents domaines, comme la création et la configuration d'un cluster, ou encore les ports et la structure de répertoire des applications sur le cluster.
Cette section tente de répertorier les différences les plus importantes pour Amazon EMR, ainsi que les différences spécifiques portant sur la gestion et la configuration des applications. Elle n'est pas exhaustive. Si vous créez et utilisez des clusters dans les versions 2.x ou 3.x, il se peut que vous rencontriez des différences non répertoriées dans cette section.
**Topics**
+ [Création d'un cluster avec des versions AMI plus récentes d'Amazon EMR](emr-3x-create.md)
+ [Installation d'applications avec des versions AMI antérieures d'Amazon EMR](emr-3x-install-apps.md)
+ [Personnalisation de la configuration des clusters et des applications avec des versions AMI antérieures d'Amazon EMR](emr-3x-customizeappconfig.md)
+ [Caractéristiques de l'application Hive pour les versions AMI antérieures d'Amazon EMR](emr-3x-hive.md)
+ [HBase spécificités de l'application pour les versions antérieures de l'AMI d'Amazon EMR](emr-3x-hbase.md)
+ [Caractéristiques de l'application Pig pour les versions AMI antérieures d'Amazon EMR](emr-3x-pig.md)
+ [Caractéristiques de l'application Spark pour les versions AMI antérieures d'Amazon EMR](emr-3x-spark.md)
+ [Différences entre l'DistCp utilitaire S3 et les versions antérieures de l'AMI d'Amazon EMR](emr-3x-s3distcp.md)
# Création d'un cluster avec des versions AMI plus récentes d'Amazon EMR
Les versions Amazon EMR 2.x et 3.x sont référencées par la version AMI. À partir des versions 4.0.0 et ultérieures d'Amazon EMR, les publications sont référencées par version, à l'aide d'une étiquette de version telle que `emr-5.11.0`. Ce changement est particulièrement visible lorsque vous créez un cluster à l'aide du AWS CLI ou par programmation.
Lorsque vous utilisez le AWS CLI pour créer un cluster à l'aide d'une version de version AMI, utilisez l'`--ami-version`option, par exemple,`--ami-version 3.11.0`. De nombreuses options, fonctions et applications introduites dans les versions 4.0.0 et ultérieures d'Amazon EMR ne sont pas disponibles lorsque vous spécifiez une option `--ami-version`. Pour plus d'informations, consultez [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/emr/create-cluster.html) dans la *Référence des commandes de la AWS CLI *.
L'exemple de AWS CLI commande suivant lance un cluster à l'aide d'une version AMI.
**Note**
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr create-cluster --name "Test cluster" --ami-version 3.11.0 \
--applications Name=Hue Name=Hive Name=Pig \
--use-default-roles --ec2-attributes KeyName=myKey \
--instance-groups InstanceGroupType=MASTER,InstanceCount=1,\
InstanceType=m3.xlarge InstanceGroupType=CORE,InstanceCount=2,\
InstanceType=m3.xlarge --bootstrap-actions Path=s3://elasticmapreduce/bootstrap-actions/configure-hadoop,\
Name="Configuring infinite JVM reuse",Args=["-m","mapred.job.reuse.jvm.num.tasks=-1"]
```
Par programmation, toutes les versions d'Amazon EMR utilisent l'action `RunJobFlowRequest` de l'API EMR pour créer des clusters. Dans l'exemple suivant, le code Java crée un cluster à l'aide de la version AMI 3.11.0.
```
RunJobFlowRequest request = new RunJobFlowRequest()
.withName("AmiVersion Cluster")
.withAmiVersion("3.11.0")
.withInstances(new JobFlowInstancesConfig()
.withEc2KeyName("myKeyPair")
.withInstanceCount(1)
.withKeepJobFlowAliveWhenNoSteps(true)
.withMasterInstanceType("m3.xlarge")
.withSlaveInstanceType("m3.xlarge");
```
L'appel `RunJobFlowRequest` suivant utilise quant à lui une étiquette de version :
```
RunJobFlowRequest request = new RunJobFlowRequest()
.withName("ReleaseLabel Cluster")
.withReleaseLabel("emr-7.12.0")
.withInstances(new JobFlowInstancesConfig()
.withEc2KeyName("myKeyPair")
.withInstanceCount(1)
.withKeepJobFlowAliveWhenNoSteps(true)
.withMasterInstanceType("m3.xlarge")
.withSlaveInstanceType("m3.xlarge");
```
## Configuration de la taille du cluster
Lorsque votre cluster s'exécute, Hadoop détermine le nombre de tâches de mappeur et de réducteur nécessaires pour traiter les données. Les clusters les plus grands doivent avoir plus de tâches pour une meilleure utilisation des ressources et une plus courte durée de traitement. En règle générale, un cluster EMR conserve la même taille tout au long de sa vie ; vous définissez le nombre de tâches lorsque vous créez le cluster. Lorsque vous redimensionnez un cluster en cours d'exécution, vous pouvez modifier le traitement au cours de l'exécution du cluster. Par conséquent, au lieu d'utiliser un nombre fixe de tâches, vous pouvez modifier le nombre de tâches au cours de la vie du cluster. Il existe deux options de configuration qui vous aideront à définir le nombre idéal de tâches :
+ `mapred.map.tasksperslot`
+ `mapred.reduce.tasksperslot`
Vous pouvez définir ces deux options dans le fichier `mapred-conf.xml`. Lorsque vous soumettez un travail au cluster, le client du travail vérifie le nombre total actuel d'emplacements de mappage et de réduction disponibles sur l'ensemble du cluster. Le client du travail utilise alors les équations suivantes pour définir le nombre de tâches :
+ `mapred.map.tasks` =` mapred.map.tasksperslot` \$1 emplacements de mappage dans le cluster
+ `mapred.reduce.tasks` = `mapred.reduce.tasksperslot` \$1 emplacements de réduction dans le cluster
Le client du travail lit uniquement le paramètre `tasksperslot` si le nombre de tâches n'est pas configuré. Vous pouvez remplacer le nombre de tâches à tout moment, pour tous les clusters via une action d'amorçage ou individuellement, travail par travail, en ajoutant une étape pour modifier la configuration.
Amazon EMR supporte les défaillances des nœuds de tâches et continue l'exécution du cluster même si un nœud de tâches cesse d'être disponible. Amazon EMR alloue automatiquement des nœuds de tâches supplémentaires pour remplacer les nœuds défaillants.
Vous pouvez avoir un nombre différent de nœuds de tâches pour chaque étape du cluster. Vous pouvez également ajouter une étape à un cluster en cours d'exécution pour modifier le nombre de nœuds de tâches. Étant donné que toutes les étapes sont garanties de s'exécuter de manière séquentielle par défaut, vous pouvez spécifier le nombre de nœuds de tâches en cours d'exécution pour n'importe quelle étape.
# Installation d'applications avec des versions AMI antérieures d'Amazon EMR
Lorsque vous utilisez une version AMI, les applications sont installées de différentes manières, notamment en utilisant le `NewSupportedProducts` paramètre de l'[RunJobFlow](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_RunJobFlow.html)action, en utilisant les actions d'amorçage et en utilisant l'action [Step](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_Step.html).
# Personnalisation de la configuration des clusters et des applications avec des versions AMI antérieures d'Amazon EMR
Amazon EMR version 4.0.0 a introduit une méthode simplifiée pour configurer des applications à l'aide de classifications de configuration. Pour de plus amples informations, veuillez consulter [Configuration des applications](emr-configure-apps.md). Lorsque vous utilisez une version AMI, vous configurez les applications à l'aide des actions d'amorçage et des arguments que vous transmettez. Par exemple, les actions d'amorçage `configure-hadoop` et `configure-daemons` définissent les propriétés des environnements Hadoop et YARN telles que `--namenode-heap-size`. Dans les versions plus récentes, ces propriétés sont configurées à l'aide des classifications de configuration `hadoop-env` et `yarn-env`. Pour les actions de bootstrap qui exécutent des configurations courantes, consultez le [emr-bootstrap-actions référentiel sur Github](https://github.com/awslabs/emr-bootstrap-actions).
Les tableaux suivants associent les actions d'amorçage aux classifications de configuration correspondantes dans les versions plus récentes d'Amazon EMR.
**Hadoop**
| Nom du fichier d'application concerné | Action d'amorçage de la version d'AMI | Classification de configuration |
| --- | --- | --- |
| core-site.xml | configure-hadoop -c | core-site |
| log4j.properties | configure-hadoop -l | hadoop-log4j |
| hdfs-site.xml | configure-hadoop -s | hdfs-site |
| N/A | s/o | hdfs-encryption-zones |
| mapred-site.xml | configure-hadoop -m | mapred-site |
| yarn-site.xml | configure-hadoop -y | yarn-site |
| httpfs-site.xml | configure-hadoop -t | httpfs-site |
| capacity-scheduler.xml | configure-hadoop -z | capacity-scheduler |
| yarn-env.sh | configure-daemons --resourcemanager-opts | yarn-env |
**Hive**
| Nom du fichier d'application concerné | Action d'amorçage de la version d'AMI | Classification de configuration |
| --- | --- | --- |
| hive-env.sh | N/A | hive-env |
| hive-site.xml | hive-script --install-hive-site \$1\$1MY\$1HIVE\$1SITE\$1FILE\$1 | hive-site |
| hive-exec-log4j.properties | N/A | hive-exec-log4j |
| hive-log4j.properties | s/o | hive-log4j |
**EMRFS**
| Nom du fichier d'application concerné | Action d'amorçage de la version d'AMI | Classification de configuration |
| --- | --- | --- |
| emrfs-site.xml | configure-hadoop -e | emrfs-site |
| N/A | s3get -s s3://custom-provider.jar -d /usr/share/aws/emr/auxlib/ | emrfs-site (avec le nouveau paramètre fs.s3.cse.encryptionMaterialsProvider.uri) |
Pour obtenir une liste de toutes les classifications, consultez [Configuration des applications](emr-configure-apps.md).
## Variables d'environnement d'application
Lorsque vous utilisez une version AMI, un script `hadoop-user-env.sh` est utilisé avec l'action d'amorçage `configure-daemons` pour configurer l'environnement Hadoop. Les actions suivantes sont incluses dans le script :
```
#!/bin/bash
export HADOOP_USER_CLASSPATH_FIRST=true;
echo "HADOOP_CLASSPATH=/path/to/my.jar" >> /home/hadoop/conf/hadoop-user-env.sh
```
Dans Amazon EMR version 4.x, vous procédez de la même façon en utilisant la classification de configuration `hadoop-env`, comme illustrée dans l'exemple suivant :
```
[
{
"Classification":"hadoop-env",
"Properties":{
},
"Configurations":[
{
"Classification":"export",
"Properties":{
"HADOOP_USER_CLASSPATH_FIRST":"true",
"HADOOP_CLASSPATH":"/path/to/my.jar"
}
}
]
}
]
```
Autre exemple : l'utilisation de `configure-daemons` et la transmission de `--namenode-heap-size=2048` et `--namenode-opts=-XX:GCTimeRatio=19` équivalent aux classifications de configuration suivantes.
```
[
{
"Classification":"hadoop-env",
"Properties":{
},
"Configurations":[
{
"Classification":"export",
"Properties":{
"HADOOP_DATANODE_HEAPSIZE": "2048",
"HADOOP_NAMENODE_OPTS": "-XX:GCTimeRatio=19"
}
}
]
}
]
```
D'autres variables de l'environnement d'application ne sont plus définies dans `/home/hadoop/.bashrc`. Au lieu de cela, elles sont principalement définies dans les fichiers `/etc/default` par composant ou par application, par exemple, `/etc/default/hadoop`. Les scripts wrapper `/usr/bin/` installés par l'application RPMs peuvent également définir des variables d'environnement supplémentaires avant d'impliquer le script bin lui-même.
## Ports de service
Lorsque vous employez une version AMI, certains services utilisent des ports personnalisés.
**Modifications des paramètres de port**
| Paramètre | Version AMI 3.x | Open source par défaut |
| --- | --- | --- |
| fs.default.name | hdfs://emrDeterminedIP:9000 | par défaut (hdfs : emrDeterminedIP //:8020) |
| dfs.datanode.address | 0.0.0.0:9200 | valeur par défaut (0.0.0.0:50010) |
| dfs.datanode.http.address | 0.0.0.0:9102 | valeur par défaut (0.0.0.0:50075) |
| dfs.datanode.https.address | 0.0.0.0:9402 | valeur par défaut (0.0.0.0:50475) |
| dfs.datanode.ipc.address | 0.0.0.0:9201 | valeur par défaut (0.0.0.0:50020) |
| dfs.http.address | 0.0.0.0:9101 | valeur par défaut (0.0.0.0:50070) |
| dfs.https.address | 0.0.0.0:9202 | valeur par défaut (0.0.0.0:50470) |
| dfs.secondary.http.address | 0.0.0.0:9104 | valeur par défaut (0.0.0.0:50090) |
| yarn.nodemanager.address | 0.0.0.0:9103 | valeur par défaut (\$1\$1yarn.nodemanager.hostname\$1:0) |
| yarn.nodemanager.localizer.address | 0.0.0.0:9033 | valeur par défaut (\$1\$1yarn.nodemanager.hostname\$1:8040) |
| yarn.nodemanager.webapp.address | 0.0.0.0:9035 | valeur par défaut (\$1\$1yarn.nodemanager.hostname\$1:8042) |
| yarn.resourcemanager.address | emrDeterminedIP:9022 | valeur par défaut (\$1\$1yarn.resourcemanager.hostname\$1:8032) |
| yarn.resourcemanager.admin.address | emrDeterminedIP:9025 | valeur par défaut (\$1\$1yarn.resourcemanager.hostname\$1:8033) |
| yarn.resourcemanager.resource-tracker.address | emrDeterminedIP:9023 | valeur par défaut (\$1\$1yarn.resourcemanager.hostname\$1:8031) |
| yarn.resourcemanager.scheduler.address | emrDeterminedIP:9024 | valeur par défaut (\$1\$1yarn.resourcemanager.hostname\$1:8030) |
| yarn.resourcemanager.webapp.address | 0.0.0.0:9026 | valeur par défaut (\$1\$1yarn.resourcemanager.hostname\$1:8088) |
| yarn.web-proxy.address | emrDeterminedIP:9046 | valeur par défaut (no-value) |
| yarn.resourcemanager.hostname | 0.0.0.0 (par défaut) | emrDeterminedIP |
**Note**
*emrDeterminedIP*Il s'agit d'une adresse IP générée par Amazon EMR.
## Utilisateurs
Lorsque vous utilisez une version AMI, l'utilisateur `hadoop` exécute tous les processus et possède tous les fichiers. Dans Amazon EMR 4.0.0 et versions ultérieures, les utilisateurs existent au niveau de l'application et des composants.
## Séquence d'installation, artefacts installés et emplacement des fichiers journaux
Lorsque vous utilisez une version AMI, les artefacts de l'application et leurs répertoires de configuration sont installés dans le répertoire `/home/hadoop/application`. Par exemple, si vous avez installé Hive, le répertoire est `/home/hadoop/hive`. A partir des versions 4.0.0 et ultérieures d'Amazon EMR, les artefacts de l'application sont installés dans le répertoire `/usr/lib/application`. Lorsque vous utilisez une version AMI, les fichiers journaux sont situés à différents emplacements. Le tableau ci-dessous répertorie ces emplacements.
**Modification des emplacements des journaux sur Amazon S3**
| Démon ou application | Emplacement du répertoire |
| --- | --- |
| instance-state | noeud/ /instance-state/ instance-id |
| hadoop-hdfs-namenode | démons//.log instance-id hadoop-hadoop-namenode |
| hadoop-hdfs-datanode | démons//.log instance-id hadoop-hadoop-datanode |
| fil de hadoop () ResourceManager | démons//instance-idyarn-hadoop-resourcemanager |
| hadoop-yarn (serveur Proxy) | démons//instance-idyarn-hadoop-proxyserver |
| mapred-historyserver | démons//instance-id |
| httpfs | daemons/ /httpfs.log instance-id |
| hive-server | noeud/ /hive-server/hive-server.log instance-id |
| hive-metastore | noeud/ /apps/hive.log instance-id |
| Interface de ligne de commande Hive | noeud/ /apps/hive.log instance-id |
| Journaux utilisateur et journaux de conteneur des applications YARN | task-attempts/ |
| Mahout | N/A |
| Pig | N/A |
| spark-historyserver | N/A |
| Fichiers d'historique des tâches mapreduce | jobs/ |
## Exécuteur de commandes
Lorsque vous utilisez une version AMI, de nombreux scripts ou programmes comme `/home/hadoop/contrib/streaming/hadoop-streaming.jar` ne sont pas placés dans l'environnement du chemin d'accès de connexion au shell, ce qui signifie que vous devez spécifier le chemin d'accès complet lorsque vous utilisez un fichier jar (command-runner.jar ou script-runner.jar, par exemple) pour exécuter les scripts. Le fichier `command-runner.jar` se trouve sur l'image AMI, si bien qu'il n'est pas nécessaire de connaître un URI complet comme c'était le cas avec `script-runner.jar`.
## Facteur de réplication
Le facteur de réplication vous permet de configurer à quel moment démarrer une machine virtuelle Java. Vous pouvez démarrer une nouvelle JVM Hadoop pour chaque tâche, ce qui permet une meilleure isolation des tâches, ou vous pouvez les partager JVMs entre les tâches, ce qui permet de réduire les frais de structure. Si vous traitez un grand nombre de petits fichiers, il est logique de réutiliser la JVM plusieurs fois pour amortir les coûts de démarrage. Toutefois, si chaque tâche prend du temps ou traite une grande quantité de données, vous pouvez choisir de ne pas réutiliser la JVM, afin de vous assurer que l'ensemble de la mémoire est libérée pour les tâches suivantes. Lorsque vous utilisez une version AMI, vous pouvez personnaliser le facteur de réplication à l'aide de l'action d'amorçage `configure-hadoop` pour définir la propriété `mapred.job.reuse.jvm.num.tasks`.
L'exemple suivant illustre la définition du facteur de réutilisation de la machine virtuelle Java pour une réutilisation infinie de cette dernière.
**Note**
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr create-cluster --name "Test cluster" --ami-version 3.11.0 \
--applications Name=Hue Name=Hive Name=Pig \
--use-default-roles --ec2-attributes KeyName=myKey \
--instance-groups InstanceGroupType=MASTER,InstanceCount=1,InstanceType=m3.xlarge \
InstanceGroupType=CORE,InstanceCount=2,InstanceType=m3.xlarge \
--bootstrap-actions Path=s3://elasticmapreduce/bootstrap-actions/configure-hadoop,\
Name="Configuring infinite JVM reuse",Args=["-m","mapred.job.reuse.jvm.num.tasks=-1"]
```
# Caractéristiques de l'application Hive pour les versions AMI antérieures d'Amazon EMR
## Les fichiers journaux
Lorsque vous utilisez les versions AMI 2.x et 3.x d'Amazon EMR, les fichiers journaux Hive sont enregistrés dans `/mnt/var/log/apps/`. La version de Hive que vous exécutez détermine le nom du fichier journal, comme illustré dans le tableau suivant. Cela permet de prendre en charge les versions simultanées de Hive.
| Version de Hive | Nom du fichier journal |
| --- | --- |
| 0.13.1 | hive.log A partir de cette version, Amazon EMR utilise un nom de fichier non versionné, `hive.log`. Les versions mineures partagent le même emplacement du journal que la version majeure. |
| 0.11.0 | hive\$10110.log Les versions mineures de Hive 0.11.0, par exemple 0.11.0.1, partagent le même emplacement du fichier journal que Hive 0.11.0. |
| 0.8.1 | hive\$1081.log Les versions mineures de Hive 0.8.1, par exemple Hive 0.8.1.1, partagent le même emplacement du fichier journal que Hive 0.8.1. |
| 0.7.1 | hive\$107\$11.log Les versions mineures de Hive 0.7.1, par exemple Hive 0.7.1.3 et Hive 0.7.1.4, partagent le même emplacement du fichier journal que Hive 0.7.1. |
| 0.7 | hive\$107.log |
| 0.5 | hive\$105.log |
| 0.4 | hive.log |
## Fonctionnalité de format d'entrée avec fractionnement
Pour implémenter la fonctionnalité de format d'entrée avec fractionnement à l'aide des versions de Hive antérieures à 0.13.1 (versions AMI d'Amazon EMR antérieures à 3.11.0), utilisez les commandes suivantes :
```
hive> set hive.input.format=org.apache.hadoop.hive.ql.io.HiveCombineSplitsInputFormat;
hive> set mapred.min.split.size=100000000;
```
Cette fonctionnalité est devenue obsolète avec Hive 0.13.1. Pour profiter de la même fonctionnalité de format d'entrée avec fractionnement dans la version 3.11.0 AMI Amazon EMR, procédez comme suit :
```
set hive.hadoop.supports.splittable.combineinputformat=true;
```
## Ports de service Thrift
Thrift est une infrastructure RPC qui définit un format de sérialisation binaire compact utilisé pour conserver les structures de données afin de les analyser ultérieurement. Généralement, Hive configure le serveur pour qu'il fonctionne sur les ports suivants.
| Version de Hive | Numéro de port |
| --- | --- |
| Hive 0.13.1 | 10 000 |
| Hive 0.11.0 | 10004 |
| Hive 0.8.1 | 10003 |
| Hive 0.7.1 | 10002 |
| Hive 0.7 | 10001 |
| Hive 0.5 | 10 000 |
Pour plus d'informations sur les services thrift, consultez [http://wiki.apache.org/thrift/](http://wiki.apache.org/thrift/).
## Utilisation de Hive pour récupérer des partitions
Amazon EMR inclut une instruction du langage de requête Hive qui récupère les partitions d'une table depuis des données de table situées dans Amazon S3. L'exemple suivant en est une illustration.
```
CREATE EXTERNAL TABLE (json string) raw_impression
PARTITIONED BY (dt string)
LOCATION 's3://elastic-mapreduce/samples/hive-ads/tables/impressions';
ALTER TABLE logs RECOVER PARTITIONS;
```
Les données et les répertoires de la partition doit être à l'emplacement spécifié dans la définition de table et doivent être nommées selon la convention Hive : par exemple, `dt=2009-01-01`.
**Note**
Après Hive 0.13.1, cette fonctionnalité est prise en charge en mode natif à l'aide de `msck repair table` et par conséquent la prise en charge de `recover partitions` n'est plus assurée. Pour plus d'informations, consultez [https://cwiki.apache. org/confluence/display/Hive/LanguageManual\$1DDL](https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL).
## Transmission d'une variable Hive à un script
Pour transmettre une variable à une étape Hive à l'aide de AWS CLI, tapez la commande suivante, *myKey* remplacez-la par le nom de votre paire de clés EC2 et remplacez-la par le nom *amzn-s3-demo-bucket* de votre bucket. Dans cet exemple, `SAMPLE` est une valeur de variable précédée par le commutateur `-d`. Cette variable est définie dans le script Hive comme suit : `${SAMPLE}`.
**Note**
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr create-cluster --name "Test cluster" --ami-version 3.9 \
--applications Name=Hue Name=Hive Name=Pig \
--use-default-roles --ec2-attributes KeyName=myKey \
--instance-type m3.xlarge --instance-count 3 \
--steps Type=Hive,Name="Hive Program",ActionOnFailure=CONTINUE,\
Args=[-f,s3://elasticmapreduce/samples/hive-ads/libs/response-time-stats.q,-d,\
INPUT=s3://elasticmapreduce/samples/hive-ads/tables,-d,OUTPUT=s3://amzn-s3-demo-bucket/hive-ads/output/,\
-d,SAMPLE=s3://elasticmapreduce/samples/hive-ads/]
```
## Spécification d'un emplacement de metastore externe
La procédure suivante vous montre comment remplacer les valeurs de configuration par défaut pour l'emplacement du metastore Hive et démarrer un cluster en utilisant l'emplacement du metastore reconfiguré.
**Pour créer un metastore situé en dehors du cluster EMR**
1. Créez une base de données MySQL ou Aurora à l'aide d'Amazon RDS.
Pour plus d'informations sur la façon de créer une base de données Amazon RDS, consultez [Mise en route sur Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.html).
1. Modifiez vos groupes de sécurité pour autoriser les connexions JDBC entre votre base de données et le groupe de sécurité **ElasticMapReduce-Master**.
Pour plus d'informations sur la façon de modifier vos groupes de sécurité pour l'accès, consultez [Groupes de sécurité Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html) dans le *Guide de l'utilisateur Amazon RDS*.
1. Définissez les valeurs de configuration JDBC dans `hive-site.xml` :
1. Créez un fichier de configuration `hive-site.xml` contenant les éléments suivants :
```
javax.jdo.option.ConnectionURL
jdbc:mariadb://hostname:3306/hive?createDatabaseIfNotExist=true
JDBC connect string for a JDBC metastore
javax.jdo.option.ConnectionUserName
hive
Username to use against metastore database
javax.jdo.option.ConnectionPassword
password
Password to use against metastore database
```
*hostname*est l'adresse DNS de l'instance Amazon RDS qui exécute la base de données. *username*et *password* sont les informations d'identification de votre base de données. Pour plus d'informations sur la connexion aux instances de bases de données MySQL et Aurora, consultez les sections [Connexion à une instance de base de données exécutant le moteur de base de données MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html) et [Connexion à un cluster de bases de données Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Connecting.html) dans le *Guide de l'utilisateur Amazon RDS*.
Les pilotes JDBC sont installés par Amazon EMR.
**Note**
La propriété value ne doit pas contenir d'espaces ni de retours chariot. Elle doit figurer entièrement sur une seule ligne.
1. Enregistrez votre fichier `hive-site.xml` dans un emplacement sur Amazon S3, tel que `s3://amzn-s3-demo-bucket/hive-site.xml`.
1. Créez un cluster, en spécifiant l'emplacement Amazon S3 du fichier `hive-site.xml` personnalisé.
L'exemple de commande suivant illustre une AWS CLI commande qui effectue cette opération.
**Note**
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr create-cluster --name "Test cluster" --ami-version 3.10 \
--applications Name=Hue Name=Hive Name=Pig \
--use-default-roles --ec2-attributes KeyName=myKey \
--instance-type m3.xlarge --instance-count 3 \
--bootstrap-actions Name="Install Hive Site Configuration",\
Path="s3://region.elasticmapreduce/libs/hive/hive-script",\
Args=["--base-path","s3://elasticmapreduce/libs/hive","--install-hive-site",\
"--hive-site=s3://amzn-s3-demo-bucket/hive-site.xml","--hive-versions","latest"]
```
## Connexion à Hive à l'aide de JDBC
Pour vous connecter à Hive via JDBC, vous devez télécharger le pilote JDBC et installer un client SQL. L'exemple suivant montre comment utiliser SQL Workbench/J pour se connecter à Hive à l'aide de JDBC.
**Pour télécharger les pilotes JDBC**
1. Téléchargez et extrayez les pilotes correspondant aux versions de Hive auxquelles vous souhaitez accéder. La version de Hive varie en fonction de l'image AMI que vous choisissez lorsque vous créez un cluster Amazon EMR.
+ [Pilotes JDBC Hive 0.13.1 : JDBC\$11.0.4.1004.zip https://amazon-odbc-jdbc-drivers.s3.amazonaws.com/public/ AmazonHive](https://amazon-odbc-jdbc-drivers.s3.amazonaws.com/public/AmazonHiveJDBC_1.0.4.1004.zip)
+ Pilotes JDBC Hive 0.11.0 : [https://mvnrepository.com/artifact/org.apache.hive/hive-jdbc/0.11.0](https://mvnrepository.com/artifact/org.apache.hive/hive-jdbc/0.11.0)
+ Pilotes JDBC Hive 0.8.1 : [https://mvnrepository.com/artifact/org.apache.hive/hive-jdbc/0.8.1](https://mvnrepository.com/artifact/org.apache.hive/hive-jdbc/0.8.1)
1. Installez SQL Workbench/J. Pour plus d'informations, consultez la section [Installation et démarrage de SQL Workbench/J](http://www.sql-workbench.net/manual/install.html) dans le manuel d'utilisation de SQL Manual. Workbench/J
1. Créez un tunnel SSH vers le nœud maître du cluster. Le port de connexion diffère en fonction de la version de Hive. Les exemples fournis dans les tableaux ci-dessous concernent les utilisateurs de Linux (commandes `ssh`) et les commandes PuTTY pour les utilisateurs de Windows
**Commandes SSH Linux**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-3x-hive.html)
**Paramètres du tunnel PuTTY (Windows)**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-3x-hive.html)
1. Ajoutez le pilote JDBC à SQL Workbench.
1. Dans la boîte de dialogue **Select Connection Profile (Sélectionner le profil de connexion)**, sélectionnez **Manage Drivers (Gérer les pilotes)**.
1. Sélectionnez l'icône **Create a new entry (Créer une nouvelle saisie)** (page blanche).
1. Dans le champ **Name (Nom)**, saisissez **Hive JDBC**.
1. Pour **Library (Bibliothèque)**, cliquez sur l'icône **Select the JAR file(s) (Sélectionner le(s) fichier(s) JAR)**.
1. Sélectionnez les fichiers JAR comme indiqué dans le tableau suivant.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-3x-hive.html)
1. Dans la boîte de dialogue **Please select one driver (Veuillez sélectionner un pilote)**, sélectionnez un pilote en vous conformant au tableau suivant, puis cliquez sur **OK**.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-3x-hive.html)
1. Lorsque vous revenez à la boîte de dialogue **Select Connection Profile (Sélectionner le profil de connexion)**, vérifiez que le champ **Driver (Pilote)** est défini sur **Hive JDBC** et fournissez la chaîne de connexion JDBC dans le champ **URL**, en vous conformant au tableau suivant.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-3x-hive.html)
Si votre cluster utilise la version 3.3.1 d'AMI ou une version ultérieure, dans la boîte de dialogue **Select Connection Profile (Sélectionner le profil de connexion)**, tapez **hadoop** dans le champ **Username (Nom d'utilisateur)**.
# HBase spécificités de l'application pour les versions antérieures de l'AMI d'Amazon EMR
## HBase Versions prises en charge
| HBase version | Version d'AMI | AWS CLI paramètres de configuration | HBase détails de la version |
| --- | --- | --- | --- |
| [0.94.18](https://svn.apache.org/repos/asf/hbase/branches/0.94/CHANGES.txt) | 3.1.0 et ultérieures | `--ami-version 3.1` `--ami-version 3.2` `--ami-version 3.3` `--applications Name=HBase` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-3x-hbase.html) |
| [0.94.7](https://svn.apache.org/repos/asf/hbase/branches/0.94/CHANGES.txt) | 3.0-3.0.4 | `--ami-version 3.0` `--applications Name=HBase` |
| [0.92](https://svn.apache.org/repos/asf/hbase/branches/0.92/CHANGES.txt) | 2.2 et ultérieures | `--ami-version 2.2 or later` `--applications Name=HBase` |
## HBase prérequis du cluster
Un cluster créé à l'aide des versions 2.x et 3.x de l'AMI Amazon EMR doit répondre aux exigences suivantes pour. HBase
+ Le AWS CLI (facultatif) —Pour interagir à HBase l'aide de la ligne de commande, téléchargez et installez la dernière version du AWS CLI. Pour plus d’informations, consultez [Installation d’ AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) dans le *Guide de l’utilisateur AWS Command Line Interface *.
+ Au moins deux instances (facultatif) : le nœud principal du cluster exécute le serveur maître HBase et Zookeeper, et les nœuds de tâche exécutent les serveurs de région HBase. Pour de meilleures performances, les clusters HBase doivent s'exécuter sur au moins deux instances EC2, mais vous pouvez les exécuter HBase sur un seul nœud à des fins d'évaluation.
+ Cluster de longue durée : HBase ne s'exécute que sur des clusters de longue durée. Par défaut, l'interface de ligne de commande et la console Amazon EMR créent des clusters de longue durée.
+ Un jeu de paires de clés Amazon EC2 (recommandée) : pour utiliser le protocole Secure Shell (SSH) pour vous connecter avec le nœud principal et exécuter les commandes de shell HBase, vous devez utiliser une paire de clés Amazon EC2 lorsque vous créez le cluster.
+ Versions d'AMI et d'Hadoop correctes : les HBase clusters ne sont actuellement pris en charge que sur Hadoop 20.205 ou version ultérieure.
+ Ganglia (facultatif) : pour surveiller les indicateurs de HBase performance, installez Ganglia lors de la création du cluster.
+ Un compartiment Amazon S3 pour les journaux (facultatif) : les journaux pour HBase sont disponibles sur le nœud principal. Si vous voulez que ces journaux soient copiés dans Amazon S3, spécifiez un compartiment S3 qui contiendra les fichiers journaux lorsque vous créez le cluster.
## Création d'un cluster avec HBase
Le tableau suivant répertorie les options disponibles lorsque vous utilisez la console pour créer un cluster à HBase l'aide d'une version publiée de l'AMI Amazon EMR.
| Champ | Action |
| --- | --- |
| Restore from backup (Rétablir à partir d'une sauvegarde) | Spécifiez s'il faut précharger le HBase cluster avec les données stockées dans Amazon S3. |
| Backup location (Emplacement de sauvegarde) | Spécifiez l'URI où la sauvegarde à restaurer réside dans Amazon S3. |
| Backup version (Version de sauvegarde) | Éventuellement, spécifiez le nom de version de la sauvegarde dans Backup Location (Emplacement de sauvegarde) à utiliser. Si vous laissez ce champ vide, Amazon EMR utilise la dernière sauvegarde de Backup Location pour remplir le nouveau cluster. HBase |
| Schedule Regular Backups (Planifier des sauvegardes régulières) | Spécifiez s'il convient de planifier des sauvegardes incrémentielles automatiques. La première sauvegarde est une sauvegarde complète pour créer une référence pour les futures sauvegardes incrémentielles. |
| Consistent backup (Sauvegarde uniforme) | Spécifiez si les sauvegardes doivent être cohérentes. Une sauvegarde cohérente est une sauvegarde qui interrompt les opérations d'écriture au cours de la phase initiale de sauvegarde, pour la synchronisation entre les nœuds. Les éventuelles opérations d'écriture ainsi interrompues sont placées dans une file d'attente et reprises lorsque la synchronisation est terminée. |
| Backup frequency (Fréquence de sauvegarde) | Nombre de sauvegardes planifiées days/hours/minutes entre deux. |
| Backup location (Emplacement de sauvegarde) | L'URI Amazon S3 où les sauvegardes sont stockées. L'emplacement de sauvegarde de chaque HBase cluster doit être différent pour garantir que les sauvegardes différentielles restent correctes. |
| Backup start time (Heure de début de sauvegarde) | Spécifiez quand la première sauvegarde doit avoir lieu. Vous pouvez spécifier now, ce qui entraîne le commencement de la première sauvegarde lorsque le cluster est en cours d'exécution, ou saisir une date et une heure dans [ISO format](http://www.w3.org/TR/NOTE-datetime). Par exemple, 2012-06-15T20:00Z définit la date et l'heure de début sur le 15 juin 2012 à 20 h 00 UTC. |
L'exemple de AWS CLI commande suivant lance un cluster avec HBase d'autres applications :
**Note**
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr create-cluster --name "Test cluster" --ami-version 3.3 \
--applications Name=Hue Name=Hive Name=Pig Name=HBase \
--use-default-roles --ec2-attributes KeyName=myKey \
--instance-type c1.xlarge --instance-count 3 --termination-protected
```
Une fois la connexion établie entre le Hive et les HBase clusters (comme indiqué dans la procédure précédente), vous pouvez accéder aux données stockées sur le HBase cluster en créant une table externe dans Hive.
L'exemple suivant, lorsqu'il est exécuté à partir de l'invite Hive, crée une table externe qui fait référence aux données stockées dans une HBase table appelée`inputTable`. Vous pouvez ensuite faire référence `inputTable` dans les instructions Hive pour interroger et modifier les données stockées dans le HBase cluster.
**Note**
L'exemple suivant utilise **protobuf-java-2.4.0a.jar** dans AMI 2.3.3, mais vous devez modifier l'exemple pour qu'il corresponde à votre version. Pour vérifier quelle version du fichier JAR de tampons de protocole vous avez, exécutez la commande à l'invite de commande Hive : `! ls /home/hadoop/lib;`.
```
add jar lib/emr-metrics-1.0.jar ;
add jar lib/protobuf-java-2.4.0a.jar ;
set hbase.zookeeper.quorum=ec2-107-21-163-157.compute-1.amazonaws.com ;
create external table inputTable (key string, value string)
stored by 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'
with serdeproperties ("hbase.columns.mapping" = ":key,f1:col1")
tblproperties ("hbase.table.name" = "t1");
select count(*) from inputTable ;
```
## Personnalisation de la configuration HBase
Bien que les paramètres par défaut devraient fonctionner pour la plupart des applications, vous avez la possibilité de modifier vos paramètres HBase de configuration. Pour ce faire, exécutez l'un des deux scripts d'action d'amorçage :
+ **configure-hbase-daemons**—Configure les propriétés des démons master, regionserver et zookeeper. Ces propriétés incluent la taille du segment de mémoire et les options à transmettre à la machine virtuelle Java (JVM) au démarrage du HBase démon. Vous définissez ces propriétés en tant qu'arguments dans l'action d'amorçage. Cette action d'amorçage modifie le fichier de configuration/home/hadoop/conf/hbase-user-env.sh sur le HBase cluster.
+ **configure-hbase** —Configure les paramètres HBase spécifiques au site, tels que le port auquel le HBase maître doit se lier et le nombre maximal de fois que le client CLI du client doit réessayer une action. Vous pouvez les one-by-one définir en tant qu'arguments dans l'action bootstrap, ou vous pouvez spécifier l'emplacement d'un fichier de configuration XML dans Amazon S3. Cette action d'amorçage modifie le fichier de configuration/home/hadoop/conf/hbase-site.xml sur le HBase cluster.
**Note**
Ces scripts, comme les autres actions d'amorçage, ne peuvent être exécutés que lorsque le cluster est créé ; vous ne pouvez pas les utiliser pour modifier la configuration d'un HBase cluster en cours d'exécution.
Lorsque vous exécutez les actions **configure-hbase** ou **configure-hbase-daemons**bootstrap, les valeurs que vous spécifiez remplacent les valeurs par défaut. Toutes les valeurs que vous ne définissez pas explicitement reçoivent les valeurs par défaut.
La configuration HBase à l'aide de ces actions d'amorçage est analogue à l'utilisation d'actions de démarrage dans Amazon EMR pour configurer les paramètres Hadoop et les propriétés du démon Hadoop. La différence est qu'il HBase n'y a pas d'options de mémoire par processus. Au lieu de cela, les options de mémoire sont définies à l'aide de l'`--daemon-opts`argument, qui *daemon* est remplacé par le nom du démon à configurer.
### Configurer les HBase démons
Amazon EMR fournit une action de démarrage que vous pouvez utiliser pour modifier la configuration des HBase démons, en indiquant la région dans laquelle vous lancez votre cluster. `s3://region.elasticmapreduce/bootstrap-actions/configure-hbase-daemons` *region* HBase
Pour configurer HBase des démons à l'aide de AWS CLI, ajoutez l'action `configure-hbase-daemons` bootstrap lorsque vous lancez le cluster afin de configurer un ou plusieurs démons. HBase Vous pouvez définir les propriétés suivantes :
| Propriété | Description |
| --- | --- |
| hbase-master-opts | Options qui contrôlent la façon dont la machine virtuelle Java exécute le démon maître. Si elles sont définies, elles remplacent les variables HBASE\$1MASTER\$1OPTS par défaut. |
| regionserver-opts | Options qui contrôlent la façon dont la machine virtuelle Java exécute le démon de serveur de région. Si elles sont définies, elles remplacent les variables HBASE\$1REGIONSERVER\$1OPTS par défaut. |
| zookeeper-opts | Options qui contrôlent la façon dont la machine virtuelle Java exécute le démon zookeeper. Si elles sont définies, elles remplacent les variables HBASE\$1ZOOKEEPER\$1OPTS par défaut. |
Pour plus d'informations sur ces options, consultez le [fichier hbase-env.sh](https://hbase.apache.org/book.html#hbase.env.sh) dans la HBase documentation.
Une action d'amorçage permettant de configurer les valeurs de `zookeeper-opts` et `hbase-master-opts` est illustrée dans l'exemple suivant.
**Note**
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr create-cluster --name "Test cluster" --ami-version 3.3 \
--applications Name=Hue Name=Hive Name=Pig Name=HBase \
--use-default-roles --ec2-attributes KeyName=myKey \
--instance-type c1.xlarge --instance-count 3 --termination-protected \
--bootstrap-actions Path=s3://elasticmapreduce/bootstrap-actions/configure-hbase-daemons,\
Args=["--hbase-zookeeper-opts=-Xmx1024m -XX:GCTimeRatio=19","--hbase-master-opts=-Xmx2048m","--hbase-regionserver-opts=-Xmx4096m"]
```
### Configuration des paramètres HBase du site
Amazon EMR fournit une action de démarrage que vous pouvez utiliser pour modifier la configuration de. `s3://elasticmapreduce/bootstrap-actions/configure-hbase` HBase Vous pouvez définir des valeurs de configuration one-by-one, comme arguments dans l'action bootstrap, ou vous pouvez spécifier l'emplacement d'un fichier de configuration XML dans Amazon S3. La définition de valeurs de configuration one-by-one est utile si vous n'avez besoin de définir que quelques paramètres de configuration. Leur définition à l'aide d'un fichier XML est utile si vous avez beaucoup de modifications à apporter, ou si vous souhaitez enregistrer vos paramètres de configuration en vue de les réutiliser.
**Note**
Vous pouvez préfixer le nom du compartiment Amazon S3 par un préfixe de région`s3://region.elasticmapreduce/bootstrap-actions/configure-hbase`, tel que « où se *region* trouve la région dans laquelle vous lancez votre HBase cluster ».
Cette action d'amorçage modifie le fichier `/home/hadoop/conf/hbase-site.xml` de configuration du HBase cluster. L'action bootstrap ne peut être exécutée que lorsque le HBase cluster est lancé.
Pour plus d'informations sur les paramètres du HBase site que vous pouvez configurer, consultez la section [Configuration par défaut](http://hbase.apache.org/book.html#config.files) dans la HBase documentation.
Définissez l'action `configure-hbase` bootstrap lorsque vous lancez le HBase cluster et spécifiez les valeurs `hbase-site.xml` à modifier.
**Pour définir les paramètres individuels HBase du site à l'aide du AWS CLI**
+ Pour modifier le `hbase.hregion.max.filesize` paramètre, tapez la commande suivante et remplacez-la *myKey* par le nom de votre paire de clés Amazon EC2.
**Note**
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr create-cluster --name "Test cluster" --ami-version 3.3 \
--applications Name=Hue Name=Hive Name=Pig Name=HBase \
--use-default-roles --ec2-attributes KeyName=myKey \
--instance-type c1.xlarge --instance-count 3 --termination-protected \
--bootstrap-actions Path=s3://elasticmapreduce/bootstrap-actions/configure-hbase,Args=["-s","hbase.hregion.max.filesize=52428800"]
```
**Pour définir les paramètres HBase du site à l'aide d'un fichier XML à l'aide du AWS CLI**
1. Créez une version personnalisée de `hbase-site.xml`. Votre fichier personnalisé doit être un fichier XML valide. Pour réduire le risque d'introduction d'erreurs, commencez par la copie par défaut de`hbase-site.xml`, située sur le nœud HBase principal Amazon EMR à l'adresse`/home/hadoop/conf/hbase-site.xml`, et modifiez une copie de ce fichier au lieu de créer un fichier à partir de zéro. Vous pouvez donner un nouveau nom à votre nouveau fichier ou conserver le nom `hbase-site.xml`.
1. Chargez votre fichier `hbase-site.xml` personnalisé sur un compartiment Amazon S3. Les autorisations doivent être définies pour que le AWS compte qui lance le cluster puisse accéder au fichier. Si le AWS compte qui lance le cluster possède également le compartiment Amazon S3, il y a accès.
1. Définissez l'action de démarrage **configure-hbase** lorsque vous lancez le HBase cluster et incluez l'emplacement de votre fichier personnalisé. `hbase-site.xml` L'exemple suivant définit les valeurs de configuration du HBase site selon celles spécifiées dans le fichier`s3://amzn-s3-demo-bucket/my-hbase-site.xml`. Tapez la commande suivante, *myKey* remplacez-la par le nom de votre paire de clés EC2 et remplacez-la *amzn-s3-demo-bucket* par le nom de votre compartiment Amazon S3.
**Note**
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr create-cluster --name "Test cluster" --ami-version 3.3 \
--applications Name=Hue Name=Hive Name=Pig Name=HBase \
--use-default-roles --ec2-attributes KeyName=myKey \
--instance-type c1.xlarge --instance-count 3 --termination-protected \
--bootstrap-actions Path=s3://elasticmapreduce/bootstrap-actions/configure-hbase,Args=["--site-config-file","s3://amzn-s3-demo-bucket/config.xml"]
```
Si vous spécifiez plusieurs options pour personnaliser le HBase fonctionnement, vous devez ajouter un commutateur d'`-s`options à chaque paire clé-valeur, comme indiqué dans l'exemple suivant :
```
--bootstrap-actions s3://elasticmapreduce/bootstrap-actions/configure-hbase,Args=["-s","zookeeper.session.timeout=60000"]
```
Une fois le proxy défini et la connexion SSH ouverte, vous pouvez afficher l' HBase interface utilisateur en ouvrant une fenêtre de navigateur avec http : //:60010/master-status*master-public-dns-name*, où se trouve *master-public-dns-name* l'adresse DNS publique du nœud maître du cluster. HBase
Vous pouvez consulter les HBase journaux actuels en utilisant SSH pour vous connecter au nœud principal et en accédant au `mnt/var/log/hbase` répertoire. Ces journaux ne sont pas disponibles une fois que le cluster a été arrêté sauf si vous activez la journalisation dans Amazon S3 lorsque le cluster est lancé.
## Sauvegarder et restaurer HBase
Amazon EMR permet de sauvegarder vos HBase données sur Amazon S3, soit manuellement, soit selon un calendrier automatisé. Vous pouvez effectuer des sauvegardes complètes et incrémentielles. Une fois que vous disposez d'une version sauvegardée des HBase données, vous pouvez restaurer cette version dans un HBase cluster. Vous pouvez effectuer une restauration sur un HBase cluster en cours d'exécution ou lancer un nouveau cluster prérempli de données sauvegardées.
Pendant le processus de sauvegarde, HBase continue d'exécuter les commandes d'écriture. Cela garantit la disponibilité du cluster tout au long de la sauvegarde, mais cela entraîne un risque d'incohérence entre les données en cours de sauvegarde et les éventuelles opérations d'écriture en cours d'exécution en parallèle. Pour comprendre les incohérences qui peuvent survenir, vous devez tenir compte du fait que les opérations d' HBase écriture sont réparties entre les nœuds de son cluster. Si une opération d'écriture se produit après qu'un nœud particulier a été interrogé, ces données ne sont pas incluses dans l'archive de sauvegarde. Vous pouvez même constater que les écritures antérieures sur le HBase cluster (envoyées à un nœud qui a déjà été interrogé) ne figurent peut-être pas dans l'archive de sauvegarde, alors que les écritures ultérieures (envoyées à un nœud avant qu'il ne soit interrogé) sont incluses.
Si une sauvegarde cohérente est requise, vous devez suspendre les écritures HBase pendant la partie initiale du processus de sauvegarde, c'est-à-dire la synchronisation entre les nœuds. Pour cela, vous pouvez spécifier le paramètre `--consistent` lorsque vous demandez une sauvegarde. Avec ce paramètre, les écritures intervenant au cours de cette période sont mises en file d'attente et exécutées dès que la synchronisation se termine. Vous pouvez également planifier des sauvegardes récurrentes, ce qui résout les incohérences au fil du temps, car les données qui manquent dans un cycle de sauvegarde sont sauvegardées lors du cycle suivant.
Lorsque vous sauvegardez HBase des données, vous devez spécifier un répertoire de sauvegarde différent pour chaque cluster. Un moyen simple pour cela consiste à utiliser l'identifiant du cluster dans le chemin d'accès spécifié pour le répertoire de sauvegarde. Par exemple, `s3://amzn-s3-demo-bucket/backups/j-3AEXXXXXX16F2`. Cela garantit que toutes les futures sauvegardes incrémentielles font référence au HBase cluster approprié.
Lorsque vous êtes prêt à supprimer les anciens fichiers de sauvegarde devenus inutiles, nous vous recommandons d'effectuer d'abord une sauvegarde complète de vos HBase données. Ceci garantit la conservation de toutes les données et fournit un point de départ pour les futures sauvegardes incrémentielles. Une fois la sauvegarde complète terminée, vous pouvez accédez à l'emplacement de sauvegarde et supprimer manuellement les anciens fichiers de sauvegarde.
Le processus HBase de sauvegarde utilise S3 DistCp pour l'opération de copie, qui comporte certaines limites concernant l'espace de stockage temporaire des fichiers.
### Sauvegarde et restauration à HBase l'aide de la console
La console permet de lancer un nouveau cluster et de le remplir avec les données d'une HBase sauvegarde précédente. Il vous permet également de planifier des sauvegardes incrémentielles périodiques des HBase données. Des fonctionnalités de sauvegarde et de restauration supplémentaires sont disponibles via l'interface de ligne de commande, telles que la possibilité de restaurer les données dans un cluster déjà en cours d'exécution, d'effectuer des sauvegardes manuelles et de planifier des sauvegardes complètes automatisées.
**Pour remplir un nouveau cluster avec des HBase données archivées à l'aide de la console**
1. Accédez à la nouvelle console Amazon EMR et sélectionnez **Changer pour l'ancienne console** depuis le menu latéral. Pour plus d'informations sur ce qu'implique le passage à l'ancienne console, consultez la rubrique [Utilisation de l'ancienne console](https://docs.aws.amazon.com/emr/latest/ManagementGuide/whats-new-in-console.html#console-opt-in).
1. Choisissez **Créer un cluster**.
1. Dans la section **Configuration logicielle**, pour **Applications supplémentaires**, sélectionnez **Configurer **HBase**et ajouter**.
1. Dans la boîte de dialogue **Add Application (Ajouter une application)**, cochez **Restore From Backup (Restituer à partir d'une sauvegarde)**.
1. Pour **Backup Location**, spécifiez l'emplacement de la sauvegarde à charger dans le nouveau HBase cluster. Il doit s'agir d'une URL Amazon S3 de la forme `s3://amzn-s3-demo-bucket/backups/`.
1. Pour **Backup Version (Version de sauvegarde)**, vous avez la possibilité de spécifier le nom d'une version de sauvegarde à charger en définissant une valeur. Si vous ne définissez pas de valeur pour **Version de sauvegarde**, Amazon EMR charge la dernière sauvegarde à l'emplacement spécifié.
1. Choisissez **Ajouter**, puis créez le cluster avec d'autres options, si vous le souhaitez.
**Pour planifier des sauvegardes automatisées des HBase données à l'aide de la console**
1. Dans la section **Configuration logicielle**, pour **Applications supplémentaires**, sélectionnez **Configurer **HBase**et ajouter**.
1. Choisissez **Schedule Regular Backups (Planifier des sauvegardes régulières)**.
1. Spécifiez si les sauvegardes doivent être cohérentes. Une sauvegarde cohérente est une sauvegarde qui interrompt les opérations d'écriture au cours de la phase initiale de sauvegarde, pour la synchronisation entre les nœuds. Les éventuelles opérations d'écriture ainsi interrompues sont placées dans une file d'attente et reprises lorsque la synchronisation est terminée.
1. Définissez la fréquence à laquelle les sauvegardes doivent intervenir en entrant un nombre pour **Backup Frequency (Fréquence de sauvegarde)** et en choisissant **Jours**, **Heures** ou **Minutes**. La première sauvegarde automatisée qui s'exécute est une sauvegarde complète. Après cela, Amazon EMR enregistre des sauvegardes incrémentielles basées sur la planification que vous spécifiez.
1. Spécifiez l'emplacement dans Amazon S3 où les sauvegardes doivent être stockées. Chaque HBase cluster doit être sauvegardé dans un emplacement distinct dans Amazon S3 afin de garantir que les sauvegardes incrémentielles sont correctement calculées.
1. Spécifiez quand la première sauvegarde doit intervenir en définissant une valeur pour **Backup Start Time (Heure de début de sauvegarde)**. Vous pouvez spécifier `now`, ce qui entraîne le commencement de la première sauvegarde lorsque le cluster est en cours d'exécution, ou saisir une date et une heure dans [ISO format](http://www.w3.org/TR/NOTE-datetime). Par exemple, 2013-09-26T20:00Z, définit la date et l'heure de début sur 26 septembre 2013 à 20 h 00 UTC.
1. Choisissez **Ajouter**.
1. Procédez à la création du cluster avec d'autres options, si vous le souhaitez.
## Moniteur HBase avec CloudWatch
Amazon EMR indique trois indicateurs CloudWatch que vous pouvez utiliser pour surveiller vos HBase sauvegardes. Ces mesures sont poussées CloudWatch à des intervalles de cinq minutes et sont fournies gratuitement.
| Métrique | Description |
| --- | --- |
| HBaseBackupFailed | Si la dernière sauvegarde a échoué. La valeur est définie sur 0 par défaut et mise à jour sur 1 en cas d'échec de la tentative de sauvegarde précédente. Cette métrique n'est signalée que pour les HBase clusters. Cas d'utilisation : surveiller les HBase sauvegardes Unités : *nombre* |
| HBaseMostRecentBackupDuration | Délai nécessaire à l'exécution de la précédente sauvegarde. Cette métrique est définie même si la dernière sauvegarde a réussi ou a échoué. Lorsque la sauvegarde est en cours, cette métrique retourne le nombre de minutes qui se sont écoulées depuis le démarrage de la sauvegarde. Cette métrique n'est signalée que pour les HBase clusters. Cas d'utilisation : Surveiller les HBase sauvegardes Unités : *minutes* |
| HBaseTimeSinceLastSuccessfulBackup | Nombre de minutes écoulées après le démarrage de la dernière HBase sauvegarde réussie sur votre cluster. Cette métrique n'est signalée que pour les HBase clusters. Cas d'utilisation : surveiller les HBase sauvegardes Unités : *minutes* |
## Configurer Ganglia pour HBase
Vous configurez Ganglia pour HBase utiliser l'action **configure-hbase-for-ganglia**bootstrap. Cette action de bootstrap est configurée HBase pour publier des métriques sur Ganglia.
Vous devez configurer HBase et Ganglia lorsque vous lancez le cluster ; les rapports Ganglia ne peuvent pas être ajoutés à un cluster en cours d'exécution.
Ganglia stocke également les fichiers journaux sur le serveur à l'adresse `/mnt/var/log/ganglia/rrds`. Si vous avez configuré votre cluster pour conserver les fichiers journaux dans un compartiment Amazon S3, les fichiers journaux Ganglia y sont conservés également.
Pour lancer un cluster avec Ganglia for HBase, utilisez l'action **configure-hbase-for-ganglia**bootstrap comme indiqué dans l'exemple suivant.
**Note**
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr create-cluster --name "Test cluster" --ami-version 3.3 \
--applications Name=Hue Name=Hive Name=Pig Name=HBase Name=Ganglia \
--use-default-roles --ec2-attributes KeyName=myKey \
--instance-type c1.xlarge --instance-count 3 --termination-protected \
--bootstrap-actions Path=s3://elasticmapreduce/bootstrap-actions/configure-hbase-for-ganglia
```
Une fois que le cluster a été lancé et Ganglia configuré, vous pouvez accéder aux graphiques et rapports Ganglia à l'aide de l'interface graphique en cours d'exécution sur le nœud maître.
# Caractéristiques de l'application Pig pour les versions AMI antérieures d'Amazon EMR
## Versions de Pig prises en charge
La version de Pig que vous pouvez ajouter à votre cluster dépend de la version d'AMI Amazon EMR et de la version de Hadoop que vous utilisez. Le tableau ci-dessous montre les versions d'AMI et les versions de Hadoop compatibles avec les différentes versions de Pig. Nous recommandons d'utiliser la dernière version de Pig disponible pour tirer parti des améliorations de performances et des nouvelles fonctionnalités.
Lorsque vous utilisez l'API pour installer Pig, la version par défaut est utilisée, sauf si vous spécifiez `--pig-versions` comme argument l'étape qui charge Pig sur le cluster lors de l'appel à [RunJobFlow](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_RunJobFlow.html).
| Version de Pig | Version d'AMI | Paramètres de configuration | Détails de la version de Pig |
| --- | --- | --- | --- |
| 0.12.0[Notes de mise à jour](http://pig.apache.org/releases.html#14+October%2C+2013%3A+release+0.12.0+available)[Documentation](http://pig.apache.org/docs/r0.12.0/) | 3.1.0 et ultérieures | `--ami-version 3.1` `--ami-version 3.2` `--ami-version 3.3` | Ajoute la prise en charge des éléments suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/emr/latest/ReleaseGuide/emr-3x-pig.html) |
| 0.11.1.1[Notes de mise à jour](http://pig.apache.org/releases.html#1+April%2C+2013%3A+release+0.11.1+available)[Documentation](http://pig.apache.org/docs/r0.11.1/) | 2.2 et ultérieures | `--pig-versions 0.11.1.1` `--ami-version 2.2` | Améliore les performances de la commande LOAD PigStorage si l'entrée réside dans Amazon S3. |
| 0.11.1[Notes de mise à jour](http://pig.apache.org/releases.html#1+April%2C+2013%3A+release+0.11.1+available)[Documentation](http://pig.apache.org/docs/r0.11.1/) | 2.2 et ultérieures | `--pig-versions 0.11.1` `--ami-version 2.2` | Ajoute la prise en charge du JDK 7, de Hadoop 2, des fonctions définies par l'utilisateur de Groovy, de l' SchemaTuple optimisation, des nouveaux opérateurs, etc. Pour plus d'informations, consultez [Journal de modifications Pig 0.11.1](http://svn.apache.org/repos/asf/pig/tags/release-0.11.1/CHANGES.txt). |
| 0.9.2.2[Notes de mise à jour](http://pig.apache.org/releases.html#22+January%2C+2012%3A+release+0.9.2+available)[Documentation](http://pig.apache.org/docs/r0.9.2/index.html) | 2.2 et ultérieures | `--pig-versions 0.9.2.2` `--ami-version 2.2` | Ajoute une prise en charge pour Hadoop 1.0.3. |
| 0.9.2.1[Notes de mise à jour](http://pig.apache.org/releases.html#22+January%2C+2012%3A+release+0.9.2+available)[Documentation](http://pig.apache.org/docs/r0.9.2/index.html) | 2.2 et ultérieures | `--pig-versions 0.9.2.1` `--ami-version 2.2` | Ajoute la prise en charge de MapR. |
| 0.9.2[Notes de mise à jour](http://pig.apache.org/releases.html#22+January%2C+2012%3A+release+0.9.2+available)[Documentation](http://pig.apache.org/docs/r0.9.2/index.html) | 2.2 et ultérieures | `--pig-versions 0.9.2` `--ami-version 2.2` | Inclut plusieurs améliorations de performances et correctifs. Pour obtenir des informations détaillées sur les modifications apportées dans la version Pig 0.9.2, consultez [Journal de modifications Pig 0.9.2](http://svn.apache.org/repos/asf/pig/tags/release-0.9.2/CHANGES.txt). |
| 0.9.1[Notes de mise à jour](http://pig.apache.org/releases.html#5+October%2C+2011%3A+release+0.9.1+available)[Documentation](http://pig.apache.org/docs/r0.9.1/) | 2.0 | `--pig-versions 0.9.1` `--ami-version 2.0` |
| 0.6[Notes de mise à jour](http://pig.apache.org/releases.html#1+March%2C+2010%3A+release+0.6.0+available) | 1.0 | `--pig-versions 0.6` `--ami-version 1.0` |
| 0.3[Notes de mise à jour](http://pig.apache.org/releases.html#25+June%2C+2009%3A+release+0.3.0+available) | 1.0 | `--pig-versions 0.3` `--ami-version 1.0` |
## Détails de la version de Pig
Amazon EMR prend en charge certaines versions de Pig auxquelles des correctifs Amazon EMR supplémentaires sont appliqués. Vous pouvez configurer la version de Pig à exécuter sur les clusters Amazon EMR. Pour plus d'informations sur cette étape, consultez [Apache Pig](emr-pig.md). Les sections suivantes décrivent les différentes versions de Pig et les correctifs appliqués aux versions chargées sur Amazon EMR.
### Correctifs Pig
Cette section décrit les correctifs personnalisés appliqués aux versions de Pig disponibles avec Amazon EMR.
#### Correctifs Pig 0.11.1.1
La version Amazon EMR de Pig 0.11.1.1 est une version de maintenance qui améliore les performances de la commande LOAD PigStorage si l'entrée réside dans Amazon S3.
#### Correctifs Pig 0.11.1
La version Amazon EMR de Pig 0.11.1 contient toutes les mises à jour fournies par l'Apache Software Foundation et les correctifs Amazon EMR cumulés depuis la version Pig 0.9.2.2. Il n'y a cependant pas de nouveaux correctifs spécifiques à Amazon EMR dans Pig 0.11.1.
#### Correctifs Pig 0.9.2
Apache Pig 0.9.2 est une version de maintenance de Pig. L'équipe Amazon EMR a appliqué les correctifs suivants à la version Amazon EMR de Pig 0.9.2.
| Correctif | Description |
| --- | --- |
| PIG-1429 | Ajout du type de données Boolean à Pig en tant que type de données de première classe. Pour plus d'informations, rendez-vous sur [https://issues.apache. org/jira/browse/PIG-1429](https://issues.apache.org/jira/browse/PIG-1429). **Statut :** validé **Correction dans la version Apache Pig :** 0.10 |
| PIG-1824 | Prise en charge des modules d'importation dans Jython UDF. Pour plus d'informations, rendez-vous sur [https://issues.apache. org/jira/browse/PIG-1824](https://issues.apache.org/jira/browse/PIG-1824). **Statut :** validé **Correction dans la version Apache Pig :** 0.10 |
| PIG-2010 | JARs Bundle enregistré dans le cache distribué. Pour plus d'informations, rendez-vous sur [https://issues.apache. org/jira/browse/PIG-2010.](https://issues.apache.org/jira/browse/PIG-2010) **Statut :** validé **Correction dans la version Apache Pig :** 0.11 |
| PIG-2456 | Ajout d'un fichier \$1/.pigbootup dans lequel l'utilisateur peut spécifier des déclarations Pig par défaut. Pour plus d'informations, rendez-vous sur [https://issues.apache. org/jira/browse/PIG-2456](https://issues.apache.org/jira/browse/PIG-2456). **Statut :** validé **Correction dans la version Apache Pig :** 0.11 |
| PIG-2623 | Support à l'utilisation des chemins Amazon S3 pour l'enregistrement UDFs. Pour plus d'informations, rendez-vous sur [https://issues.apache. org/jira/browse/PIG-2623](https://issues.apache.org/jira/browse/PIG-2623). **Statut :** validé **Correction dans les versions Apache Pig :** 0.10, 0.11 |
#### Correctifs Pig 0.9.1
L'équipe Amazon EMR a appliqué les correctifs suivants à la version Amazon EMR de Pig 0.9.1.
| Correctif | Description |
| --- | --- |
| Prise en charge des fichiers JAR et des scripts Pig dans les systèmes de fichiers distribués | Ajout de la prise en charge de l'exécution de scripts et de l'enregistrement de fichiers JAR stockés dans HDFS, Amazon S3 ou d'autres systèmes de fichiers distribués. Pour plus d'informations, rendez-vous sur [https://issues.apache. org/jira/browse/PIG-1505](https://issues.apache.org/jira/browse/PIG-1505). **Statut :** validé **Correction dans la version Apache Pig :** 0.8.0 |
| Prise en charge de plusieurs systèmes de fichiers dans Pig | Ajout de la prise en charge des scripts Pig pour lire les données d'un système de fichiers et les écrire dans un autre. Pour plus d'informations, rendez-vous sur [https://issues.apache. org/jira/browse/PIG-1564](https://issues.apache.org/jira/browse/PIG-1564). **Statut :** non validé **Correction dans la version Apache Pig :** non applicable |
| Ajouter la date, l'heure et la chaîne de caractères de Piggybank UDFs | Ajoutez la date, l'heure et la chaîne UDFs pour prendre en charge les scripts Pig personnalisés. Pour plus d'informations, rendez-vous sur [https://issues.apache. org/jira/browse/PIG-1565](https://issues.apache.org/jira/browse/PIG-1565). **Statut :** non validé **Correction dans la version Apache Pig :** non applicable |
## Clusters Pig en mode interactif ou en mode de traitement par lots
Amazon EMR vous permet d'exécuter des scripts Pig dans deux modes :
+ Interactive
+ Par lots
Lorsque vous lancez un cluster de longue durée à l'aide de la console ou du AWS CLI, vous pouvez vous connecter au nœud principal **ssh** en tant qu'utilisateur Hadoop et utiliser le shell Grunt pour développer et exécuter vos scripts Pig de manière interactive. Utiliser Pig de façon interactive vous permet de réviser plus facilement le script Pig qu'en mode de traitement par lots. Lorsque vous avez révisé le script Pig en mode interactif et que tout est correct, vous pouvez charger le script sur Amazon S3 et utiliser le mode de traitement par lots pour exécuter le script en production. Vous pouvez également soumettre des commandes Pig de façon interactive sur un cluster en cours d'exécution pour analyser et transformer les données en fonction des besoins.
En mode de traitement par lots, vous chargez votre script Pig sur Amazon S3, puis soumettez le travail au cluster dans le cadre d'une étape. Les étapes Pig peuvent être soumises à un cluster de longue durée ou à un cluster transitoire.
# Caractéristiques de l'application Spark pour les versions AMI antérieures d'Amazon EMR
## Utilisation interactive de Spark ou en mode de traitement par lots
Amazon EMR vous permet d'exécuter des applications Spark dans deux modes :
+ Interactive
+ Par lots
Lorsque vous lancez un cluster de longue durée à l'aide de la console ou du AWS CLI, vous pouvez vous connecter via SSH au nœud principal en tant qu'utilisateur Hadoop et utiliser le shell Spark pour développer et exécuter vos applications Spark de manière interactive. L'utilisation de Spark vous permet de façon interactive de créer un prototype ou de tester les applications Spark plus facilement que dans un environnement de traitement par lots. Après avoir révisé avec succès l'application Spark en mode interactif, vous pouvez placer le programme JAR ou Python de cette application dans le système de fichiers local du nœud principal du cluster sur Amazon S3. Vous pouvez alors soumettre l'application en tant que flux de travail de traitement par lots.
En mode de traitement par lots, chargez votre script Spark sur Amazon S3 ou le système de fichiers local du nœud principal, puis soumettez le travail au cluster en tant qu'étape. Les étapes Spark peuvent être soumises à un cluster de longue durée ou à un cluster transitoire.
## Création d'un cluster avec Spark installé
**Pour lancer un cluster avec Spark installé à l'aide de la console**
1. Accédez à la nouvelle console Amazon EMR et sélectionnez **Changer pour l'ancienne console** depuis le menu latéral. Pour plus d'informations sur ce qu'implique le passage à l'ancienne console, consultez la rubrique [Utilisation de l'ancienne console](https://docs.aws.amazon.com/emr/latest/ManagementGuide/whats-new-in-console.html#console-opt-in).
1. Choisissez **Créer un cluster**.
1. Pour **Configuration des logiciels**, choisissez la version AMI dont vous avez besoin.
1. Pour **Applications to be installed (Applications à installer)**, choisissez **Spark** dans la liste, puis choisissez **Configurer et ajouter**.
1. Ajoutez des arguments pour modifier la configuration de Spark comme vous le souhaitez. Pour de plus amples informations, veuillez consulter [Configuration de Spark](#emr-3x-spark-configure). Choisissez **Ajouter**.
1. Sélectionnez d'autres options si nécessaire, puis choisissez **Create cluster (Créer le cluster)**.
L'exemple suivant montre comment créer un cluster avec Spark au moyen de Java :
```
AmazonElasticMapReduceClient emr = new AmazonElasticMapReduceClient(credentials);
SupportedProductConfig sparkConfig = new SupportedProductConfig()
.withName("Spark");
RunJobFlowRequest request = new RunJobFlowRequest()
.withName("Spark Cluster")
.withAmiVersion("3.11.0")
.withNewSupportedProducts(sparkConfig)
.withInstances(new JobFlowInstancesConfig()
.withEc2KeyName("myKeyName")
.withInstanceCount(1)
.withKeepJobFlowAliveWhenNoSteps(true)
.withMasterInstanceType("m3.xlarge")
.withSlaveInstanceType("m3.xlarge")
);
RunJobFlowResult result = emr.runJobFlow(request);
```
## Configuration de Spark
Vous configurez Spark lorsque vous créez un cluster en exécutant l'action bootstrap située dans le [awslabs/emr-bootstrap-actions/sparkréférentiel sur Github](https://github.com/awslabs/emr-bootstrap-actions/tree/master/spark). Pour savoir quels arguments sont acceptés par l'action d'amorçage, consultez le fichier [README](https://github.com/aws-samples/emr-bootstrap-actions/blob/master/spark/examples/README.md)dans ce référentiel. L'action d'amorçage configure les propriétés dans le fichier `$SPARK_CONF_DIR/spark-defaults.conf`. Pour plus d'informations sur les paramètres, consultez la rubrique Spark Configuration dans la documentation Spark. Vous pouvez remplacer « latest » dans l'URL suivante avec le numéro de la version de Spark que vous installez, par exemple, `2.2.0` [http://spark.apache.org/docs/latest/configuration.html](http://spark.apache.org/docs/latest/configuration.html).
Vous pouvez également configurer Spark dynamiquement au moment de l'envoi de chaque application. Un paramètre permettant d'optimiser automatiquement l'allocation de ressources pour un exécuteur est disponible dans le fichier de configuration `spark`. Pour de plus amples informations, veuillez consulter [Remplacement des paramètres de configuration par défaut de Spark](#emr-3x-spark-dynamic-configuration).
### Modification des paramètres Spark par défaut
L'exemple suivant montre comment créer un cluster avec `spark.executor.memory` défini sur 2G au moyen de l' AWS CLI.
**Note**
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr create-cluster --name "Spark cluster" --ami-version 3.11.0 \
--applications Name=Spark, Args=[-d,spark.executor.memory=2G] --ec2-attributes KeyName=myKey \
--instance-type m3.xlarge --instance-count 3 --use-default-roles
```
### Soumission d'un travail à Spark
Pour soumettre du travail à un cluster, utilisez une étape pour exécuter le script `spark-submit` sur votre cluster EMR. Ajoutez l'étape en utilisant la `addJobFlowSteps` méthode dans [AmazonElasticMapReduceClient](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/elasticmapreduce/AmazonElasticMapReduceClient.html):
```
AWSCredentials credentials = new BasicAWSCredentials(accessKey, secretKey);
AmazonElasticMapReduceClient emr = new AmazonElasticMapReduceClient(credentials);
StepFactory stepFactory = new StepFactory();
AddJobFlowStepsRequest req = new AddJobFlowStepsRequest();
req.withJobFlowId("j-1K48XXXXXXHCB");
List stepConfigs = new ArrayList();
StepConfig sparkStep = new StepConfig()
.withName("Spark Step")
.withActionOnFailure("CONTINUE")
.withHadoopJarStep(stepFactory.newScriptRunnerStep("/home/hadoop/spark/bin/spark-submit","--class","org.apache.spark.examples.SparkPi","/home/hadoop/spark/lib/spark-examples-1.3.1-hadoop2.4.0.jar","10"));
stepConfigs.add(sparkStep);
req.withSteps(stepConfigs);
AddJobFlowStepsResult result = emr.addJobFlowSteps(req);
```
### Remplacement des paramètres de configuration par défaut de Spark
Vous souhaiterez probablement remplacer les valeurs de configuration par défaut de Spark indépendamment pour chaque application. Vous pouvez faire cela lorsque vous soumettez des applications à l'aide d'une étape, ce qui transmet essentiellement des options à `spark-submit`. Par exemple, vous pouvez changer la mémoire allouée à un processus d'exécuteur en modifiant `spark.executor.memory`. Vous pouvez fournir le commutateur `--executor-memory` avec un argument tel que :
```
/home/hadoop/spark/bin/spark-submit --executor-memory 1g --class org.apache.spark.examples.SparkPi /home/hadoop/spark/lib/spark-examples*.jar 10
```
De même, vous pouvez ajuster `--executor-cores` et `--driver-memory`. Dans une étape, vous pouvez fournir les arguments suivants à l'étape :
```
--executor-memory 1g --class org.apache.spark.examples.SparkPi /home/hadoop/spark/lib/spark-examples*.jar 10
```
Vous pouvez également ajuster les paramètres qui n'ont peut-être pas de commutateur intégré à l'aide de l'option `--conf`. Pour plus d'informations sur les autres paramètres ajustables, consultez la rubrique [Chargement dynamique de propriétés Spark](https://spark.apache.org/docs/latest/configuration.html#dynamically-loading-spark-properties) dans la documentation Apache Spark.
# Différences entre l'DistCp utilitaire S3 et les versions antérieures de l'AMI d'Amazon EMR
## DistCp Versions S3 prises en charge dans Amazon EMR
Les DistCp versions S3 suivantes sont prises en charge dans les versions de l'AMI Amazon EMR. DistCpLes versions S3 postérieures à 1.0.7 se trouvent directement sur les clusters. Utilisez le fichier JAR dans `/home/hadoop/lib` pour bénéficier des dernières fonctions.
| Version | Description | Date de publication |
| --- | --- | --- |
| 1.0.8 | Ajoute les options --appendToLastFile, --requirePreviousManifest et --storageClass. | 3 janvier 2014 |
| 1.0.7 | Ajoute l'option --s3ServerSideEncryption. | 2 mai 2013 |
| 1.0.6 | Ajoute l'option --s3Endpoint. | 6 août 2012 |
| 1.0.5 | Améliore la capacité à spécifier la version de S3 DistCp à exécuter. | 27 juin 2012 |
| 1.0.4 | Améliore l'option --deleteOnSuccess. | 19 juin 2012 |
| 1.0.3 | Ajoute une prise en charge pour les options --numberFiles et --startingIndex. | 12 juin 2012 |
| 1.0.2 | Améliore l'affectation des noms lors de l'utilisation de groupes. | 6 juin 2012 |
| 1.0.1 | Version initiale de S3DistCp. | 19 janvier 2012 |
## Ajouter une étape de DistCp copie S3 à un cluster
Pour ajouter une étape de DistCp copie S3 à un cluster en cours d'exécution, tapez la commande suivante, *j-3GYXXXXXX9IOK* remplacez-la par votre ID de cluster et remplacez *amzn-s3-demo-bucket* par le nom de votre compartiment Amazon S3.
**Note**
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr add-steps --cluster-id j-3GYXXXXXX9IOK \
--steps Type=CUSTOM_JAR,Name="S3DistCp step",Jar=/home/hadoop/lib/emr-s3distcp-1.0.jar,\
Args=["--s3Endpoint,s3-eu-west-1.amazonaws.com",\
"--src,s3://amzn-s3-demo-bucket/logs/j-3GYXXXXXX9IOJ/node/",\
"--dest,hdfs:///output",\
"--srcPattern,.*[a-zA-Z,]+"]
```
**Example Charger CloudFront les journaux Amazon dans HDFS**
Cet exemple charge les CloudFront journaux Amazon dans HDFS en ajoutant une étape à un cluster en cours d'exécution. Au cours du processus, il modifie le format de compression de Gzip (format CloudFront par défaut) en LZO. Cela est utile, car les données compressées à l'aide de LZO peuvent être divisées en plusieurs mappages lorsqu'elles sont décompressées, si bien que vous n'avez pas à attendre la fin de la compression, comme vous le faites pour Gzip. Cela fournit de meilleures performances lorsque vous analysez les données à l'aide d'Amazon EMR. Cet exemple améliore également les performances en utilisant l'expression régulière spécifiée dans l'option `--groupBy` pour combiner tous les journaux d'une heure donnée dans un seul fichier. Les clusters Amazon EMR sont plus efficaces lors du traitement de quelques fichiers volumineux compressés LZO que lors du traitement de nombreux petits fichiers compressés au format GZIP. Pour fractionner les fichiers LZO, vous devez les indexer et utiliser la bibliothèque tierce hadoop-lzo.
Pour charger CloudFront les journaux Amazon dans HDFS, tapez la commande suivante, remplacez-la *j-3GYXXXXXX9IOK* par votre ID de cluster et remplacez par le nom *amzn-s3-demo-bucket* de votre compartiment Amazon S3.
Les caractères de continuation de ligne Linux (\$1) sont inclus pour des raisons de lisibilité. Ils peuvent être supprimés ou utilisés dans les commandes Linux. Pour Windows, supprimez-les ou remplacez-les par un caret (^).
```
aws emr add-steps --cluster-id j-3GYXXXXXX9IOK \
--steps Type=CUSTOM_JAR,Name="S3DistCp step",Jar=/home/hadoop/lib/emr-s3distcp-1.0.jar,\
Args=["--src,s3://amzn-s3-demo-bucket/cf","--dest,hdfs:///local",\
"--groupBy,.*XABCD12345678.([0-9]+-[0-9]+-[0-9]+-[0-9]+).*",\
"--targetSize,128",
"--outputCodec,lzo","--deleteOnSuccess"]
```
Considérons que l'exemple précédent est exécuté sur les fichiers journaux CloudFront suivants.
```
s3://amzn-s3-demo-bucket/cf/XABCD12345678.2012-02-23-01.HLUS3JKx.gz
s3://amzn-s3-demo-bucket/cf/XABCD12345678.2012-02-23-01.I9CNAZrg.gz
s3://amzn-s3-demo-bucket/cf/XABCD12345678.2012-02-23-02.YRRwERSA.gz
s3://amzn-s3-demo-bucket/cf/XABCD12345678.2012-02-23-02.dshVLXFE.gz
s3://amzn-s3-demo-bucket/cf/XABCD12345678.2012-02-23-02.LpLfuShd.gz
```
S3 DistCp copie, concatène et compresse les fichiers dans les deux fichiers suivants, le nom du fichier étant déterminé par la correspondance établie par l'expression régulière.
```
hdfs:///local/2012-02-23-01.lzo
hdfs:///local/2012-02-23-02.lzo
```