Snowpark Migration Accelerator: laboratório de pipeline – avaliação¶

Extração/Disponibilidade do código¶

Os arquivos que usaremos para o Laboratório da AdventureWorks estão aqui:

end_to_end_lab_source_code.zip

Para fins deste laboratório, assumiremos que o notebook e o arquivo de script que estamos convertendo já estão acessíveis como arquivos. Em geral, o SMA recebe arquivos como entrada e não se conecta a nenhuma plataforma de origem. Se os arquivos estiverem sendo orquestrados por uma ferramenta específica, talvez seja necessário exportá-los. Se você estiver usando notebooks como parte do Databricks ou do EMR, poderá exportá-los como arquivos .ipynb, assim como o notebook Jupyter que executaremos no SMA hoje.

Este laboratório tem apenas alguns arquivos, mas é comum em uma migração grande haver centenas ou milhares deles. Extraia o que puder e execute esses arquivos pelo SMA. A vantagem de usar uma ferramenta como esta é que ela pode indicar o que pode estar faltando.

Observe que também existe um arquivo de dados: “customer_update.csv”. Este é um exemplo do arquivo gerado localmente pelo sistema de Ponto de Venda (POS) que a Adventure Works usa atualmente. Embora esse sistema também esteja sendo atualizado, esta prova de conceito (POC) está focada em fazer o pipeline existente funcionar com o Snowpark em vez do Spark.

Vamos pegar cada um desses arquivos e colocá-los em um único diretório em nossa máquina local:

Recomenda-se criar um diretório de projeto. Você pode dar o nome que quiser, mas como sugestão para este laboratório, vamos usar spark_adw_lab. Isso significa que criaremos uma pasta com o nome spark_adw_lab e, em seguida, outra pasta nesse diretório chamada source_files (o caminho é algo como /your/accessible/directory/spark_adw_lab/source_files). Isso não é obrigatório, mas ajudará a manter tudo organizado. O SMA também analisará qualquer conjunto de subdiretórios, então você pode adicionar pipelines específicos em uma pasta e notebooks em outra.

Acesso ¶

Agora que temos nossos arquivos de origem em um diretório acessível, é hora de executar o SMA.

Se você ainda não o baixou, o SMA está disponível no site da Snowflake. Também é possível acessá-lo na página Migrations no SnowSight, na sua conta Snowflake:

Após baixar a ferramenta, instale-a! Há mais informações sobre a instalação do SMA na documentação do SMA.

Uso do Snowpark Migration Accelerator¶

Após instalar a ferramenta, abra-a! Ao iniciar o SMA, ele será muito semelhante à sua ferramenta parceira, o SnowConvert. Ambas as ferramentas são baseadas em um conceito similar, no qual você insere arquivos de código na ferramenta e ela os executa. Como lembrete, vimos que o SnowConvert pode receber o DDL e os dados diretamente da fonte e inseri-los diretamente no Snowflake. O SMA não faz isso. Ele só aceita arquivos de código como fonte e os gera em um formato compatível com o Snowflake. Isso ocorre principalmente porque a ferramenta não sabe como o usuário vai orquestrar o código Spark, mas também para torná-la mais segura.

Após iniciar a ferramenta, ela perguntará se você deseja criar um novo projeto ou abrir um já existente:

Isso levará você à tela de criação de projeto:

Nesta tela, você vai inserir os detalhes relevantes do seu projeto. Observe que todos os campos são obrigatórios. Para este projeto, você pode inserir algo semelhante a:

• Nome do projeto: Spark ADW Lab

• Endereço de e-mail: your.name@your_domain.com

• Company name: Your Organization

• Caminho da pasta de entrada: /your/accessible/directory/spark_adw_lab/source_files

• Caminho da pasta de saída (o SMA vai gerar automaticamente um diretório para a saída, mas você pode modificá-lo): /your/accessible/directory/spark_adw_lab/source_files_output

Algumas observações sobre esta tela de criação de projeto:

• Os campos de e-mail e empresa servem para ajudar você a acompanhar projetos que podem estar em andamento. Por exemplo, em qualquer SI grande, pode haver vários endereços de e-mail e várias organizações em nome das quais um único usuário pode executar o SMA. Essas informações são armazenadas no arquivo de projeto criado pelo SMA.

• Há um campo oculto para SQL. Observe que o SMA pode analisar/escanear SQL, mas não converte nenhum SQL. Ele também só pode identificar SQL nas seguintes circunstâncias:

  • SQL que está em arquivos .sql

  • SQL que está em células SQL em um Jupyter Notebook

  • SQL que é passado como uma única cadeia de caracteres para uma instrução spark.sql.

