Connecteurs basés sur la query
Les connecteurs basés sur des queries de Lakeflow Connect ingèrent les données des bases de données en interrogeant directement la source, sans nécessiter de configuration de la capture des changements de données (CDC). Au lieu de s'appuyer sur les binlogs ou l'infrastructure CDC, ils utilisent une colonne curseur — une colonne d'entiers ou de Timestamp à croissance monotone — pour suivre les lignes nouvelles ou mises à jour après la dernière exécution du pipeline.
Les connecteurs basés sur des requêtes utilisent les connexions Unity Catalog et la Lakehouse Federation pour se connecter aux bases de données sources, et ils écrivent les résultats dans des tables de streaming.
Comment cela fonctionne
Lors de chaque exécution de pipeline, un connecteur basé sur la query interroge la base de données source et récupère toutes les lignes dont la valeur de la colonne du curseur est supérieure à la limite supérieure de l'exécution précédente. Le connecteur stocke la valeur de référence de la colonne de curseur après chaque exécution réussie et l'utilise comme borne inférieure pour la prochaine exécution.
Étant donné que le connecteur interroge directement la source, il ne nécessite pas de passerelle d'ingestion ni de volume de staging. Le pipeline s'exécute selon un calendrier que vous définissez, pas en continu.
Connecteurs basés sur une query comparés aux connecteurs de base de données CDC.
Les connecteurs basés sur la query diffèrent des connecteurs de base de données CDC de la manière suivante :
- Pas de passerelle d'ingestion : les connecteurs CDC nécessitent une passerelle pour capturer les événements de binlog. Les connecteurs basés sur une query n'utilisent pas de passerelle.
- Pas de volume de staging : Les connecteurs CDC mettent en mémoire tampon les données extraites dans un volume de staging. Les connecteurs basés sur une query écrivent directement de la query source vers la table de destination.
- Planifiés au lieu de continus : les connecteurs basés sur les query s'exécutent selon un calendrier. Ils ne capturent pas tous les états de ligne intermédiaires entre les exécutions. Ils ne capturent que l'état le plus récent des lignes qui ont changé.
- Compatibilité de source plus large : Toute base de données avec une colonne de curseur appropriée est une source valide, même si elle ne prend pas en charge le CDC ou l'accès au journal binaire.
Le compromis est que les performances des requêtes peuvent être plus lentes et que les requêtes s'exécutent directement sur les tables source, ce qui peut imposer une charge plus importante sur la base de données source par rapport aux connecteurs CDC qui interrogent le journal binaire. Le suivi des suppressions logiques est pris en charge à l'aide de deletion_condition. Le suivi des suppressions définitives est également pris en charge en version Beta. Les deux nécessitent une configuration d'API.
Approches d'ingestion prises en charge
Les connecteurs basés sur la query prennent en charge plusieurs approches d'ingestion. L'approche que vous utilisez détermine quels paramètres de configuration sont requis.
Approche | Comment il se connecte | Paramètres requis |
|---|---|---|
Ingestion de connexion externe | Utilise une connexion qui stocke les identifiants d'authentification pour la base de données source. Le connecteur utilise la connexion pour query directement la base de données source. |
|
Ingestion de catalogue étranger | Utilise un catalogue externe alimenté par une source de données Lakehouse Federation. Le connecteur utilise le catalogue étranger pour lire les données source au lieu de se connecter directement à la base de données source. |
|
Sources prises en charge
Les sources de bases de données suivantes sont prises en charge.
Sources d'ingestion de connexions étrangères :
- Oracle
- Teradata
- SQL Server
- MySQL
- MariaDB
- PostgreSQL
Sources d'ingestion de catalogues étrangers :
Toutes les sources de données Lakehouse Federation sont prises en charge à l'aide de l'ingestion de catalogues étrangers. Pour la liste complète, voir Lakehouse Federation.
Interfaces prises en charge
Vous pouvez utiliser l'interface utilisateur de Databricks ou les Declarative Automation Bundles pour créer des pipelines basés sur des requêtes.
Exigences de compute
Les pipelines d'ingestion basés sur les queries s'exécutent sur le compute serverless par default. Le déploiement du compute classique est pris en charge en version bêta via les Declarative Automation Bundles ou l'API. Databricks recommande d'utiliser le compute serverless. Voir Créer un pipeline d’ingestion basé sur la query.
Pour utiliser des connecteurs basés sur une query avec le compute Serverless, votre environnement de compute doit autoriser la connectivité réseau à la base de données source. Consultez Réseau et Recommandations réseau pour Lakehouse Federation.
Modes de suivi de l'historique (SCD)
Les connecteurs basés sur une query prennent en charge les modes de suivi d'historique suivants — également connus sous le nom de modes de dimension à évolution lente (SCD) — pour les tables de destination :
- SCD_TYPE_1 : Écrase la ligne existante dans la table de destination avec la dernière ligne source. La table de destination ne conserve aucun historique.
- **SCD_TYPE_2** : Préserve l'historique complet des modifications de ligne en ajoutant de nouvelles lignes avec des métadonnées de version. Voir Activer le suivi de l'historique (SCD de type 2).
- APPEND_ONLY : Ajoute chaque ligne ingérée à la table de destination sans fusionner ni écraser.
évolution des schémas
Les connecteurs basés sur la requête gèrent l'évolution des schémas de la même manière que les autres connecteurs gérés de Lakeflow Connect. Consultez Comment les connecteurs gérés gèrent-ils l’évolution des schémas ?