Connecteurs basés sur des requêtes

Important

Cette fonctionnalité est disponible en préversion publique.

Les connecteurs basés sur des requêtes dans Lakeflow Connect ingèrent des données à partir de bases de données en interrogeant directement la source, sans nécessiter de configuration de capture de données modifiées (CDC). Au lieu de s’appuyer sur des fichiers binaires ou une infrastructure CDC, ils utilisent une colonne de curseur ( un horodatage ou une colonne entière) monotoniquement croissant pour suivre les lignes qui sont nouvelles ou mises à jour depuis la dernière exécution du pipeline.

Les connecteurs basés sur des requêtes utilisent les connexions de catalogue Unity et la fédération Lakehouse pour se connecter aux bases de données sources, et ils écrivent des résultats dans des tables de diffusion en continu.

Fonctionnement

Sur chaque exécution de pipeline, un connecteur basé sur une requête interroge la base de données source et récupère toutes les lignes avec une valeur de colonne de curseur supérieure à la valeur enregistrée à partir de l’exécution précédente. Le connecteur stocke le seuil élevé de la colonne du curseur après chaque exécution réussie et l’utilise comme borne inférieure pour l’exécution suivante.

Étant donné que le connecteur interroge directement la source, il ne nécessite pas de passerelle d’ingestion ou un volume intermédiaire. Le pipeline s’exécute selon une planification que vous définissez, et non en continu.

Connecteurs basés sur des requêtes par rapport aux connecteurs de base de données CDC

Les connecteurs basés sur des requêtes diffèrent des connecteurs de base de données CDC de différentes façons :

  • Aucune passerelle d’ingestion : les connecteurs CDC nécessitent une passerelle pour capturer les événements binlog. Les connecteurs basés sur des requêtes n’utilisent pas de passerelle.
  • Aucun volume intermédiaire : les connecteurs CDC mettent en mémoire tampon les données extraites dans un volume intermédiaire. Les connecteurs basés sur des requêtes écrivent directement à partir de la requête source dans la table de destination.
  • Planifié au lieu d’être continu : les connecteurs basés sur des requêtes s’exécutent selon une planification. Ils ne capturent pas chaque état de ligne intermédiaire entre les exécutions. Ils capturent uniquement l’état le plus récent des lignes qui ont changé.
  • Compatibilité plus large de la source : 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 l’accès cdc ou binlog.

Le compromis est que les performances des requêtes peuvent être plus lentes et que les requêtes s’exécutent directement sur des tables sources, ce qui peut placer plus de charge sur la base de données source par rapport aux connecteurs CDC qui interrogent le binlog. Le suivi des suppressions réversibles est pris en charge à l’aide de deletion_condition. Le suivi de suppression complète est aussi pris en charge dans la version bêta. Les deux nécessitent une configuration d’API.

Approches d’ingestion prises en charge

Les connecteurs basés sur des requêtes prennent en charge plusieurs approches d’ingestion. L’approche que vous utilisez détermine les paramètres de configuration requis.

Approche Comment ça se connecte Paramètres requis
Ingestion de connexion étrangère Utilise une connexion qui stocke les informations d’identification d’authentification pour la base de données source. Le connecteur utilise la connexion pour interroger directement la base de données source. connection_name, source_catalog, , source_schema, source_table, cursor_column
Ingestion de catalogue étranger Utilise un catalogue externe soutenu par une source de données Fédération Lakehouse. Le connecteur utilise le catalogue étranger pour lire les données sources au lieu de se connecter directement à la base de données source. ingest_from_uc_foreign_catalog: true, cursor_columns, primary_keys (obligatoire sauf si vous utilisez le mode APPEND_ONLY)

Sources prises en charge

Les sources de base de données suivantes sont prises en charge.

Sources d’ingestion de connexion étrangère :

  • Oracle
  • Teradata
  • SQL Server
  • MySQL
  • MariaDB
  • PostgreSQL

Sources d’ingestion de catalogues étrangers :

Toutes les sources de données de Lakehouse Federation sont prises en charge à l’aide de l’ingestion de catalogue externe. Pour obtenir la liste complète, consultez Lakehouse Federation.

Interfaces prises en charge

Vous pouvez utiliser l’interface utilisateur Azure Databricks ou les bundles Automation déclaratifs pour créer des pipelines basés sur des requêtes.

Exigences de calcul

Les pipelines d’ingestion basés sur des requêtes s’exécutent par défaut sur le calcul sans serveur. Le calcul classique est pris en charge en version bêta, mais uniquement à l’aide d’API. Databricks recommande d’utiliser le calcul serverless.

Pour utiliser des connecteurs basés sur des requêtes avec un calcul serverless, votre environnement de calcul doit autoriser la connectivité réseau à la base de données source. Consultez Mise en réseau et Recommandations en matière de mise en réseau pour Lakehouse Federation.

Modes de suivi d'historique (SCD)

Les connecteurs basés sur des requêtes prennent en charge les modes de suivi d’historique suivants, également appelés modes SCD (Dimension à variation lente) pour les tables de destination :

  • SCD_TYPE_1 : remplace la ligne existante dans la table de destination avec la dernière ligne source. Aucun historique n’est conservé.
  • SCD_TYPE_2 : conserve l’historique complet des modifications de ligne en ajoutant de nouvelles lignes avec des métadonnées de version. Consultez Activer le suivi de l’historique (type SCD 2).
  • APPEND_ONLY : ajoute chaque ligne ingérée à la table de destination sans fusion ni remplacement.

Évolution du schéma

Les connecteurs basés sur des requêtes gèrent l’évolution du schéma de la même façon que d’autres connecteurs managés dans Lakeflow Connect. Découvrez comment les connecteurs managés gèrent-ils l’évolution du schéma ?.

  • Last updated on