Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los conectores basados en consultas de Lakeflow Connect ingieren datos de bases de datos consultando el origen directamente, sin necesidad de una configuración de captura de datos modificados (CDC). En lugar de depender de binlogs o de una infraestructura de CDC, usan una columna de cursor —una marca de tiempo o una columna entera que aumenta de forma monotónica— para realizar un seguimiento de las filas que son nuevas o se han actualizado después de la última ejecución de la canalización.
Los conectores basados en consultas usan conexiones de Unity Catalog y Lakehouse Federation para conectarse a bases de datos de origen, y escriben los resultados en tablas de streaming.
Cómo funciona
En cada ejecución de la canalización, un conector basado en consultas consulta la base de datos de origen y recupera todas las filas cuyo valor de columna de cursor es mayor que la marca de agua alta de la ejecución anterior. El conector almacena el punto máximo de la columna del cursor después de cada ejecución exitosa y lo utiliza como límite inferior en la siguiente ejecución.
Dado que el conector consulta el origen directamente, no requiere una puerta de enlace de ingesta ni un volumen de almacenamiento provisional. La canalización se ejecuta según un horario que usted defina, no continuamente.
Conectores basados en consultas en comparación con los conectores de base de datos CDC
Los conectores basados en consultas difieren de los conectores de base de datos CDC de las maneras siguientes:
- Sin pasarela de ingesta: los conectores CDC requieren una pasarela para capturar eventos de binlog. Los conectores basados en consultas no usan una puerta de enlace.
- Sin volumen de almacenamiento provisional: los conectores CDC almacenan en búfer los datos extraídos en un volumen de almacenamiento provisional. Los conectores basados en consultas escriben directamente desde la consulta de origen en la tabla de destino.
- Programado en lugar de continuo: los conectores basados en consultas se ejecutan según una programación. No capturan todos los estados intermedios de las filas entre ejecuciones. Solo capturan el estado más reciente de las filas que han cambiado.
- Compatibilidad de origen más amplia: cualquier base de datos con una columna de cursor adecuada es un origen válido, aunque no admita el acceso CDC o binlog.
La desventaja es que el rendimiento de las consultas puede ser más lento y las consultas se ejecutan directamente en las tablas de origen, lo que puede imponer más carga en la base de datos de origen en comparación con los conectores CDC que interactúan con el binlog. El seguimiento de eliminaciones lógicas se admite mediante deletion_condition.
El seguimiento de eliminación completa también está compatible con la versión Beta. Ambos requieren configuración de API.
Enfoques de ingesta admitidos
Los conectores basados en consultas admiten varios enfoques de ingesta. El enfoque que usa determina qué parámetros de configuración son necesarios.
| Enfoque | Cómo se conecta | Parámetros necesarios |
|---|---|---|
| Ingesta de conexión externa | Usa una conexión que almacena las credenciales de autenticación para la base de datos de origen. El conector usa la conexión para consultar directamente la base de datos de origen. |
connection_name, source_catalog, source_schema, , source_table, cursor_column |
| Ingestión de catálogos externos | Usa un catálogo externo respaldado por un origen de datos de Lakehouse Federation. El conector usa el catálogo externo para leer datos de origen en lugar de conectarse directamente a la base de datos de origen. |
Fuentes admitidas
Se admiten los siguientes orígenes de base de datos.
Orígenes de entrada de conexiones externas:
- Oracle
- Teradata
- SQL Server
- MySQL
- MariaDB
- PostgreSQL
Fuentes de ingestión de catálogos externos:
Todas las fuentes de datos de Lakehouse Federation se admiten mediante la ingesta de catálogo externo. Para obtener la lista completa, consulte Federación de Lakehouse.
Interfaces admitidas
Puede usar la interfaz de usuario de Azure Databricks o agrupaciones de automatización declarativa para crear canalizaciones basadas en consultas.
Requisitos de cómputo
Las canalizaciones de ingestión basadas en consultas se ejecutan por defecto en computación sin servidor, aunque también se soportan despliegues clásicos de cómputo. Databricks recomienda usar cómputo sin servidor. Consulte Creación de una canalización de ingesta basada en consultas.
Para usar conectores basados en consultas con proceso sin servidor, el entorno de proceso debe permitir la conectividad de red a la base de datos de origen. Consulte Redes y Recomendaciones de redes para la federación de Lakehouse.
Modos de seguimiento del historial (SCD)
Los conectores basados en consultas admiten los siguientes modos de seguimiento del historial, también conocidos como modos de dimensión de cambio lento (SCD), para las tablas de destino.
- SCD_TYPE_1: sobrescribe la fila existente en la tabla de destino con la fila de origen más reciente. La tabla de destino no conserva ningún historial.
- SCD_TYPE_2: conserva el historial completo de cambios de fila agregando nuevas filas con metadatos de versión. Consulte Habilitación del seguimiento del historial (tipo 2 de SCD).
- APPEND_ONLY: anexa todas las filas ingeridas a la tabla de destino sin combinar ni sobrescribir.
Evolución del esquema
Los conectores basados en consultas controlan la evolución del esquema de la misma manera que otros conectores administrados en Lakeflow Connect. Consulte ¿Cómo controlan los conectores administrados la evolución del esquema?.