Retroceder e reproduzir um pipeline

Uma transformação incorreta, um lote malformado de registos de origem ou uma alteração inesperada do esquema podem deixar incorretas as tabelas de um pipeline desde um ponto conhecido no tempo em diante. Faz recuar o pipeline até um ponto anterior à ocorrência do problema, para que possa aplicar uma correção e reprocessar apenas os dados afetados.

O Rewind restaura, em simultâneo, versões da tabela, offsets da origem de streaming e o estado do operador, para que o reprocessamento não ignore registos nem escreva duplicados. Três operações reprocessam dados e resolvem diferentes problemas:

• Rewind destina-se a um pipeline passível de recuperação que gravou dados incorretos a partir de um determinado momento conhecido, por exemplo após uma transformação incorreta, uma entrada malformada ou uma má distribuição de código. Restaura os dados da tabela, os deslocamentos de origem e o estado do operador para um ponto anterior ao problema e reprocessa apenas os dados afetados, mantendo o estado do operador. Os dados anteriores a esse ponto permanecem intactos.
• A atualização completa reconstrói uma tabela a partir de todos os dados de origem disponíveis e descarta o seu conteúdo atual. Usa-o para recalcular tudo do zero, ou quando uma alteração de código não for compatível com o estado existente.
• A redefinição do checkpoint permite recuperar um pipeline cujo checkpoint é inválido ou está corrompido, ou que está bloqueado por uma alteração de código incompatível com o checkpoint. Reinicia o ponto de controlo e continua em frente, preservando o conteúdo atual da tabela. O Rewind não pode recuperar estes casos, porque não relaxa as regras de compatibilidade do Structured Streaming.

Requisitos

Cada fluxo no oleoduto deve cumprir estes requisitos. Enquanto pipelines.rewind.betaEnabled é true, um pipeline que contém um fluxo que não cumpre os critérios falha nas suas atualizações. Confirme que cada fluxo cumpre os requisitos acima antes de o ativar.

Como funcionam o retrocesso e a repetição

Rebobinar e reproduzir novamente são passos separados.

Rewind restaura cada tabela para a versão que tinha num ponto de Rewind e reinicia os checkpoints de streaming que acompanham até onde cada fluxo leu. As suas transformações não são executadas, e nenhum dado de origem é reprocessado.

A repetição acontece na próxima vez que o pipeline é executado. Reprocessa a partir do ponto de retrocesso usando a definição atual do pipeline, recupera o presente e depois retoma o processamento incremental normal. Rewind não inicia o pipeline, por isso, inicia-o tu mesmo quando estiveres pronto.

A canalização gera pontos de reversão automaticamente, cerca de uma vez por hora, e mantém-nos durante 7 dias. Uma canalização que acabaste de criar não tem para onde recuar até produzir a primeira.

Rebobinar um conjunto de dados também rebobina tudo o que está a jusante no mesmo pipeline. Rebobinar cobre um oleoduto. Não coordena com outros pipelines nem com leitores externos das mesmas tabelas, por isso trate esses casos separadamente.

Repor um pipeline através da interface de utilizador

A interface e o Genie são as principais formas de usar o rewind. A interface lista os pontos de reversão disponíveis e mostra que conjuntos de dados cada um afeta antes de confirmar.

1. Na página do pipeline, clique no botão ao lado de Executar pipeline e, em seguida, clique em Recuar pipeline.
2. Selecione um ponto de rebobinado, ou use um atalho como Rebobinar até ontem ou Rebobinar até ao ponto mais recente. Clique em Next.
3. Selecione quais as tabelas a incluir. Utilize a vista Graph para selecionar conjuntos de dados no grafo do pipeline, ou a vista List para selecioná-los numa tabela. Deixe Repor todos os checkpoints selecionado (a opção predefinida) para restaurar os offsets da origem e o estado do operador, juntamente com os dados da tabela, para que a canalização reprocesse a partir do ponto de retrocesso. Limpe-o para restaurar apenas os dados da tabela, sem reprocessamento, por exemplo quando quiser restaurar o conteúdo de uma tabela mas não quiser reprocessar os dados afetados. Esta configuração deve ser a mesma para uma tabela e os seus upstreams, e não pode ser liberada para um fluxo que leia uma fonte externa como Kafka ou Auto Loader. Clique em Next.
4. Revise o ponto de rebobinar, a definição do ponto de controlo e os conjuntos de dados afetados, depois clique em Rebobinar.

