Aller au contenu principal
Dernière mise à jour le

Dépanner les connecteurs basés sur query

Pour obtenir des conseils de dépannage généraux qui s'appliquent à tous les pipelines d'ingestion gérés, consultez Dépannage des pipelines d'ingestion gérés.

Colonnes de curseur invalides​

Symptôme : le pipeline échoue avec l’erreur INVALID_CURSOR_COLUMNS.

Cause : La colonne de curseur n'est pas configurée correctement. La cause la plus courante est la spécification de plus d'une colonne de curseur. Les connecteurs basés sur la query nécessitent exactement une colonne de curseur.

Résolution :

  1. Ouvrez votre configuration de pipeline (bundle YAML ou CLI JSON).
  2. Vérifiez le champ cursor_column (ingestion de connexion étrangère) ou la liste cursor_columns (ingestion de catalogue étranger).
  3. Confirmez qu'exactement un nom de colonne est spécifié. Supprimez toutes les entrées supplémentaires.
  4. Confirmez que la colonne que vous avez spécifiée existe dans la table source et contient des valeurs qui augmentent de manière monotone.
  5. Redéployez ou mettez à jour le pipeline et Trigger une nouvelle exécution.

Échecs de connexion​

Symptôme : le pipeline ne parvient pas à se connecter à la base de données source, ou le test de connexion renvoie une erreur.

Résolution :

  1. Vérifiez que l'objet de connexion Unity Catalog est valide :

    • Dans le Workspace Databricks, accédez à Catalog > Connections et confirmez que la connexion existe et que les identifiants sont à jour.
    • Si les identifiants ont expiré ou ont été modifiés, mettez à jour la connexion avec les nouvelles valeurs.

  2. Vérifiez la connectivité réseau du compute Serverless à la base de données source :

    • Confirmez que l’hôte de la base de données est accessible depuis le réseau de Serverless compute.
    • Vérifiez que les règles de pare-feu, les paramètres de groupe de sécurité ou le peering de Virtual Private Cloud (VPC)/VNet autorisent le trafic des plages d'adresses IP du compute Serverless vers le port de la base de données.
    • Pour les bases de données on-premise, confirmez que le chemin réseau (tel qu'AWS Direct Connect ou Azure ExpressRoute) est actif.

  3. Pour l'ingestion du catalogue étranger, confirmez que le catalogue étranger Unity Catalog est accessible :

    • Dans le workspace Databricks, accédez à Catalog et confirmez que le catalogue étranger est visible et interrogeable.
    • Essayez d'exécuter un simple SELECT sur une table du catalogue externe pour vérifier que la connexion de Lakehouse Federation fonctionne.

Le pipeline n’ingère pas de nouvelles lignes​

Symptôme : le pipeline s'exécute correctement, mais la table de destination ne reçoit pas de nouvelles lignes, même si de nouvelles données existent dans la source.

Causes et résolutions possibles :

  • La valeur de la colonne de curseur n'avance pas. Vérifiez si la colonne de curseur dans la source est mise à jour lorsque les lignes changent. Si la valeur de la colonne ne change pas lorsqu'une ligne est modifiée, le connecteur ne détectera pas le changement. Envisagez d'utiliser une autre colonne, telle qu'un timestamp last_modified qui est mis à jour à chaque écriture.
  • Valeurs NULL du curseur. Les lignes où la colonne du curseur est NULL sont exclues de l'ingestion. Si de nombreuses lignes contiennent NULL dans la colonne de curseur, ces lignes ne sont jamais ingérées. Assurez-vous que la colonne de curseur est renseignée pour toutes les lignes que vous souhaitez ingérer.
  • Données à arrivée tardive ou décalage d'horloge. Si des lignes sont écrites avec un Timestamp futur, si les données arrivent en retard par rapport au calendrier du pipeline ou s'il y a une drift d'horloge significative sur la source, ces lignes pourraient avoir des valeurs de curseur supérieures à la marque haute actuelle mais ne pas être encore visibles pour la prochaine exécution. Dans la plupart des cas, cela se résout lors de la prochaine exécution.
  • refresh complète nécessaire. Si vous avez modifié la colonne de curseur ou Reset les données source, effectuez une full refresh pour réingérer depuis le début. Voir refresh complète des tables cibles.

Le suivi de la suppression ne fonctionne pas​

Symptôme : Les lignes qui sont supprimées logiquement dans la source sont toujours présentes dans la table de destination après l'exécution d'un pipeline.

Cause : Le suivi des suppressions logiques nécessite le paramètre deletion_condition dans la configuration de votre pipeline. Ce paramètre n’est configurable qu’à l’aide de l’API.

Résolution :

  1. Confirmez que le paramètre deletion_condition est défini dans votre configuration de pipeline et que son expression SQL identifie correctement les lignes supprimées de manière logique. Par exemple :

    JSON
    "deletion_condition": "deleted_at IS NOT NULL"

  2. Vérifiez que l'expression est correctement évaluée par rapport aux données réelles de la table source. Exécutez la query équivalente directement sur la source pour confirmer qu'elle renvoie les lignes que vous vous attendez à voir supprimées.

  3. Si vous avez récemment ajouté le deletion_condition à un pipeline existant, Trigger une exécution de pipeline et vérifiez que la table de destination reflète les suppressions une fois l'exécution terminée.

Pour la syntaxe de référence de deletion_condition, consultez Condition de suppression.

Sur cette page