Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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 de infraestrutura de CDC, eles usam uma coluna de cursor (uma coluna de carimbo de data/hora ou de inteiro monotonicamente crescente) para rastrear linhas 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 do pipeline, um conector baseado em consulta faz uma consulta no banco de dados de origem e recupera todas as linhas em que o valor da coluna de cursor é maior que a marca d’água máxima da execução anterior. O conector armazena o ponto de referência da coluna do cursor após cada execução com êxito e o utiliza como limite inferior na próxima execução.
Como o conector consulta diretamente a origem, ele não exige um gateway de ingestão ou um volume de preparo. 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 de acordo com uma agenda. 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 rastreamento de exclusão temporária usando deletion_condition.
O rastreamento por exclusão rígida também é suportado no 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
Pipelines de ingestão baseados em consulta rodam por padrão em computação serverless, embora implantações clássicas de computação também sejam suportadas. O Databricks recomenda o uso de computação sem servidor. Veja Criar um pipeline de ingestão baseado em consulta.
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 e Recomendações de rede para a Federação do Lakehouse.
Modos de rastreamento 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. A tabela de destino não preserva nenhum histórico.
- 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?.