Compartilhar via


Conectores baseados em consulta

Importante

Esse recurso está em Visualização Pública.

Conectores baseados em consulta no Lakeflow Connect realizam a ingestão de dados de bancos de dados ao consultar diretamente a origem, sem exigir a configuração de CDC (captura de dados de alteração). Em vez de depender de binlogs ou infraestrutura CDC, eles usam uma coluna de cursor—uma coluna de data/hora ou um valor inteiro que aumenta monotonicamente—para rastrear quais linhas são novas ou atualizadas desde a última execução do pipeline.

Conectores baseados em consulta usam conexões do Catálogo do Unity e a Federação Lakehouse para se conectar a bancos de dados de origem e gravam resultados em tabelas de streaming.

Como funciona

Em cada execução de pipeline, um conector baseado em consulta executa uma consulta no banco de dados de origem e recupera todas as linhas com um valor de coluna de cursor maior que o valor registrado da execução anterior. O conector armazena o ponto de referência da coluna do cursor após cada execução bem-sucedida e o utiliza como limite inferior na próxima execução.

Como o conector consulta diretamente a origem, ele não requer um gateway de ingestão ou um volume de estágio. O pipeline é executado conforme um horário que você define, e não continuamente.

Conectores baseados em consulta em comparação com conectores de banco de dados CDC

Os conectores baseados em consulta diferem dos conectores de banco de dados CDC das seguintes maneiras:

  • Nenhum gateway de ingestão: os conectores CDC exigem um gateway para capturar eventos de binlog. Conectores baseados em consulta não usam um gateway.
  • Nenhum volume de preparo: os conectores CDC armazenam dados extraídos em um volume de preparo. Conectores baseados em consulta gravam diretamente da consulta de origem para a tabela de destino.
  • Agendado em vez de contínuo: conectores baseados em consulta são executados conforme um horário definido. Eles não capturam todos os estados de linha intermediária entre execuções. Eles capturam apenas o estado mais recente das linhas que foram alteradas.
  • Compatibilidade de origem mais ampla: qualquer banco de dados com uma coluna de cursor adequada é uma origem válida, mesmo que não dê suporte a acesso CDC ou binlog.

A compensação é que o desempenho da consulta pode ser mais lento e as consultas são executadas diretamente em tabelas de origem, o que pode colocar mais carga no banco de dados de origem em comparação com os conectores CDC que consultam o binlog. Há suporte para o acompanhamento de exclusão lógica usando deletion_condition. Também há suporte para o acompanhamento de exclusão permanente na Beta. Ambos exigem a configuração da API.

Abordagens de ingestão com suporte

Conectores baseados em queries dão suporte a diversas abordagens de ingestão. A abordagem usada determina quais parâmetros de configuração são necessários.

Abordagem Como ele se conecta Parâmetros necessários
Ingestão de conexão estrangeira Usa uma conexão que armazena credenciais de autenticação para o banco de dados de origem. O conector usa a conexão para consultar o banco de dados de origem diretamente. connection_name, source_catalog, source_schema, , source_tablecursor_column
Ingestão de catálogo estrangeiro Usa um catálogo externo apoiado por uma fonte de dados da Federação Lakehouse. O conector usa o catálogo estrangeiro para ler dados de origem em vez de se conectar diretamente ao banco de dados de origem. ingest_from_uc_foreign_catalog: true, cursor_columns, primary_keys (obrigatório, a menos que você use o modo APPEND_ONLY)

Fontes com suporte

Há suporte para as seguintes fontes de banco de dados.

Fontes de ingestão de conexão estrangeira:

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

Fontes de ingestão de catálogo estrangeiro:

Todas as fontes de dados da Federação Lakehouse são compatíveis com a ingestão de catálogos externos. Para ver a lista completa, consulte Lakehouse Federation.

Interfaces com suporte

Você pode usar a interface do usuário Azure Databricks ou pacotes de automação declarativa para criar pipelines baseados em consulta.

Requisitos de computação

Os pipelines de ingestão baseados em consulta são executados na computação sem servidor por padrão. Há suporte para computação clássica na Versão Beta, mas apenas usando APIs. O Databricks recomenda o uso de computação sem servidor.

Para usar conectores baseados em consulta com computação sem servidor, seu ambiente de computação deve permitir a conectividade de rede com o banco de dados de origem. Consulte rede de rede e as recomendações de rede para a Federação Lakehouse.

Modos de controle de histórico (SCD)

Os conectores baseados em consulta dão suporte aos seguintes modos de rastreamento de histórico, também conhecidos como modos SCD (dimensão de alteração lenta), para tabelas de destino:

  • SCD_TYPE_1: substitui a linha existente na tabela de destino com a linha de origem mais recente. Nenhuma história é preservada.
  • SCD_TYPE_2: preserva o histórico completo de alterações de linha adicionando novas linhas com metadados de versão. Consulte Habilitar acompanhamento de histórico (SCD tipo 2).
  • APPEND_ONLY: acrescenta todas as linhas ingeridas à tabela de destino sem mesclar ou substituir.

Evolução do esquema

Conectores baseados em consulta lidam com a evolução do esquema da mesma maneira que outros conectores gerenciados no Lakeflow Connect. Veja como os conectores gerenciados lidam com a evolução do esquema?.