Inicie o pipeline para reprocessar os dados.

Pode retroceder as vezes que quiser. Cada rebobinagem substitui a anterior, para que possas recuperar de uma repetição que falhou rebobinando noutro ponto.

Após um recuo

Uma falha na repetição deixa o oleoduto rebobinado mas parado. Corrija o código ou os dados de origem e inicie o pipeline para repetir a tentativa, ou retroceda até um ponto diferente. O pipeline não reverte automaticamente, e os erros são apresentados através dos diagnósticos padrão do pipeline e do registo de eventos.

A reexecução só é bem-sucedida se a definição atual do pipeline for compatível com o estado restaurado; o recuo não flexibiliza as regras de compatibilidade do Structured Streaming. Para quais alterações são compatíveis, veja Tipos de alterações nas consultas de Streaming Estruturado. As vistas materializadas seguem semântica em lote e toleram alterações de esquema mais amplas, mas ainda falham se uma dependência for incompatível.

Um retrocesso que falha parcialmente pode deixar o oleoduto parcialmente rebobinado. Tem duas opções:

1. Retroceda novamente até ao mesmo ponto ou a outro diferente, e o pipeline converge nesse ponto.
2. Para forçar o pipeline a iniciar uma atualização normal apesar da reversão incompleta, defina pipelines.allowUpdateAfterIncompleteRewind como true e reinicie o pipeline.

Até onde podes recuar

Os pontos de retrocesso são mantidos durante 7 dias. Nessa janela, uma reversão falha se os dados de que necessita já tiverem sido removidos. Verifique estes antes de recorrer ao rewind:

• VACUUM ou um breve delta.deletedFileRetentionDuration nas suas mesas. Ver Trabalhar com histórico de tabelas.
• Retenção na origem mais curta do que a janela temporal para a qual pretende recuar, como um tópico Kafka que retém dados durante um dia.

Pipelines com várias fontes ou cadeias de dependências longas precisam de um período de retenção maior, porque cada tabela e ponto de verificação tem de remeter para um ponto consistente.

Limitações

• Não é possível recuar para restaurar um pipeline para um ponto anterior a uma atualização completa.
• Os pontos de reversão são mantidos durante 7 dias, e a reversão falha se o histórico da tabela ou os dados de origem necessários para regressar a esse ponto já tiverem sido removidos, por exemplo, por VACUUM ou por um período de retenção curto dos dados de origem. Vê até onde consegues recuar.
• O modo em tempo real não é suportado.
• Kinesis, Pulsar, Google Pub/Sub e fontes personalizadas construídas com as APIs de fontes de dados DSv2 ou Python não são suportadas como fontes.
• Sumidouros externos e personalizados não são suportados, incluindo sumidouros definidos com create_sink(). Veja Usar sumidouros em oleodutos.
• As tabelas em fluxo que usam um filtro de linha ou uma máscara de coluna não podem ser reiniciadas. Consulte Aplicar manualmente filtros de linha e máscaras de coluna.
• O retrocesso com preservação de estado requer o armazenamento de estado RocksDB, que os pipelines utilizam por predefinição. Um retrocesso falha num fluxo configurado com um armazenamento de estado diferente.
• Algumas tabelas de transmissão em fluxo AUTO CDC precisam de uma atualização antes de poderem ser reiniciadas. O pipeline notifica-o quando solicita o retrocesso.
• As vistas materializadas podem ser totalmente recalculadas em vez de serem atualizadas de forma incremental após uma reversão. Consulte Atualização incremental para ver vistas materializadas.
• Rewind abrange um pipeline e não se coordena com leitores externos nem com outros pipelines que estão a ler as mesmas tabelas.
• O Rewind não restaura o código do pipeline, a configuração do pipeline ou os metadados dos objetos do Unity Catalog, como etiquetas e concessões.

Recursos adicionais

• Recuperar um pipeline de uma falha no ponto de verificação de streaming
• Atualização completa para tabelas de streaming
• Como é que os pipelines se atualizam?
• Executar uma atualização do pipeline
• Trabalhar com o histórico da tabela