Gestion des erreurs dans Snowpipe Streaming haute performance

Cette rubrique présente les mécanismes de gestion des erreurs disponibles dans l’édition haute performance de Snowpipe Streaming. Cette approche améliorée fournit des informations détaillées sur les erreurs et améliore le processus global de traitement des erreurs pour une expérience plus robuste et plus informative.

Fonctions clés de traitement des erreurs dans l’architecture haute performance

  • Amélioration du point de terminaison du statut du canal : Cette édition étend le point de terminaison du statut du canal afin de fournir des informations plus complètes sur les erreurs.

  • Détails granulaires des erreurs : L’édition haute performance fournit des informations plus détaillées sur les erreurs pour aider à identifier l’endroit où elles se sont produites et à trouver les causes racines des problèmes d’ingestion.

  • Amélioration de l’expérience client : L’édition haute performance simplifie la gestion des erreurs pour les clients, en réduisant la complexité du raisonnement et de la récupération des erreurs.

  • The channel history view: Vue SNOWPIPE_STREAMING_CHANNEL_HISTORY provides a historical record of channel activity to monitor and locate errors. This feature enables you to track error trends and proactively address potential issues.

Point de terminaison du statut du canal

The high-performance architecture includes a channel status endpoint to provide more detailed, point-in-time information about a channel.

In addition to the channel status information for the classic architecture, which is statusCode, persistedOffsetToken, the high-performance architecture includes the following information:

  • channel_status_code: Represents the current operational status of the streaming channel. This code provides a high-level indication of the channel’s health and ability to ingest data. For more information about the channel status codes, see Gestion des erreurs côté client et actions requises.

  • last_commited_offset_token : Indique le jeton de décalage du dernier ensemble de lignes qui a été validé dans la table cible par Snowflake. C’est essentiel pour suivre les progrès et garantir la transmission des données.

  • created_on_ms: The timestamp, in milliseconds, that indicates when the streaming channel was initially created within Snowflake.

  • database_name : Le nom de la base de données vers laquelle le canal de diffusion est configuré pour ingérer des données.

  • schema_name : Le nom du schéma au sein de la base de données spécifiée où réside la table cible du canal de diffusion.

  • pipe_name : Le nom de l’objet Snowpipe qui est configuré pour utiliser ce canal Snowpipe Streaming pour l’ingestion de données dans une table cible spécifique.

  • channel_name : Un nom créé par l’utilisateur pour l’instance spécifique du canal de Snowpipe Streaming.

  • rows_inserted : Un décompte du nombre total de lignes de données qui ont été insérées dans la table cible par le biais de ce canal de diffusion depuis sa création.

  • rows_parsed : Un décompte du nombre total de lignes de données qui ont été traitées et analysées par le service Snowpipe Streaming pour ce canal (mais pas nécessairement insérées, par exemple en raison d’erreurs).

  • rows_error_count : Un décompte du nombre total de lignes de données qui ont rencontré des erreurs lors du traitement et qui ont donc été rejetées par le service Snowpipe Streaming pour ce canal.

  • last_error_offset_upper_bound : La limite supérieure de l’intervalle de jetons de décalage du dernier ensemble de lignes qui contenait des erreurs. Cela permet d’identifier l’emplacement approximatif des erreurs les plus récentes dans le flux de données.

  • last_error_message : Un message lisible par l’homme correspondant au dernier code d’erreur.

  • last_error_timestamp : L’horodatage indiquant quand l’erreur la plus récente s’est produite sur ce canal de diffusion.

  • snowflake_avg_processing_latency_ms : La latence moyenne, en millisecondes, observée par le service Snowflake dans le traitement des ensembles de lignes reçus par ce canal. Cette métrique donne un aperçu des performances du pipeline d’ingestion au sein de Snowflake.

