refresh completa para tabelas de transmissão

Uma refresh completa de uma tabela de transmissão descarta todos os dados e metadados existentes e reinicia a transmissão desde o início. Especificamente, ele trunca a tabela de transmissão, remove todos os dados de ponto de verificação e reinicia o processo de transmissão com novos pontos de verificação para cada fluxo que grava na tabela. Esta página descreve quando pode ser necessário executar uma refresh completa e o impacto dessa refresh. Inclui também as melhores práticas para uma atualização completa.

Para obter orientações sobre como acionar uma refresh completa, consulte a seção sobre como executar uma atualização pipeline.

Impacto na fonte de dados

Uma refresh completa remove todos os dados existentes da tabela de transmissão. Se a sua fonte de dados tiver limites de retenção — como tópicos Kafka com períodos de retenção curtos — alguns dados históricos podem se tornar irrecuperáveis após uma refresh completa.

Por exemplo, se sua fonte for Kafka com retenção de 24 horas e você executar uma refresh completa após esse período, as mensagens mais antigas não estarão mais disponíveis e não poderão ser reprocessadas.

nota

A atualização completa não é recomendada para cargas de trabalho de transmissão de alto volume ou quando a retenção upstream impede a reprodução de dados históricos.

Se a tabela de transmissão tiver tabelas downstream dependentes, o pipeline falhará até que essas tabelas também sejam totalmente atualizadas, a menos que a opção skipChangeCommits esteja habilitada na tabela de transmissão. A visão materializada a jusante também deve ser totalmente atualizada.

Quando executar uma refreshcompleta

A atualização completa do pipeline declarativo LakeFlow Spark deve ser acionada explicitamente. Você pode executar uma refresh completa clicando em "Atualização completa" na interface do pipeline ou ativando refresh completa automática no LakeFlow Connect.

Recomenda-se uma refresh completa quando as alterações impedem que uma consulta de transmissão seja retomada com segurança a partir do seu ponto de verificação atual, ou quando os dados processados anteriormente se tornariam inconsistentes com a lógica, o esquema ou a configuração de origem atualizados. As seções a seguir descrevem cenários comuns.

Alterações de esquema

As seguintes alterações de esquema na tabela de destino não são compatíveis com versões anteriores e exigem uma refresh completa:

• Renomear colunas sem o modo de mapeamento de colunas ativado.

• Alterando colunas de desduplicação.

• Modificação dos tipos de dados das colunas, incluindo:

  • Restrição de tipo (por exemplo, BIGINT → INT ou DOUBLE → FLOAT).
  • Alterações de tipo incompatíveis (por exemplo, STRING → INT).

• Exclusão permanente de colunas do esquema da tabela.

Para esses tipos de alterações de esquema, Databricks recomenda criar uma nova coluna com o esquema ou nome desejado e, em seguida, usar uma view na tabela de transmissão para unir os valores antigos e novos.

Mudanças na disposição de dados físicos

As seguintes alterações na disposição de dados físicos exigem uma refresh completa:

• Migração de um sistema de particionamento legado para um novo esquema clustering .

Alterações na fonte a montante

As seguintes alterações na fonte upstream exigem uma refresh completa:

• Modificando as tabelas de origem lidas pela consulta de transmissão.
• Alternar entre tipos de origem (por exemplo, Kafka para Delta ou Auto Loader para Kafka).
• Alterar locais de origem, como caminhos de tabelas ou inscrição de tópicos Kafka .
• Excluir e recriar uma tabela Delta de origem, mesmo quando o esquema permanece inalterado.

alterações de processamento com estado

As seguintes alterações de processamento com estado exigem uma refresh completa:

• Modificação da chave de agrupamento de agregação ou das funções de agregação.
• Adicionar ou remover agregações.
• Alterar a chave join ou os tipos join .
• Adicionando ou removendo junções.
• Modificar colunas de desduplicação ou a lógica de desduplicação.

problemas de continuidade de dados

Uma refresh completa pode ser necessária quando a continuidade dos dados estiver comprometida:

• logs CDC tornaram-se indisponíveis devido ao vencimento do prazo de retenção.
• Corrupção ou eliminação do diretório do ponto de verificação da transmissão.
• Corrupção ou perda de arquivos de acompanhamento de esquema ou de localização de esquema.

Para obter mais informações sobre como recuperar um pipeline de uma falha de ponto de verificação, consulte Recuperar um pipeline de uma falha de ponto de verificação de transmissão.

Limitações

As seguintes limitações se aplicam à atualização completa. Consulte as Melhores práticas para obter informações que ajudarão a trabalhar dentro dessas limitações.

• Uma refresh completa não reprocessa os dados a menos que sua fonte retenha o dataset histórico completo.
• Um conjunto de dados grande pode tornar a atualização completa dispendiosa e demorada.
• Os consumidores subsequentes que dependem da tabela podem falhar ou retornar resultados incompletos até que a refresh seja concluída.

Melhores práticas

Situação	Práticas recomendadas
Design para estabilidade	Planeje seu esquema para evitar alterações que exijam uma refresh completa. Adicionar colunas geralmente é seguro, enquanto modificar colunas existentes ou esquemas de particionamento normalmente exige o recálculo da tabela.
marketing de fontes com períodos de retenção curtos	Transmissão a partir de fontes, como um tópico Kafka , que não possuem longos períodos de retenção, significa que uma refresh completa perde os dados que ainda não estão na fonte. Para evitar a perda de dados históricos, transmiti dados brutos para uma tabela de transmissão (uma tabela bronze, na arquitetura medalhão). Utilize tipos de coluna flexíveis (variantes ou strings, por exemplo) para evitar que esta tabela precise ser totalmente refresh caso os dados de origem sejam alterados. Esta tabela pode armazenar dados históricos e ser usada por tabelas de transmissão subsequentes (que podem ter tipos mais restritivos ou outras alterações estruturais). Caso as tabelas subsequentes necessitem de uma refresh completa, esta tabela contém dados históricos, sem, no entanto, necessitar de uma refresh completa.
Considere alternativas antes de executar uma refreshcompleta.	Alternativas incluem: Ao alterar a origem de um fluxo, considere criar um novo fluxo em vez de atualizar o fluxo existente em uma tabela de transmissão. Isso preserva os dados existentes na tabela, mas pode gravar dados duplicados porque o novo fluxo tem um novo ponto de verificação. Como alternativa, você pode redefinir o ponto de verificação, mas isso pode levar à gravação de dados duplicados na tabela de destino. Se nenhuma das opções for aceitável, considere criar uma nova tabela de transmissão e usar uma view para unir as tabelas de transmissão antiga e nova.
Quando for necessário um refresh completo	Siga estas boas práticas quando for necessária uma refresh completa: Teste as operações em um ambiente de desenvolvimento ou de teste. Documente as dependências subsequentes afetadas. Programar a refresh durante uma janela de manutenção para minimizar o impacto nas cargas de trabalho de produção. Certifique-se de que o sistema de origem retenha dados históricos suficientes para reproduzir a transmissão.

Para preencher dados retroativamente após uma refresh completa, você pode criar um fluxo append once . Esta função realiza um preenchimento único sem continuar a execução após o primeiro preenchimento. O código permanece no seu pipeline e, se o pipeline for totalmente atualizado novamente, o preenchimento retroativo será executado novamente.