Snowflake SPCS Runtime Customizado

Dhiego Piroto

4 min read

·

1 day ago

--

Share

Press enter or click to view image in full size

Fala, pessoal.

Quem usa notebooks no Snowflake conhece bem esse passo a passo:, acessa os workspaces > abre um notebook > instala as dependências com o pip install (de novo), aguarda a instalação e faz um restart do kernel (e ainda depende de uma External Access Integration liberando o acesso ao PyPI). Você já pensou em como seria simples deixar um runtime com as libs que você precisa pré-configurado e pronto pra uso?

É exatamente para isso que o Custom Runtime Environment (CRE) foi criado. Vamos entender como funciona?

Antes disso, uma contextualização inicial…o que é esse tal de container runtime, Dhiego?

De forma MUITO simplista: é o ambiente de execução Python para ML que roda sobre o Snowpark Container Services (SPCS), usando compute pools CPU ou GPU no lugar de warehouses.

Eu sei o que muitos vão pensar: “então, todo SPCS já vem com PyTorch, XGBoost e cia.?”. Não exatamente…

O SPCS puro (CREATE SERVICE): você traz sua própria imagem Docker, mas ele vem sem nada instalado. Já o Container Runtime, que é usado para notebooks ou ML Jobs, roda em cima do SPCS, mas usa uma imagem versionada mantida pela Snowflake, que já traz o stack de ML e o snowflake-ml-python.

E o que é um Custom Runtime?

A CRE é uma imagem derivada da imagem base oficial, que fica armazenada no image repository da sua conta Snowflake e vem com as libs que você quiser pré-configuradas.
E por que você iria querer usá-las?

• Compliance: a imagem pode ser escaneada e aprovada no seu pipeline.

• Reprodutibilidade: a CRE fixa o digest SHA256 da imagem.

• Sem PyPI em runtime: as libs já vêm na imagem, então não precisa de EAI para isso.

• Persistência: acabou o pip install a cada sessão.

Então o fluxo ficaria: imagem base > Dockerfile > build > validate > push > CREATE CUSTOM RUNTIME ENVIRONMENT > Notebook.

Vamos para a prática? Hands-on time :D

No Snowflake, vamos precisar de alguns componentes, como um database/schema e um compute pool.

Press enter or click to view image in full size

Na sua máquina local você vai precisar de Docker, Snowflake CLI (snow) e Python 3.10+.

agora vamos fazer o pull da imagem default (CPU) do Snowflake, para depois criarmos uma imagem customizada e enviar para o repositório de imagens que criamos.

https://gist.github.com/dhiegopiroto/f991a13f7f786635ce6a6ae7faba38f1

E a lib que vamos adicionar? Escolhi a faker, que gera dados sintéticos, já que ela não faz parte da lista padrão. Para isso, vamos criar um Dockerfile usando como base nossa imagem default.

MUITO IMPORTANTE:

• O ENTRYPOINT tem de continuar /usr/local/bin/entrypoint.sh.
• A variável DASHBOARD_PORT=12003 tem de existir.
• Pacotes obrigatórios: snowflake-ml-python, snowflake-snowpark-python[pandas], ray, jupyter-server, notebook, ipykernel, entre outros.
• A árvore de dependências não pode ter conflitos. Cuidado ao forçar versão de numpy ou pandas.

Agora vamos fazer o build do nosso container na máquina local e enviar para o repositório da nossa conta Snowflake.

Press enter or click to view image in full size

Vamos criar um runtime customizado, usando como base a imagem que subimos para nosso repositório no Snowflake:

https://gist.github.com/dhiegopiroto/fc0a37e41179810536bf67e954f1519d?file=gistfile1.txt

Press enter or click to view image in full size

Crie um novo notebook e configure-o para usar a imagem customizada que criamos e o compute pool definido no primeiro passo do artigo.

Por fim, podemos testar nosso notebook com runtime customizado, mas antes vamos ver como o código seria executado em um runtime padrão:

Press enter or click to view image in full size

Agora vamos ver no customizado

Press enter or click to view image in full size

Por hoje é isso, pessoas!

[]’s

Piroto