Migrar um projeto para o Lakehouse v2

Pode mover um projeto de cada vez do Lakehouse v1 para o Lakehouse v2. Os outros projetos da mesma área de trabalho continuam a funcionar na v1 até os migrar também, pelo que pode migrar um único projeto e deixar tudo o resto como está.

A migração move as tabelas do projeto e tudo o que se baseia nelas: consultas, expressões, vistas, conjuntos de dados do Superset, colunas calculadas, indicadores e regras de acesso a linhas.

Antes de começar

Migrar projeto para o Lakehouse v2… aparece no menu Ferramentas para os membros que podem editar projetos. Apenas os Arquitetos de um projeto o podem migrar: iniciar, agendar, cancelar e anular uma migração requerem acesso de Arquiteto ao projeto.
Precisa de acesso de Arquiteto ao projeto, e o projeto tem de estar desbloqueado.
O seu plano precisa de ter espaço para a cópia. Consulte Verificação de armazenamento.
Qualquer pessoa que consiga abrir um projeto pode executar a verificação de prontidão.
Execute primeiro a verificação de prontidão e resolva tudo o que ela recusar. Uma migração iniciada num projeto que não consegue traduzir é interrompida a meio.
Planeie que o projeto fique indisponível durante toda a execução, porque as escritas durante a execução perdem-se.
Se outros projetos leem as tabelas deste projeto através de uma partilha de dados, migre primeiro esses projetos ou remova a partilha. Um projeto que outros leem através de uma partilha de dados é migrado depois deles.

Verificar a preparação da migração

A verificação de prontidão indica o que acontecerá ao projeto antes de assumir qualquer compromisso. Não altera nada.

Abra o menu Ferramentas.
Selecione Verificar a preparação da migração….
Selecione o projeto.

Se o projeto já estiver no Lakehouse v2, a verificação indica-o e informa que não há nada a migrar.

O relatório apresenta cada área com um dos seguintes estados:

Estado	Significado
Limpar	O PlaidCloud analisou a área e não encontrou nada.
Requer revisão	Algo vai mudar, e deve reconhecê-lo antes da execução.
Bloqueado	A migração não pode começar até isto ser resolvido.
Verificado durante a migração	A área é verificada enquanto a migração decorre, pelo que nunca é apresentada como limpa de antemão.

As áreas são tabelas, vistas, passos, painéis de controlo, partilhas de dados e capacidade. Cada constatação inclui uma explicação em linguagem simples e, quando existe, é apresentada uma reescrita sugerida.

O que a verificação de prontidão recusa

Recusa	Motivo
Uma coluna cujo tipo não tem equivalente no Lakehouse v2	A migração recusa, em vez de converter silenciosamente a coluna em texto. Altere o tipo da coluna no projeto e execute novamente a verificação.
Não é possível resolver o armazém de destino do Lakehouse v2	O lakehouse v2 da área de trabalho não está visível para o serviço que executa a migração. Trata-se de um problema administrativo, que não pode resolver no projeto.
Não é possível confirmar a proteção contra eliminação no bucket de armazenamento	O período de anulação depende dela, pelo que a migração não começa sem ela.

As colunas JSON migram. As versões anteriores recusavam-nas; agora são suportadas.

Verificação de armazenamento

Antes de uma execução começar, o PlaidCloud verifica se o seu plano tem espaço para a cópia.

Num plano com limite de armazenamento, a execução é recusada se a cópia migrada não couber. As outras migrações em curso contam para o limite.
Num plano faturado por armazenamento adicional, a execução começa com um aviso do excedente previsto.

Experimentar na v2

Experimentar na v2… cria uma cópia de avaliação privada do projeto no Lakehouse v2, para que possa verificar os resultados antes de migrar o projeto real. Na cópia de avaliação, os agendamentos e os sensores estão desativados e o lançamento em ERP está em modo de simulação. Os passos que escrevem fora do PlaidCloud, como SFTP, correio eletrónico e publicações REST, são listados como aviso antes de confirmar. Iniciar avaliação cria a cópia. Um projeto que já tenha uma avaliação oferece Abrir avaliação existente e Substituir avaliação….

Executar a migração

Abra o menu Ferramentas.
Selecione Migrar projeto para o Lakehouse v2…. A janela lista as execuções de migração da área de trabalho.
Inicie uma nova execução e selecione o projeto.
Leia o relatório de prontidão apresentado na janela e reconheça cada constatação indicada. Aceitar uma constatação aplica-se apenas a esse item específico.
Selecione Iniciar migração ou marque Iniciar a uma hora agendada, defina a hora e selecione Agendar migração. Uma migração agendada apresenta uma faixa no projeto, e pode cancelá-la antes de começar. Quando começa, o PlaidCloud volta a verificar a prontidão, a compatibilidade, a capacidade e as suas permissões.
Inicie a execução. A caixa de diálogo de progresso mostra cada tabela à medida que é copiada e verificada. Os agendamentos de fluxos de trabalho ativos do projeto ficam em pausa durante a execução. Pode fechar a caixa de diálogo e voltar a abri-la a partir da lista de execuções; a execução continua em ambos os casos.

