Atualização completa para tabelas em streaming

Uma atualização completa de uma tabela de streaming descarta todos os dados e metadados existentes e reinicia o fluxo do início. Especificamente, trunca a tabela de fluxo contínuo, remove todos os dados de pontos de verificação e reinicia o processo de streaming com novos pontos de verificação para cada fluxo que realiza gravação na tabela. Esta página descreve quando poderá ser necessário executar uma atualização completa e o impacto de executar uma atualização completa. Inclui também boas práticas relativas a atualizações completas.

Para orientações sobre como desencadear uma atualização completa, veja Executar uma atualização do pipeline.

Impacto nas fontes de dados

Uma atualização completa remove todos os dados existentes da tabela de streaming. 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 tornar-se irrecuperáveis após uma atualização completa.

Por exemplo, se a sua fonte for Kafka com retenção de 24 horas e fizer uma atualização completa após essa janela, mensagens antigas já não estão disponíveis e não podem ser reprocessadas.

Se a tabela de streaming tiver tabelas dependentes a jusante, o pipeline falha até que essas tabelas também sejam totalmente atualizadas, a menos que a tabela de streaming tenha o skipChangeCommits ativado. As vistas materializadas a jusante também devem ser totalmente atualizadas.

Quando fazer uma atualização completa

As atualizações totais nos Lakeflow Spark Declarative Pipelines devem ser ativadas de forma explícita. Pode executar uma atualização completa clicando em Atualização Completa na interface do pipeline ou ativando a atualização completa automática no Lakeflow Connect.

Recomenda-se uma atualização completa quando as alterações impedem que uma consulta em streaming retome em segurança a partir do seu checkpoint existente, ou quando os dados previamente processados se tornam inconsistentes com a lógica, esquema ou configuração de origem atualizados. As secções seguintes descrevem cenários comuns.

Alterações de esquema

As seguintes alterações de esquema na tabela alvo não são retrocompatíveis e requerem uma atualização completa:

• Renomear colunas sem o modo de mapeamento de colunas ativado.
• Alterar colunas de deduplicação.
• Modificação dos tipos de dados das colunas, incluindo:
  • Estreitamento de tipo (por exemplo, BIGINT → INT ou DOUBLE → FLOAT).
  • Alterações de tipo incompatíveis (por exemplo, STRING → INT).
• Eliminação forçada das colunas do esquema da tabela.

Para este tipo de alterações de esquema, a Databricks recomenda criar uma nova coluna com o esquema ou nome desejado, e depois usar uma vista no topo da tabela de streaming para unir os valores antigos e novos.

Alterações na disposição física dos dados

As seguintes alterações no layout físico dos dados requerem uma atualização completa:

• Migrar da partição antiga para um novo esquema de agrupamento.

Alterações da fonte a montante

As seguintes mudanças na fonte upstream requerem uma atualização completa:

• Modificar as tabelas de origem lidas pela consulta de streaming.
• Alternar entre tipos de fonte (por exemplo, Kafka para Delta ou Auto Loader para Kafka).
• Alterar a localização das fontes, como caminhos de tabelas ou subscrições de tópicos Kafka.
• Remover e recriar uma tabela Delta de origem, mesmo quando o esquema permanece inalterado.

Alterações no processamento de estado

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

• Modificação de chaves de agrupamento ou funções de agregação.
• Adicionar ou remover agregações.
• Alterar chaves ou tipos de junção.
• Adicionar ou remover junções.
• Modificar colunas de deduplicação ou lógica de deduplicação.

Problemas de continuidade de dados

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

• Os registos do CDC tornaram-se indisponíveis devido à expiração da retenção.
• Corrupção ou exclusão do diretório de pontos de verificação de fluxo contínuo.
• Corrupção ou perda de ficheiros de seguimento ou localização de esquema.

Para obter mais informações sobre como recuperar um pipeline após uma falha de checkpoint, consulte Recuperar um pipeline após falha de checkpoint de streaming.

Limitações

As seguintes limitações aplicam-se às atualizações completas. Consulte Melhores Práticas para obter informações que ajudem a trabalhar dentro destas limitações.

• Uma atualização completa não reprocessa dados a menos que a sua fonte mantenha todo o conjunto de dados histórico.
• Grandes conjuntos de dados podem tornar as atualizações completas dispendiosas e demoradas.
• Os utilizadores finais que dependem da tabela podem falhar ou devolver resultados incompletos até que a atualização termine.

Melhores práticas

Para preencher dados após uma atualização completa, podes criar um append oncefluxo. Este realiza um backfill único sem continuar a funcionar após o primeiro backfill. O código permanece no seu pipeline e, se o pipeline for completamente atualizado novamente, o backfill é reexecutado.