Comment résoudre l'erreur « HIVE_CANNOT_OPEN_SPLIT: Error opening Hive split s3://awsdoc-example-bucket/: Slow Down (Service: Amazon S3; Status Code: 503; Error Code: 503 Slow Down; » dans Athena ?

Dernière mise à jour : 04-05-2021

Un compartiment Amazon Simple Storage Service (Amazon S3) peut traiter 3 500 requêtes PUT/COPY/POST/DELETE ou 5 500 requêtes GET/HEAD par seconde et par préfixe dans un compartiment. Ces erreurs se produisent lorsque ce seuil de requête est dépassé. Cette limite est une limite combinée pour tous les utilisateurs et services d'un compte.

Par défaut, Amazon S3 se met automatiquement à l'échelle pour prendre en charge des taux de demandes très élevés. Lorsque votre taux de demande évolue, votre compartiment S3 est automatiquement partitionné pour prendre en charge des taux de demandes plus élevés. Cependant, si le seuil de requête est dépassé, vous recevez des erreurs 5xx vous demandant de ralentir ou d'essayer plus tard.

Par exemple, le préfixe s3 : //my-athena-bucket/month=jan/ ne peut prendre en charge que 3 500 requêtes PUT/COPY/POST/DELETE par seconde ou 5 500 requêtes GET/HEAD par seconde. Si vous avez 10 000 fichiers à l'intérieur de ce préfixe et que vous exécutez une requête Athena sur ce préfixe, vous obtiendrez l'erreur 503 Slow Down. En effet, Athena essaie de lire l'ensemble des 10 000 fichiers sur le préfixe en même temps en utilisant les requêtes GET/HEAD, mais le préfixe ne peut prendre en charge que 5 500 requêtes GET/HEAD par seconde au maximum. Cela peut entraîner une limitation de vos requêtes S3 et déclencher une erreur 503 Slow Down.

Utilisez une ou plusieurs des méthodes suivantes pour empêcher la limitation des requêtes :

Le partitionnement de vos données peut aider à répartir les objets et les requêtes entre plusieurs préfixes. Évitez de stocker de nombreux fichiers sous un seul préfixe S3. Envisagez d'utiliser plusieurs préfixes afin de pouvoir répartir les objets S3 entre ces préfixes. En partitionnant vos données, vous pouvez réduire la quantité de données analysées par chaque requête. Pour en savoir plus, consultez Partitionnement des données.

Par exemple, au lieu de stocker tous les fichiers sous s3 : //my-athena-bucket/my-athena-data-files, partitionnez les données et stockez-les sous les préfixes individuels suivants :

s3 : //mon-athena-bucket/jan

s3 : //moy-athena-bucket/fev

s3 : //mon-athena-bucket/mar

Les données contenues dans ces fichiers peuvent être partitionnées davantage pour augmenter la distribution des objets (Exemple : s3 : //my-athena-bucket/jan/01).

Pour plus d'informations sur le choix de la structure de votre dossier de partition Athena, consultez les trucs et astuces sur les performances d'Amazon S3.

Vous pouvez obtenir cette erreur lorsque vous exécutez une requête sur un compartiment S3 avec un grand nombre de petits objets. Par exemple, si un compartiment S3 contient un fichier de 100 Mo, Athena doit effectuer 1 requête GET pour lire le fichier. Au contraire, s'il contient 1 000 fichiers de 100 Ko chacun, Athena doit effectuer 1 000 requêtes GET pour lire les mêmes 100 Mo de données. Les requêtes dépassent ainsi les limites de requête S3.

Pour réduire le nombre de requêtes Amazon S3, réduisez le nombre de fichiers. Par exemple, utilisez l'outil S3DistCp pour fusionner un grand nombre de petits fichiers (moins de 128 Mo) en un plus petit nombre de fichiers volumineux. Pour en savoir plus, consultez Les 10 meilleures techniques pour améliorer les performances d'Amazon Athena et consultez la section 4. Optimiser les tailles de fichier.

Exemple :

s3-dist-cp --src=s3://my_athena_bucket_source/smallfiles/ --dest=s3://my_athena_bucket_target/largefiles/ --groupBy='.*(.csv)'

Assurez-vous de remplacer ce qui suit dans la commande ci-dessus :

• my_athena_bucket_source par le compartiment S3 source contenant les petits fichiers.
• my_athena_bucket_target par le compartiment S3 de destination où la sortie sera stockée.

Vous pouvez utiliser l'option groupBy pour agréger de petits fichiers en un nombre inférieur de fichiers volumineux de la taille que vous choisissez. Cela peut vous aider à optimiser les performances et le coût des requêtes.

Remarque : S3DistCp ne prend pas en charge la concaténation pour les fichiers Parquet. Utilisez PySpark à la place. Pour en savoir plus, consultez Comment concaténer des fichiers Parquet dans Amazon EMR ?

Lorsque vous supprimez des objets d'un compartiment permettant la gestion des versions, Amazon S3 insère un marqueur de suppression plutôt que de supprimer définitivement l'objet. Si vous avez de nombreux fichiers dans votre compartiment S3 avec des marqueurs de suppression, vous pouvez obtenir cette erreur. Lorsque vous exécutez une requête sur un compartiment permettant la gestion des versions, Athena doit vérifier les différentes versions de chaque objet. Ensuite, Athena décide d'inclure un objet particulier pendant le traitement de la requête.

Pour résoudre cette erreur, envisagez de supprimer les marqueurs de suppression de votre compartiment S3. Vous pouvez supprimer les marqueurs de suppression en effectuant l'une des opérations suivantes :

• Suppression manuelle des marqueurs de suppression : Utilisez l'API ListObjectVersions pour lister les métadonnées de toutes les versions des objets dans votre compartiment S3. Dans les métadonnées renvoyées, recherchez le versionID de l'objet, puis supprimez définitivement le marqueur de suppression.
• Définition d'une configuration de cycle de vie pour supprimer les marqueurs de suppression : Vous pouvez utiliser les stratégies de cycle de vie S3 pour définir les actions que vous souhaitez qu'Amazon S3 exécute pendant la durée de vie d'un objet.

Utilisez la métrique Amazon CloudWatch 5xxErrors et les journaux d'accès au serveur S3 pour vérifier si d'autres applications, comme Hive on EMR, Spark ou AWS Glue, utilisaient le même préfixe S3 lorsque vous avez exécuté la requête Athena. Plusieurs applications essayant de lire les données à partir du même préfixe S3 peuvent entraîner une limitation des requêtes et des échecs de requête avec l'erreur Slow Down. Évitez de planifier des applications qui accèdent au même préfixe en même temps. De même, utilisez différents préfixes S3 pour la source de données Athena et la source de données d'application.

Vous pouvez créer une configuration de métriques CloudWatch pour tous les objets de votre compartiment S3. Utilisez ces métriques pour surveiller les métriques de taux d'appels de l'API pour un préfixe spécifique à un moment donné. L'activation des métriques de requête S3 pour un préfixe peut aider à comprendre le taux d'accès global à l'API pour un préfixe à un moment donné. Vous pouvez utiliser ces informations avec les journaux d'accès au serveur S3 pour trouver quelle application utilisait l'appel à l'API pour le préfixe.