Validation et traitement des erreurs¶

Validation côté serveur (par défaut)¶

snowflake.validation=server_side

Avec la validation côté serveur, les données sont envoyées à Snowflake sans vérification de type côté client. Le backend Snowflake effectue la validation et l’évolution des schémas, alignés sur le comportement de COPY et Snowpipe.

• Les enregistrements non valides sont capturés dans la table d’erreurs Snowflake associée à la table cible.

• Dans ce mode, la DLQ n’est pas utilisée pour les erreurs de validation liées à l’ingestion des données. Utilisez plutôt des tables d’erreurs. Cependant, les enregistrements qui ne parviennent pas à être désérialisés par les convertisseurs Kafka (avant d’atteindre Snowflake) sont toujours acheminés vers la DLQ si elle est configurée.

• Fournit un débit maximal en déchargeant la validation du connecteur.

• Prend en charge à la fois les modes de canal par défaut et les modes de canal définis par l’utilisateur.

Quand utiliser la validation côté serveur :

• Vous voulez un débit maximum.

• Vous pouvez gérer des tables d’erreurs dans Snowflake.

• Vous utilisez des canaux définis par l’utilisateur pour les transformations en cours.

Validation côté client¶

snowflake.validation=client_side

Avec la validation côté client, le connecteur valide les types de données et la compatibilité des schémas avant d’envoyer les lignes à Snowflake.

• Les enregistrements non valides sont traités conformément au paramètre errors.tolerance (voir ci-dessous).

• Les commandes DDL liées à l’évolution du schéma sont exécutées par le connecteur lorsque de nouveaux champs sont détectés.

• Prend en charge la Dead Letter Queue (DLQ ) pour le routage des enregistrements non valides.

• Fonctionne uniquement avec le canal par défaut ({tableName}-STREAMING). Si un canal créé par l’utilisateur existe et que la validation côté client est activée, le connecteur échoue avec ERROR_5030.

Quand utiliser la validation côté client :

• Vous avez besoin d’une Dead Letter Queue pour la gestion des erreurs.

• Vous effectuez une migration depuis la v3 et souhaitez retrouver un fonctionnement familier.

• Vous avez besoin du connecteur pour contrôler la validation.

Tolérance aux erreurs¶

La propriété errors.tolerance contrôle la manière dont le connecteur répond aux erreurs :

errors.tolerance=none (par défaut)

La tâche du connecteur échoue à la première erreur. Si une DLQ est configurée, l’enregistrement qui échoue est toujours envoyé à la DLQ avant l’abandon de la tâche.

errors.tolerance=all

Le connecteur poursuit l’ingestion des données. Les enregistrements non valides sont acheminés vers la DLQ (si configurée) ou ignorés sans notification.

Avertissement

Si l’on définit errors.tolerance=all sans configurer de sujet DLQ, les enregistrements non valides sont ignorés sans notification. Il s’agit d’une configuration non sécurisée pouvant entraîner une perte de données.

File d’attente lettres mortes (DLQ)¶

Pour configurer une DLQ :

errors.deadletterqueue.topic.name=my_topic_dlq
errors.log.enable=true

Les enregistrements suivants sont acheminés vers la DLQ (si configurée) :

• Erreurs de convertisseur (les deux modes de validation) : Les enregistrements qui ne parviennent pas à être désérialisés par les convertisseurs Kafka sont envoyés à la DLQ quel que soit le mode de validation. Ceci s’applique à la fois aux errors.tolerance=none (enregistrement poussé vers la DLQ, alors la tâche échoue) et aux errors.tolerance=all (enregistrement poussé vers la DLQ, la tâche se poursuit).

• Erreurs de validation côté client : Les enregistrements qui échouent à la conversion des données ou à la validation du schéma côté client sont envoyés à la DLQ quand snowflake.validation=client_side.

Les enregistrements qui échouent à l’ingestion côté serveur Snowflake ne sont pas acheminés vers la DLQ. Utilisez les tables d’erreurs à la place.

Tables d’erreurs (validation côté serveur)¶

Lorsque vous utilisez snowflake.validation=server_side, les enregistrements qui échouent à l’ingestion côté serveur (erreurs de correspondance de type, violations de contrainte) sont enregistrés dans la table d’erreurs pour une inspection et une relecture.

Pour plus d’informations sur les tables d’erreurs et la gestion des erreurs avec Snowpipe Streaming, voir Gestion des erreurs dans l’architecture hautes performances de Snowpipe Streaming.