• Embora essa capacidade de SQL possa ser útil para determinar onde há SQL incompatível com o Snowflake, esse não é o uso principal do SMA. Mais suporte para o Spark SQL e o HiveQL estará disponível em breve.

Depois de inserir todas as informações do projeto, para este HoL, vamos pular a fase de avaliação. (O quê… não estamos criando uma avaliação?) Se você não quiser converter nenhum código, executar uma avaliação pode ser útil, pois permitirá que você obtenha o conjunto completo de relatórios gerados pelo SMA. Você poderá então navegar por esses relatórios ou compartilhá-los com outras pessoas em sua organização sem criar cópias extras do código convertido. No entanto, todos esses mesmos relatórios de avaliação também são gerados durante uma conversão. Portanto, vamos pular o modo de avaliação por enquanto e ir para a conversão.

On the Conversion settings page, select Skip Assessment, and then click Continue in the bottom right corner.

Observe que o que você está “salvando” é um arquivo de projeto local. Todas as informações que você inseriu na tela de criação do projeto serão salvas neste arquivo de texto local com a extensão “.snowma” no diretório que você acabou de especificar acima.

This will take you to the Conversion settings page. From here, you can choose Default Settings to proceed with conversion, or select Customize settings to review and adjust advanced options.

Há uma configuração que simplificará a saída deste laboratório prático, que consiste em desativar a tentativa de conversão de dataframes do pandas para a API do Snowpark:

Essa configuração está sendo atualizada; portanto, muitos avisos adicionais serão exibidos se essa opção não for desmarcada. A maior parte do dataframe do pandas pode ser utilizada como parte da implementação modin do pandas, então uma simples alteração na chamada de importação deve ser suficiente por enquanto. Procure uma questão sobre esse problema até o fim de junho de 2025. Você pode examinar as outras configurações, mas vamos deixá-las como estão. É importante observar que existe uma biblioteca de testes com a qual o código de saída é compatível, chamada Snowpark Checkpoints. Existem configurações relacionadas a isso, mas não vamos alterá-las neste laboratório.

Select «Save settings» to save and close your settings.

To start the conversion, click Continue in the bottom right corner of the application.

A próxima tela mostrará o progresso da conversão:

Assim como SnowConvert, o SMA está criando um modelo semântico de toda a base de código no diretório de entrada. Ele está construindo relações entre elementos de código, objetos SQL e outros artefatos referenciados, e criando a saída mais próxima possível de um equivalente funcional para o Snowflake. Isso significa principalmente converter referências da API do Spark para a API do Snowpark. A equipe de engenharia do SMA faz parte da equipe de engenharia do Snowpark. Portanto, a maioria das transformações que ocorrem já foi incorporada à API do Snowpark, então as mudanças podem parecer pequenas. Mas a variedade de informações de avaliação geradas pelo SMA permite que um projeto de migração realmente avance. Uma análise detalhada de todas as informações de avaliação geradas terá que ser feita em outro lugar, porque o SMA provavelmente já concluiu essa conversão no tempo que você levou para ler este parágrafo.

When the SMA has finished, the results page will show the… results.

A página de resultados contém algumas “Pontuações de preparação”, que são métricas muito simplificadas sobre o grau de “preparação” deste código-fonte para o Snowflake. Analisaremos os resultados a seguir, mas observe que executar o Snowpark Migration Accelerator é a parte fácil. Observe que este é apenas um “acelerador”. Não é uma solução mágica nem uma ferramenta de automação sem intervenção manual. Os pipelines que se conectam a uma fonte de dados e enviam saída para outra, e que não são totalmente migrados por esta ferramenta, sempre precisarão de mais atenção do que uma migração direta de SQL para SQL do DDL, como é feita pelo SnowConvert. Mas a Snowflake trabalha continuamente para tornar isso o mais simples possível.

Interpretação da saída¶

O SMA, ainda mais do que o SnowConvert, gera uma grande quantidade de informações de avaliação. Pode ser difícil analisar os resultados. Existem muitas direções diferentes que você pode seguir, dependendo do que deseja alcançar.

Observe que este é um cenário extremamente simples, então algumas das etapas que vamos realizar parecerão exageradas. (Quero dizer, precisamos mesmo analisar as dependências presentes neste projeto quando há apenas dois arquivos e poderíamos simplesmente… dar uma olhada?) O objetivo é ainda seguir o que normalmente recomendamos, mesmo neste pequeno POC. Mas sejamos claros… que o escopo é claro e que há apenas dois arquivos. Só precisamos que ambas funcionem como na fonte.