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.

Optimisation des performances pour les EMR opérations Amazon dans DynamoDB

EMRLes opérations Amazon sur une table DynamoDB sont considérées comme des opérations de lecture et sont soumises aux paramètres de débit provisionnés de la table. Amazon EMR met en œuvre sa propre logique pour essayer d'équilibrer la charge sur votre table DynamoDB afin de minimiser le risque de dépassement du débit alloué. À la fin de chaque requête Hive, Amazon EMR renvoie des informations sur le cluster utilisé pour traiter la requête, notamment le nombre de fois où le débit alloué a été dépassé. Vous pouvez utiliser ces informations, ainsi que CloudWatch les mesures relatives à votre débit DynamoDB, pour mieux gérer la charge sur votre table DynamoDB lors des demandes suivantes.

Les facteurs suivants influencent les performances des requêtes Hive lorsque vous travaillez avec des tables DynamoDB.

Unités de capacité de lecture allouées

Lorsque vous exécutez les requêtes Hive sur une table DynamoDB, vous devez vous assurer que vous avez alloué une quantité suffisante d'unités de capacité de lecture.

Par exemple, supposons que vous ayez provisionné 100 unités de capacité en lecture pour votre table DynamoDB. Vous pourrez ainsi effectuer 100 lectures, ou 409 600 octets, par seconde. Si cette table contient 20 Go de données (21 474 836 480 octets) et que votre requête Hive exécute une analyse complète de la table, vous pouvez estimer la durée d'exécution de la requête :

21 474 836 480 / 409 600 = 52 429 secondes = 14,56 heures

Le seul moyen de diminuer le temps nécessaire consiste à ajuster les unités de capacité de lecture sur la table DynamoDB source. L'ajout de nœuds supplémentaires au EMR cluster Amazon n'aidera pas.

Dans la sortie Hive, le pourcentage d'achèvement est mis à jour lorsqu'un ou plusieurs processus de mappeurs sont terminés. Pour une table DynamoDB volumineuse avec un paramètre de faible capacité allouée en lecture, la sortie du pourcentage d'achèvement peut ne pas être mise à jour pendant longtemps. Dans le cas décrit ci-dessus, la tâche apparaît complète à 0 % pendant plusieurs heures. Pour un état plus détaillé de l'avancement de votre tâche, rendez-vous sur la EMR console Amazon ; vous pourrez consulter le statut de chaque tâche du mappeur et les statistiques relatives aux lectures de données.

Vous pouvez également vous connecter à l'interface Hadoop sur le nœud maître et voir les statistiques Hadoop. Vous visualisez ainsi l'état des tâches de chaque carte et certaines statistiques de lecture des données. Pour plus d'informations, consultez la section Interfaces Web hébergées sur le nœud principal dans l'Amazon EMR Management Guide.

Paramètre de pourcentage de lecture

Par défaut, Amazon EMR gère la charge des demandes par rapport à votre table DynamoDB en fonction de votre débit provisionné actuel. Toutefois, lorsqu'Amazon EMR renvoie des informations relatives à votre tâche qui incluent un nombre élevé de réponses ayant dépassé le débit alloué, vous pouvez ajuster le taux de lecture par défaut à l'aide du dynamodb.throughput.read.percent paramètre lorsque vous configurez la table Hive. Pour plus d'informations sur la configuration du paramètre de pourcentage de lecture, consultez Options Hive.

Paramètre de pourcentage d'écriture

Par défaut, Amazon EMR gère la charge des demandes par rapport à votre table DynamoDB en fonction de votre débit provisionné actuel. Toutefois, lorsqu'Amazon EMR renvoie des informations relatives à votre tâche qui incluent un nombre élevé de réponses ayant dépassé le débit alloué, vous pouvez ajuster le taux d'écriture par défaut à l'aide du dynamodb.throughput.write.percent paramètre lorsque vous configurez la table Hive. Pour plus d'informations sur la configuration du paramètre de pourcentage d'écriture, consultez Options Hive.

Paramètre de durée de nouvelle tentative

Par défaut, Amazon EMR réexécute une requête Hive si elle n'a pas renvoyé de résultat dans les deux minutes, ce qui correspond à l'intervalle de tentatives par défaut. Vous pouvez ajuster cet intervalle en définissant le paramètre dynamodb.retry.duration lorsque vous exécutez une requête Hive. Pour plus d'informations sur la configuration du paramètre de pourcentage d'écriture, consultez Options Hive.

Nombre de tâches de mappage

