Compartilhar via

Atualização completa para tabelas de streaming

Uma atualização completa de uma tabela de streaming descarta todos os dados e metadados existentes e reinicia o fluxo desde o início. Especificamente, ele trunca a tabela de streaming, remove todos os dados de ponto de verificação e reinicia o processo de streaming com novos pontos de verificação para cada gravação de fluxo na tabela. Esta página descreve quando você pode ser obrigado a executar uma atualização completa e o impacto da execução de uma atualização completa. Ele também inclui as práticas recomendadas em torno de atualizações completas.

Para obter diretrizes sobre como disparar uma atualização completa, consulte Executar uma atualização de pipeline.

Impacto nas fontes de dados

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

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

Observação

Atualizações completas não são recomendadas para cargas de trabalho de streaming de alto volume ou quando a retenção upstream impede a reprodução de dados históricos.

Se a tabela de streaming tiver tabelas downstream dependentes, o pipeline falhará até que essas tabelas também sejam totalmente atualizadas, a menos que a tabela de streaming tenha skipChangeCommits habilitado. Visões materializadas downstream também devem ser totalmente atualizadas.

Quando executar uma atualização completa

As atualizações completas nos Pipelines Declarativos do Lakeflow Spark devem ser disparadas explicitamente. Você pode executar uma atualização completa clicando em Atualização Completa na interface do usuário do pipeline ou habilitando a atualização completa automática no Lakeflow Connect.

Uma atualização completa é recomendada quando as alterações impedem que uma consulta de streaming seja retomada com segurança de seu ponto de verificação existente ou quando os dados processados anteriormente se tornam 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 feitas no esquema

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

  • Renomeando colunas sem o modo de mapeamento de coluna habilitado.
  • Alterando colunas de deduplicação.
  • Modificando tipos de dados de coluna, incluindo:
    • Restrição de tipo (por exemplo, BIGINT → INT ou DOUBLE → FLOAT).
    • Alterações de tipo incompatíveis (por exemplo, STRING → INT).
  • Exclusão rígida de colunas do esquema de tabela.

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

Alterações no layout de dados físicos

As seguintes alterações de layout de dados físicos exigem uma atualização completa:

  • Migrando do particionamento herdado para um novo esquema de clustering.

Alterações na origem a montante

As seguintes alterações de origem upstream exigem uma atualização completa:

  • Modificando as tabelas de origem lidas pela consulta de streaming.
  • Alternar entre tipos de origem (por exemplo, Kafka para Delta ou Carregador Automático para Kafka).
  • Alterando os locais de origem, como caminhos das tabelas ou assinaturas de tópicos do Kafka.
  • Descartando e recriando uma tabela Delta de origem, mesmo quando o esquema permanece inalterado.

Alterações de processamento de estado

As seguintes alterações de processamento com estado exigem uma atualização completa:

  • Modificando chaves de agrupamento de agregação ou funções de agregação.
  • Adicionando ou removendo agregações.
  • Alterando chaves de junção ou tipos de junção.
  • Adicionando ou removendo junções.
  • Modificando colunas de deduplicação ou lógica de deduplicação.

Problemas de continuidade de dados

Uma atualização completa pode ser necessária quando a continuidade dos dados é comprometida:

  • Os logs CDC ficaram indisponíveis devido à expiração do período de retenção.
  • Corrupção ou exclusão do diretório de ponto de verificação de streaming.
  • Corrupção ou perda de arquivos de rastreamento ou localização de esquema.

Para obter mais informações sobre como recuperar um pipeline após uma falha de ponto de verificação, consulte Recuperar um pipeline após uma falha de ponto de verificação em streaming.

Limitações

As limitações a seguir se aplicam a atualizações completas. Consulte as práticas recomendadas para obter informações para ajudar a trabalhar dentro dessas limitações.

  • Uma atualização completa não reprocessa dados, a menos que sua fonte mantenha o conjunto de dados histórico completo.
  • Grandes conjuntos de dados podem tornar as atualizações completas caras e demoradas.
  • Os consumidores downstream que dependem da tabela podem falhar ou retornar resultados incompletos até que a atualização seja concluída.

Práticas recomendadas

Situação Práticas recomendadas
Design para estabilidade Planeje seu esquema para evitar alterações que exijam uma atualização completa. A adição de colunas geralmente é segura, enquanto modificar colunas existentes ou esquemas de particionamento normalmente requer a recompilação da tabela.
Transmitir de fontes com curtos períodos de retenção Transmitir de fontes, como um tópico Kafka, que não têm longos períodos de retenção significa que uma atualização completa perde dados que não estão mais na fonte.
Para evitar a perda de dados históricos, transmita dados brutos para uma tabela de fluxo contínuo (uma tabela de bronze, na arquitetura de medalhão). Use tipos de coluna flexíveis (variante ou cadeia de caracteres, por exemplo), para evitar que essa tabela exija uma atualização completa se os dados upstream forem alterados. Essa tabela pode armazenar dados históricos e ser usada por tabelas de streaming downstream (que podem ter tipos mais rigorosos ou outras alterações estruturais). Se as tabelas downstream exigirem uma atualização completa, essa tabela terá dados históricos, sem exigir uma atualização completa em si.
Considere alternativas antes de executar uma atualização completa As alternativas incluem:
  • Se estiver alterando a origem de um fluxo, considere criar um novo fluxo em vez de atualizar o fluxo existente de uma tabela de streaming. 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 streaming e usar uma exibição para unir as tabelas de streaming antigas e novas.
Quando uma atualização completa é necessária Siga estas práticas recomendadas quando uma atualização completa for necessária:
  • Teste a operação em um ambiente de desenvolvimento ou preparo.
  • Documente dependências downstream afetadas.
  • Agende a atualização durante uma janela de manutenção para minimizar o impacto nas cargas de trabalho de produção.
  • Verifique se o sistema de origem retém dados históricos suficientes para reproduzir o fluxo.

Para preencher os dados após uma atualização completa, você pode criar um append oncefluxo. Isso realiza um backfill por uma única vez sem continuar após o primeiro backfill. O código permanece no pipeline e, se o pipeline for totalmente atualizado novamente, o backfill será executado novamente.

  • Last updated on