Manter o pipeline de ingestão do site SQL Server
Esta página descreve as operações em andamento para manter o pipeline de ingestão do SQL Server.
Manutenção geral do site pipeline
As tarefas de manutenção do site pipeline nesta seção se aplicam a todos os conectores gerenciáveis em LakeFlow Connect.
Totalmente refresh tabelas de destino
A atualização completa da ingestão pipeline limpa os dados e o estado das tabelas de destino e, em seguida, reprocessa todos os registros da fonte de dados. O senhor pode acessar totalmente refresh todas as tabelas no site pipeline ou selecionar tabelas para refresh.
- Na barra lateral do site Databricks workspace, clique em pipeline .
- Selecione o pipeline.
- Na página de detalhes do pipeline, clique em Full refresh all (Atualizar tudo ) ou clique em Select tables for refresh (Selecionar tabelas para atualização ), selecione as tabelas desejadas e clique em Full refresh selection (Seleção de atualização completa) .
A atualização do pipeline de ingestão pode falhar durante a fase Initializing ou Resetting tables. LakeFlow Connect tentará acessar novamente o site pipeline automaticamente várias vezes. Se as tentativas automáticas forem interrompidas manualmente ou eventualmente falharem fatalmente, comece a nova atualização do pipeline manualmente com a tabela refresh selecionada anteriormente. Não fazer isso pode fazer com que as tabelas de destino sejam deixadas em um estado inconsistente com dados parciais. Se as tentativas manuais também falharem, crie um ticket de suporte.
Alterar a ingestão pipeline programar
- Na barra lateral do site Databricks workspace, clique em pipeline .
- Selecione o endereço pipeline e clique em programar .
Personalizar alertas e notificações
LakeFlow Connect configura automaticamente as notificações para todos os pipelines de ingestão e trabalhos de programação. O senhor pode personalizar as notificações na interface do usuário ou usando o pipeline API.
- UI
- API
- No painel esquerdo, clique em pipeline .
- Selecione seu pipeline.
- Clique em programar .
- Se o senhor já tiver um programar para o qual deseja receber notificações: a. Identifique o programar na lista. a. Clique no menu kebab e, em seguida, clique em Editar. a. Clique em Mais opções e adicione suas notificações.
- Se o senhor precisar de um novo programar: a. Clique em Add programar . a. Configure seu programa. a. Clique em Mais opções e adicione suas notificações.
Consulte Notificações no PUT /api/2.0/pipeline/{{pipeline_id} documentação.
Especificar tabelas a serem ingeridas
O pipeline API fornece dois métodos para especificar as tabelas a serem ingeridas no campo objects do ingestion_definition:
- Especificação de tabela: ingere uma tabela individual do catálogo e esquema de origem especificados para o catálogo e esquema de destino especificados.
- Especificação do esquema: ingere todas as tabelas do catálogo e do esquema de origem especificados no catálogo e no esquema especificados.
Se optar por ingerir um esquema inteiro, o senhor deve analisar as limitações do número de tabelas por pipeline para o seu conector.
CLI comando
Para editar o site pipeline, execute o seguinte comando:
databricks pipelines update --json "<<pipeline_definition OR json file path>"
Para obter a definição do site pipeline, execute o seguinte comando:
databricks pipelines get "<your_pipeline_id>"
Para excluir o site pipeline, execute o seguinte comando:
databricks pipelines delete "<your_pipeline_id>"
Para obter mais informações, o senhor pode sempre executar o seguinte comando:
databricks pipelines --help
databricks pipelines <create|update|get|delete|...> --help
Remover arquivos de teste não utilizados
Para o pipeline de ingestão criado após 6 de janeiro de 2025, os dados de preparação de volume são automaticamente programados para exclusão após 25 dias e fisicamente removidos após 30 dias. Um pipeline de ingestão que não foi concluído com êxito por 25 dias ou mais pode resultar em lacunas de dados nas tabelas de destino. Para evitar lacunas, o senhor deve acionar um refresh completo das tabelas de destino.
Para o pipeline de ingestão criado antes de 6 de janeiro de 2025, entre em contato com o suporte Databricks para solicitar a ativação manual do gerenciamento automático de retenção para a preparação de dados CDC.
Os seguintes dados são automaticamente limpos:
- Arquivos de dados do CDC
- Snapshot arquivos
- Preparando dados da tabela
Reinicie o gateway de ingestão
Para diminuir a carga no banco de dados de origem, o gateway de ingestão só verifica periodicamente se há novas tabelas. Pode levar até 6 horas para que novas tabelas sejam descobertas. Se você quiser acelerar esse processo, reinicie o gateway.
Comportamento refresh completa
Ao acionar uma refresh completa de uma tabela, Databricks otimiza o processo para reduzir o tempo de inatividade e manter a disponibilidade dos dados:
- SolicitaçãoSnapshot : Quando você solicita uma refresh completa, o gateway de ingestão começa imediatamente a criar um novo instantâneo da tabela de origem. A tabela de transmissão de destino é excluída da seleção refresh até que o Snapshot seja concluído.
- Disponibilidade contínua : Durante o processo de Snapshot, a tabela de transmissão de destino mantém seus dados existentes e permanece disponível para consultas. Nenhuma atualização, acréscimo ou exclusão é aplicada à tabela enquanto o Snapshot estiver em andamento.
- refreshatômica : Após a conclusão do Snapshot, Databricks realiza automaticamente a refresh completa em uma única operação. Esta atualização aplica todos os dados do Snapshot e quaisquer registros CDC acumulados desde que o Snapshot foi solicitado.
Por exemplo, se sua tabela tiver 50 registros ao final da atualização 15 e você solicitar uma refresh completa na atualização 16:
- O gateway de ingestão começa a criar um Snapshot durante a atualização 16.
- A tabela continua mostrando os 50 registros originais até que o Snapshot seja concluído.
- Quando o Snapshot for concluído (na atualização 16 ou posterior, dependendo do tamanho da tabela de origem), a refresh completa será aplicada automaticamente em uma única operação atômica.
Essa abordagem reduz significativamente o tempo de inatividade durante operações refresh completa e ajuda a evitar erros PENDING_RESET e de tempo limite excedido.