Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Os conectores baseados em consulta no Lakeflow Connect ingerem dados das bases de dados consultando diretamente a fonte, sem necessidade de configuração de captura de dados de alteração (CDC). Em vez de dependerem de binlogs ou infraestrutura CDC, usam uma coluna cursor — uma coluna de carimbo temporal ou inteiro que aumenta monotonamente — para acompanhar quais as linhas que são novas ou atualizadas desde a última execução do pipeline.
Conectores baseados em consulta usam ligações Unity Catalog e Lakehouse Federation para se ligar às bases de dados de origem, e escrevem resultados em tabelas de streaming.
Como funciona
Em cada execução do pipeline, um conector baseado em consultas acessa a base de dados de origem e recupera todas as linhas que contêm um valor na coluna do cursor superior ao valor registado na execução anterior. O conector armazena a marca máxima da coluna do cursor após cada execução bem-sucedida e usa-a como limite inferior na execução seguinte.
Como o conector consulta diretamente a fonte, não requer um gateway de ingestão nem um volume de staging. A pipeline opera num horário que tu defines, não de forma contínua.
Conectores baseados em consulta comparados com conectores de bases de dados CDC
Os conectores baseados em consulta diferem dos conectores de bases de dados CDC das seguintes formas:
- Sem gateway de ingestão: Os conectores CDC requerem um gateway para capturar eventos binlog. Conectores baseados em consulta não usam gateway.
- Sem volume de staging: Os conectores CDC extraem os dados em buffer num volume de staging. Os conectores baseados em consulta escrevem diretamente da consulta de origem para a tabela de destino.
- Programados em vez de contínuos: Conectores baseados em consulta funcionam num calendário. Eles não capturam todos os estados intermédios das linhas entre execuções. Só captam o estado mais recente das filas que mudaram.
- Compatibilidade mais ampla com fonte: Qualquer base de dados com uma coluna de cursor adequada é uma fonte válida, mesmo que não suporte acesso CDC ou binlog.
A desvantagem é que o desempenho das consultas pode ser mais lento e as consultas são executadas diretamente em tabelas de origem, o que pode colocar mais carga na base de dados de origem em comparação com os conectores CDC que consultam o binlog. O rastreamento por deleção suave é suportado usando deletion_condition. O rastreamento de eliminação rígida também é suportado em Beta. Ambos requerem configuração da API.
Abordagens de ingestão suportadas
Conectores baseados em consulta suportam múltiplas abordagens de ingestão. A abordagem que utiliza determina quais os parâmetros de configuração necessários.
| Abordagem | Como se liga | Parâmetros necessários |
|---|---|---|
| Ingestão de conexão externa | Utiliza uma ligação que armazena credenciais de autenticação para a base de dados de origem. O conector utiliza a ligação para consultar diretamente a base de dados de origem. |
connection_name, source_catalog, source_schema, source_table, cursor_column |
| Ingestão de catálogos estrangeiros | Utiliza um catálogo estrangeiro apoiado por uma fonte de dados da Lakehouse Federation . O conector utiliza o catálogo estrangeiro para ler os dados de origem em vez de se ligar diretamente à base de dados de origem. |
ingest_from_uc_foreign_catalog: true, cursor_columns, primary_keys (obrigatório a menos que uses o modo APPEND_ONLY) |
Fontes suportadas
As seguintes fontes de base de dados são suportadas.
Fontes de ingestão de conexão estrangeira:
- Oracle
- Teradata
- SQL Server
- MySQL
- MariaDB
- PostgreSQL
Fontes de ingestão de catálogos estrangeiros:
Todas as fontes de dados da Lakehouse Federation são suportadas através da ingestão de catálogos estrangeiros. Para a lista completa, veja Lakehouse Federation.
Interfaces suportadas
Pode usar a interface do Azure Databricks ou os Declarative Automation Bundles para criar pipelines baseados em consultas.
Requisitos de computação
Pipelines de ingestão baseados em consultas executam por padrão em computação sem servidor. O Classic Compute é suportado em Beta, mas apenas usando APIs. A Databricks recomenda a utilização de computação serverless.
Para usar conectores baseados em consulta com computação sem servidor, o seu ambiente de computação deve permitir a conectividade de rede com a origem da base de dados. Consulte Networking e Recomendações de Networking para a Federação Lakehouse.
Modos de rastreamento de histórico (SCD)
Os conectores baseados em consulta suportam os seguintes modos de acompanhamento de histórico — também conhecidos como modos de dimensão de mudança lenta (SCD) — para tabelas de destino.
- SCD_TYPE_1: Sobrescreve 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 das alterações de linha adicionando novas linhas com metadados de versão. Consulte Ativar rastreamento de histórico (SCD tipo 2).
- APPEND_ONLY: Anexa todas as linhas ingeridas à tabela de destino sem fusão ou sobrescrevimento.
Evolução do esquema
Os conectores baseados em consulta lidam com a evolução do esquema da mesma forma que outros conectores geridos no Lakeflow Connect. Veja Como é que os conectores geridos lidam com a evolução de esquemas?.