Limites des connecteurs basés sur la query
Limitations générales
- Les connecteurs basés sur la query interrogent la source à une fréquence planifiée. Ils ne fournissent pas d’ingestion continue. Si vous avez besoin d'une latence plus faible, utilisez un connecteur de base de données CDC géré.
- La colonne de curseur doit être une colonne unique. Les curseurs composites (plusieurs colonnes combinées) ne sont pas pris en charge. La valeur de la colonne doit être strictement croissante. Les lignes dont les valeurs de curseur sont inférieures ou égales au seuil supérieur stocké ne sont pas réingérées.
- Les lignes avec une colonne de curseur NULL ne sont pas ingérées.
Exigences et recommandations pour les tables sources
Tenez compte des caractéristiques suivantes de la table source lorsque vous concevez une charge de travail d'ingestion basée sur des querys. Elles affectent la façon dont une table est ingérée et la performance de la charge de travail.
Clé primaire, clé unique et curseur
Les connecteurs basés sur la query utilisent une clé primaire (PK) ou une clé unique (UK) pour identifier les lignes et une colonne de curseur pour détecter les changements. Le comportement d'ingestion dépend des éléments disponibles sur la table source :
Table source | Comportement d'ingestion |
|---|---|
PK ou UK avec un curseur | Instantané régulier et ingestion incrémentielle. |
PK ou UK sans curseur | Mode instantané de batch ( |
Pas de PK ni de UK, curseur disponible | Le connecteur génère une clé synthétique à partir de toutes les colonnes. Cela fonctionne pour les tables sans lignes dupliquées. Pour les tables comportant des lignes entièrement dupliquées, utilisez le mode de stockage |
Pas de PK ou UK, pas de curseur | Le connecteur génère une clé synthétique à partir de toutes les colonnes. Utilisez le mode de stockage |
Recommandations de partitionnement et d'indexation
-
Colonne de partitionnement : le connecteur sélectionne automatiquement une colonne pour partitionner la query source pour les lectures parallèles. Il essaie d'abord la colonne de clé primaire principale, à condition qu'elle soit de type numérique, chaîne, date ou timestamp. Si cette colonne ne convient pas, elle sélectionne une colonne de clé unique à la place. Pour un partitionnement équilibré, la colonne doit avoir :
- Cardinalité élevée : au moins 1 000 valeurs distinctes sont recommandées pour les tables approchant 1 To.
- Faible asymétrie des données : Évitez les colonnes dont les valeurs se clusters fortement autour de quelques valeurs. Les colonnes asymétriques créent des partitions surdimensionnées qui peuvent provoquer des délais d'expiration des query et entraîner une perte de progression lorsqu'une exécution redémarre.
Si la colonne sélectionnée automatiquement ne répond pas à ces critères, contactez votre équipe de compte Databricks pour demander un remplacement de colonne de partitionnement.
-
Colonne de curseur indexée : Indexez la colonne de curseur sur la base de données source. Une colonne de curseur non indexée dégrade les performances des query incrémentales.
Fonctionnalités uniquement API
Les fonctionnalités suivantes sont prises en charge pour les connecteurs basés sur une query, mais uniquement à l'aide de l'API :
- Filtrage des lignes
- Suivi de la suppression logique (
deletion_condition) - Suivi des suppressions définitives (Bêta). Pris en charge uniquement pour les colonnes de curseur Timestamp.
- Ingestion en ajout seul (mode SCD
APPEND_ONLY) - Catalogue et schéma multi-destinations