Flux de traitement des erreurs dans l’architecture haute performance

  • Envoi de données par le client : L’application client utilise le SDK de Snowpipe Streaming pour envoyer des données à Snowflake via l’API appendRow(s).

  • Traitement par le serveur : Le service Snowflake traite les données. Cela implique ce qui suit :

    • Mise en mémoire tampon des données.

    • Analyse et validation des données.

    • Enregistrement des données dans la table.

  • Détection des erreurs : Des erreurs peuvent se produire au cours de n’importe quelle zone de préparation de traitement côté serveur.

  • Error recording: Snowflake records detailed information about the last occurred error, including the following information:

    • La limite supérieure de l’intervalle de jetons de décalage du dernier ensemble de lignes contenant des erreurs. Cela permet d’identifier l’emplacement approximatif des erreurs les plus récentes dans le flux de données.

    • Un message d’erreur.

    • Un horodatage.

  • Rapport d’erreur :

    • Le point de terminaison amélioré du statut du canal permet d’accéder aux informations d’erreur enregistrées.

    • Les clients peuvent interroger ce point de terminaison pour récupérer les détails de la dernière erreur survenue.

    • Vue SNOWPIPE_STREAMING_CHANNEL_HISTORY provides a historical record of errors and their offsets.

  • Client action: The client application uses the error information to perform the following actions:

    • Identifier la cause de l’erreur.

    • Implement appropriate error handling logic, such as the following actions:

      • Réessayer l’opération qui a échoué.

      • Consigner l’erreur.

      • Alerter un administrateur.

      • Déplacer les données erronées vers une file d’attente de lettres mortes.

      • Réouvrir les canaux.

Gestion des erreurs côté client et actions requises

Le SDK Snowpipe Streaming simplifie la gestion des erreurs en mettant en œuvre une logique de relance interne pour les erreurs transitoires. Cependant, en cas d’erreurs de canal fatales et de problèmes d’autorisation persistants, vous devez intervenir manuellement.

Logique de nouvelle tentative du SDK pour les erreurs transitoires

Le SDK retente automatiquement la requête pour envoyer les données non vidées dans le canal au serveur pour les codes de statut HTTP suivants, car ils indiquent généralement un problème de service temporaire ou transitoire :

  • 5XX (Erreurs de serveur)

  • 429 (Trop de requêtes)

  • 408 (Délai d’expiration de la requête)

Erreurs de canal nécessitant une réouverture manuelle

Le SDK Snowpipe Streaming ne rouvre pas automatiquement le canal. Lorsqu’un canal entre dans un état qui n’est pas valide, le client doit explicitement fermer et rouvrir le canal pour poursuivre l’ingestion.

Un canal n’est pas considéré comme valide, et nécessite une action client, si le channel_status_code dans la réponse du statut du canal est autre que SUCCESS.

Le tableau suivant présente les codes d’erreur persistants qui indiquent un état de canal fatal et nécessitent la réouverture du canal :

Code d’erreur

Contexte

Action client requise

ERR_PIPE_DOES_NOT_EXIST_OR_NOT_AUTHORIZED

Le canal cible est manquant ou inaccessible.

Corrigez le problème de canal. Rouvrez le canal.

ERR_TABLE_DOES_NOT_EXIST_NOT_AUTHORIZED

La table cible est manquante ou inaccessible.

Corrigez le problème de table. Rouvrez le canal.

ERR_CHANNEL_HAS_INVALID_ROW_SEQUENCER

L’état de séquencement des lignes n’est pas valide.

Reopen channel.

ERR_CHANNEL_HAS_INVALID_CLIENT_SEQUENCER

L’état de séquencement du canal n’est pas valide.

Reopen channel.

ERR_CHANNEL_MUST_BE_REOPENED

Une erreur générale indiquant que le canal est inutilisable.

Reopen channel.

ERR_CHANNEL_MUST_BE_REOPENED_DUE_TO_ROW_SEQ_GAP

Un écart dans la séquence de lignes a été détecté.

Reopen channel.

Erreurs d’autorisation nécessitant une correction de la configuration

Lorsqu’une tentative d’ingestion aboutit à une erreur d’autorisation HTTP, le client doit corriger l’autorisation sous-jacente ou le problème d’identifiants. Ne rouvrez pas le canal pour ces erreurs, car le nouveau canal rencontrera immédiatement le même problème.

  • 401 (Non autorisé)

  • 403 (Interdit)

Pour ces erreurs, l’ingestion doit être arrêtée et la configuration de sécurité de l’application cliente (par exemple, les autorisations de canal, le rôle de l’utilisateur, les identifiants d’authentification) doit être corrigée avant la reprise de l’ingestion. Après avoir résolu le problème d’autorisation, vous pouvez rouvrir le client pour poursuivre l’ingestion.