Quando uma execução está a mudar o projeto para o Lakehouse v2, não pode ser interrompida. Se a própria mudança falhar a meio, a execução mostra Contact support. Don’t retry. em vez de oferecer Retomar. Contacte o suporte e deixe a execução como está.

Quando a execução termina, o projeto fica associado ao Lakehouse v2, as consultas passam a utilizá-lo e os agendamentos em pausa são repostos. Um agendamento que tenha editado ou eliminado durante a migração fica como o deixou e é indicado no relatório. A cópia original do Lakehouse v1 é mantida, indisponível para o projeto, durante o período de anulação. É notificado, por mensagem e por correio eletrónico, quando uma migração termina ou falha.

Uma migração falhada

Uma migração falhada mostra o motivo da falha e a hora a partir da qual as escritas na origem se perdem. Selecione Retomar para a continuar. As vistas que não podem ser executadas no Lakehouse v2 são ignoradas e listadas, em vez de interromperem a execução.

O que foi alterado

Após uma migração, abra O que foi alterado… para a execução. Lista cada tabela como copiada, copiada com uma lacuna indicada, ignorada ou falhada, com contagens de linhas e motivos, as vistas que foram ignoradas, as tabelas criadas ou eliminadas na origem durante a execução e os agendamentos que foram colocados em pausa e repostos.

O agrupamento semanal desloca-se um dia

O Lakehouse v2 começa as semanas ao domingo. O Lakehouse v1 começava-as à segunda-feira.

Tudo o que é agrupado por semana muda em conformidade, sem erro nem aviso. Uma linha datada de domingo, 14 de junho, pertencia à semana que começa na segunda-feira, 8 de junho, na v1. Na v2, pertence à semana que começa no domingo, 14 de junho.

Os totais de um lado e do outro dessa fronteira mudam. Um gráfico semanal, uma tabela de resumo semanal e um relatório agrupado por semana continuam todos a funcionar e mostram todos números diferentes dos anteriores. Verifique qualquer valor semanal em que se baseie depois de migrar e conte com uma deslocação de um dia, e não com um erro.

O que não é transferido

Os seus dados migram. Algumas coisas construídas sobre o motor antigo, e alguns detalhes da forma como as colunas foram declaradas, não migram.

Item	O que acontece
Histórico de instantâneos, viagem no tempo e flashback	Não transferidos. As tabelas migradas começam com um histórico novo, pelo que não é possível consultar o projeto num momento anterior à migração.
Ramos e etiquetas de tabelas	Os ramos e etiquetas existentes não são transferidos.
Limites de comprimento `VARCHAR(n)`	O limite de comprimento é removido. As colunas de texto passam a texto sem restrições; os valores existentes não são afetados.
Larguras de inteiros reduzidas	Os tipos inteiros pequenos passam a inteiros de 32 bits. Os valores não são afetados.
Precisão de frações de segundo em timestamps	Uma precisão declarada é removida.
Colunas espaciais, de geometria e bitmap	Migradas, mas excluídas da comparação automática de valores — verifique-as por si.
Colunas binárias, de array e de mapa	Migradas, mas excluídas da comparação automática de valores — verifique-as por si.
Colunas JSON	Migradas com os tipos mantidos. Um número dentro de JSON demasiado grande para armazenamento exato é guardado com precisão dupla e indicado no relatório.

Anular uma migração

Durante o período de anulação após a conclusão de uma execução, os dados originais do Lakehouse v1 são mantidos intactos, mas desassociados do projeto. Anular migração… devolve o projeto ao Lakehouse v1 nesse período. Precisa de acesso de Arquiteto ao projeto.

A anulação pede-lhe que escreva o nome do projeto para confirmar. Todas as alterações feitas ao projeto desde a mudança para o Lakehouse v2 perdem-se. O progresso é apresentado enquanto a anulação decorre. Se a anulação for recusada, o motivo é indicado, por exemplo, que o período de anulação terminou.

Utilize-a se os resultados parecerem incorretos após a migração — exceto os valores semanais, que se espera que mudem.

Depois do período de anulação, os dados originais são eliminados e a migração é definitiva.

Após a migração

As sessões que já estavam abertas continuam a ler a cópia com que começaram até terminarem. Uma sessão de aplicação Panel de longa duração, em particular, continua a servir os dados antigos até ser reiniciada. Reinicie as sessões de longa duração após uma migração para que passem a usar o Lakehouse v2.