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.
Résolution des problèmes de livraison de données
Utilisez cette section pour résoudre les problèmes courants liés à la fourniture de données.
Livraison bloquée dans l'état CREATION
Lorsque vous créez une diffusion, elle passe à l'état CREATING pendant que les ressources sont provisionnées. Le provisionnement s'effectue généralement en quelques minutes. Si la livraison reste dans CREATING pendant une période prolongée ou passe à FAILED, une erreur de configuration en est probablement la cause.
Appelez DescribeChannel pour vérifier le statut actuel et la raison du statut. Les causes courantes incluent :
L'ARN du rôle IAM n'est pas valide ou les autorisations sont insuffisantes dans la politique de rôle.
Le compartiment Amazon S3 de destination n'existe pas ou se trouve dans une autre région.
L'ARN du schéma dans AWS Glue Schema Registry ne peut pas être résolu.
Livraison en état d'échec
Vous ne pouvez pas récupérer une livraison dont le colis ChannelStatus est FAILED (tel que retourné parDescribeChannel). Lisez le ChannelStatusReason champ de DescribeChannel pour identifier la cause première. Corrigez le problème sous-jacent, supprimez la livraison qui a échoué et recréez-la avec la configuration corrigée.
Fraîcheur élevée des données
L'DataFreshnessindicateur mesure l'âge du plus vieux disque non livré. Des valeurs élevées indiquent que l'administration est en retard par rapport à l'ingestion. Causes courantes :
Le nombre élevé de partitions dans la table de destination augmente la charge de métadonnées.
La croissance des métadonnées des tables due à de nombreuses petites validations réduit le débit des validations.
Le faible débit combiné à un réglage de faible fraîcheur entraîne de fréquentes petites livraisons.
Résolution : pour les tableaux de streaming sur Apache Iceberg, activez la maintenance des tables Amazon S3 (compactage et expiration des instantanés) afin de gérer la croissance des métadonnées. Pour les flux à faible débit, augmentez la DataFreshnessInSeconds valeur afin de permettre à davantage de données d'être regroupées pour chaque cycle de diffusion.
Le paramètre de fraîcheur des données le plus strict nécessite un débit de flux minimum soutenu afin que suffisamment de données soient accumulées pour une diffusion efficace et un compactage en ligne à chaque cycle. Si votre flux produit un débit inférieur à ce débit, utilisez une DataFreshnessInSeconds valeur plus élevée.
Enregistrements échoués supérieurs à zéro
Lorsque la métrique des enregistrements échoués est différente de zéro (DeliveryToS3.FailedRecordCountpour les livraisons Amazon S3 ou DeliveryToIceberg.FailedRowCount pour les livraisons par table de streaming), les enregistrements sont envoyés vers la file d'attente des lettres mortes plutôt que vers la destination.
Pour les tables de streaming sur Apache Iceberg :
Incompatibilité de schéma : l'enregistrement n'est pas conforme au schéma enregistré.
Champ obligatoire manquant : une colonne non nullable n'a aucune valeur dans l'enregistrement.
Ne pas utiliser le sérialiseur AWS Glue Schema Registry pour le format GSR_JSON. Les producteurs doivent utiliser la bibliothèque de production Schema Registry. AWS Glue
Pour les compartiments Amazon S3 à usage général :
Incompatibilité de format : le format d'enregistrement ne correspond pas au format d'entrée configuré.
Solution : Inspectez les entrées de la file d'attente en lettres mortes pour obtenir des informations détaillées sur les erreurs. Consultez CloudWatch les journaux de livraison pour détecter les erreurs d'analyse ou de validation spécifiques. Demandez au producteur d'envoyer des enregistrements conformes.
Aucune donnée n'apparaît à la destination
Si la livraison est en état ACTIF mais qu'aucune donnée n'apparaît à destination, les causes les plus courantes sont les suivantes :
Problèmes d'autorisation : le rôle IAM ne peut pas écrire sur la destination. Vérifiez la présence CloudWatch d'
AccessDeniederreurs dans les journaux.Incompatibilité entre les préfixes des clés de sortie (compartiments Amazon S3 à usage général) : si votre
s3:PutObjectautorisation est limitée à un préfixe tel quearn:aws:s3:::my-bucket/data*, les clés générées par votre modèle de clé de sortie doivent commencer par.data/En cas de non-concordance, chaque écriture est refusée.Autorisation de table manquante (tables de streaming) : lorsque vous chiffrez la table de destination avec une AWS KMS clé gérée par le client, vérifiez que le rôle d'exécution du service inclut
s3tables:PutTableEncryptionen plus des autress3tablesactions. Sans elle, elleCreateTableréussit mais le chiffrement de la table échoue, la table n'est jamais créée et aucune donnée n'est fournie.Autorisations de journalisation manquantes : si le rôle d'exécution du service est absent
logs:CreateLogStreametlogs:PutLogEventsque les échecs de livraison ne sont pas enregistrés dans CloudWatch les journaux, ce qui peut faire apparaître un problème d'autorisations comme un échec silencieux. Vérifiez d'abord les autorisations de journalisation lorsqu'aucun journal n'est présent.Aucune nouvelle donnée après la création : la diffusion ne remplace pas les données existantes du flux. Seuls les enregistrements rédigés après que la livraison est devenue ACTIVE sont livrés.
Livraison suspendue
Une livraison passe à l'état suspendu lorsque la destination devient indisponible ou incompatible. Causes courantes :
Les tables de streaming sur la table de destination Apache Iceberg ont été supprimées.
Le propriétaire du compartiment Amazon S3 ne correspond pas au compte attendu (incompatibilité de propriété).
Une colonne de partition incompatible a été détectée dans la table de destination.
Une livraison suspendue ne peut pas être reprise. Vous devez créer une nouvelle livraison avec une configuration de destination valide.
Erreurs d'autorisation refusée dans CloudWatch les journaux
AccessDenieddes erreurs dans les CloudWatch journaux de livraison indiquent un problème d'autorisations. Causes courantes :
La politique de rôle IAM a été modifiée après la création de la diffusion.
La politique du compartiment Amazon S3 a été modifiée pour refuser l'accès depuis le rôle.
La politique de confiance relative au rôle ne permet pas au service Kinesis Data Streams de l'assumer.
La politique de AWS KMS clé refuse de chiffrer ou de déchiffrer l'accès au rôle de la diffusion.
Passez en revue et corrigez la politique correspondante, puis vérifiez que la livraison reprend.
La livraison n'est pas disponible pour mon stream
Les tables de streaming et la diffusion Amazon S3 nécessitent que le flux Kinesis Data Streams soit en mode de capacité On-Demand Standard ou On-Demand Advantage. Si votre flux utilise le mode Provisioned, vous devez le passer On-Demand en mode avant de pouvoir créer une diffusion.
La livraison s'arrête après un changement de schéma
Les livraisons ne prennent pas en charge l'évolution du schéma. Si vous mettez à jour le AWS Glue schéma dans Schema Registry après avoir créé une livraison, les enregistrements produits avec la nouvelle version du schéma risquent d'échouer à la validation et d'être acheminés vers la file d'attente de lettres mortes.
Pour résoudre le problème : annulez le changement de schéma chez le producteur, ou supprimez la livraison existante et recréez-la avec le schéma mis à jour.
Impossible de supprimer un flux
Une DeleteStream demande échoue ResourceInUseException lorsque le flux comporte une ou plusieurs livraisons actives. Un flux ne peut pas être supprimé tant que des livraisons y sont associées.
Pour résoudre le problème : listez les diffusions du stream avec ListChannels (à l'aide d'un filtre de flux)DeleteChannel, supprimez chaque diffusion avec, puis supprimez le stream.