Les démons de mappeur que Hadoop lance pour traiter vos requêtes afin d'exporter et d'interroger des données stockées dans DynamoDB sont limités à une vitesse de lecture maximale de 1 Mio par seconde afin de limiter la capacité de lecture utilisée. Si vous avez un débit alloué supplémentaire disponible sur DynamoDB, vous pouvez améliorer les performances de l'exportation Hive et des opérations d'interrogation en augmentant le nombre de démons de mappeur. Pour ce faire, vous pouvez soit augmenter le nombre d'EC2instances de votre cluster, soit augmenter le nombre de démons de mappage exécutés sur chaque instance. EC2

Vous pouvez augmenter le nombre d'EC2instances d'un cluster en arrêtant le cluster actuel et en le relançant avec un plus grand nombre d'EC2instances. Vous spécifiez le nombre d'EC2instances dans la boîte de dialogue Configurer les EC2 instances si vous lancez le cluster depuis la EMR console Amazon, ou avec l'‑‑num-instancesoption si vous lancez le cluster depuis leCLI.

Le nombre de tâches cartographiques exécutées sur une instance dépend du type d'EC2instance. Pour plus d'informations sur les types d'EC2instances pris en charge et le nombre de mappeurs fournis par chacun d'entre eux, consultezConfiguration de la tâche. Là, vous trouverez une section « Configuration des tâches » pour chacune des configurations prises en charge.

Un autre moyen d'augmenter le nombre de démons de mappeur consiste à modifier le paramètre de configuration mapreduce.tasktracker.map.tasks.maximum de Hadoop sur une valeur plus élevée. Cela a l'avantage de vous donner plus de mappeurs sans augmenter le nombre ou la taille des EC2 instances, ce qui vous permet d'économiser de l'argent. L'inconvénient est que si cette valeur est trop élevée, les EC2 instances de votre cluster risquent de manquer de mémoire. Pour définir mapreduce.tasktracker.map.tasks.maximum, lancez le cluster et spécifiez une valeur pour mapreduce.tasktracker.map.tasks.maximum en tant que propriété de la classification de configuration mapred-site. Voici un exemple : Pour de plus amples informations, veuillez consulter Configuration des applications.

{
    "configurations": [
    {
        "classification": "mapred-site",
        "properties": {
            "mapred.tasktracker.map.tasks.maximum": "10"
        }
    }
    ]
}

Demandes de données en parallèle

Plusieurs demandes de données, à partir de plusieurs utilisateurs ou de plusieurs applications vers une seule table, peuvent diminuer la vitesse de lecture allouée et ralentir les performances.

Durée du processus

La cohérence des données dans DynamoDB dépend de l'ordre des opérations de lecture et d'écriture sur chaque nœud. Quand une requête Hive est en cours, une autre application peut charger de nouvelles données dans la table DynamoDB, voire modifier ou supprimer des données existantes. Dans ce cas, les résultats de la requête Hive peuvent ne pas tenir compte des modifications apportées aux données pendant l'exécution de la requête.

Eviter le dépassement de débit

Lors de l'exécution de requêtes Hive sur DynamoDB, veillez à ne pas dépasser votre débit alloué, vous risquez sinon de réduire la capacité nécessaire des appels à DynamoDB::Get de votre application. Pour éviter que cela ne se produise, vous devez surveiller régulièrement le volume de lecture et la limitation des appels aux applications DynamoDB::Get en consultant les journaux et les métriques de surveillance sur Amazon. CloudWatch

Durée de la demande

La planification des requêtes Hive qui accèdent à une table DynamoDB à un moment où la demande sur celle-ci est inférieure a pour effet d'améliorer les performances. Par exemple, si la plupart des utilisateurs de votre application vivent à San Francisco, vous pouvez choisir d'exporter les données chaque jour à 4h00 PST, lorsque la majorité des utilisateurs sont endormis et ne mettent pas à jour les enregistrements de votre base de données DynamoDB.

Tables basées sur le temps

Si les données sont organisées en tant que série de tables DynamoDB basées sur le temps, telles qu'une table par jour, vous pouvez exporter les données lorsque la table n'est plus active. Vous pouvez utiliser cette technique pour sauvegarder les données sur Amazon S3 en continu.

Données archivées

Si vous prévoyez d'exécuter de nombreuses requêtes Hive sur les données stockées dans DynamoDB et que votre application peut tolérer les données archivées, vous souhaiterez peut-être exporter les données vers HDFS Amazon S3 et exécuter les requêtes Hive sur une copie des données plutôt que sur DynamoDB. Cela permet de conserver vos opérations de lecture et votre débit alloué.