Snowflake & Snowpark Python

Olá, daqui fala o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 1 de 17. O maior bottleneck em big data raramente é o storage. O verdadeiro problema surge quando precisas de mover datasets massivos pela rede apenas para chegar à tua camada de compute. A arquitetura do Snowflake contorna completamente este problema. As pessoas muitas vezes assumem que o Snowflake é apenas uma base de dados relacional on-premise que sofreu um lift and shift para a cloud, ou um cluster Hadoop tradicional que tens de fazer babysitting. Não é nenhuma das duas coisas. O Snowflake é um serviço totalmente self-managed, construído nativamente para a cloud. Não instalas software. Não configuras hardware. Toda a manutenção, gestão e tuning são tratados nos bastidores, sem teres de te preocupar. Para perceberes como é que isto é possível, olha para a sua arquitetura híbrida. O Snowflake combina um setup shared-disk com um setup shared-nothing. Num design shared-disk tradicional, todos os compute nodes acedem a um repositório central de dados. Num design shared-nothing, cada compute node tem o seu próprio chunk local de dados para processar. O Snowflake tira o melhor dos dois. Ele mantém um único repositório central de storage acessível a todos os compute nodes, mas utiliza clusters independentes de processamento massivamente paralelo para correr as queries reais contra esses dados. Este modelo híbrido divide-se em três camadas distintas. A primeira é a camada de Database Storage. Quando carregas dados no Snowflake, ele não despeja simplesmente ficheiros raw num bucket na cloud. Ele reorganiza esses dados num formato colunar interno, otimizado e comprimido. O Snowflake gere todos os aspetos de como estes dados são guardados. Não podes aceder ao raw storage diretamente, só interages com ele através de queries SQL. A segunda camada é o Query Processing. É aqui que o trabalho acontece, utilizando o que o Snowflake chama de Virtual Warehouses. Um virtual warehouse é simplesmente um compute cluster independente. Como o compute está estritamente separado da camada central de storage, múltiplos virtual warehouses podem fazer queries exatamente aos mesmos dados em simultâneo. Não competem por recursos e não se bloqueiam uns aos outros. Aqui está o ponto-chave. Podes escalar o teu poder de compute instantaneamente sem mover um único byte de dados. Considera um relatório financeiro de fim de mês que exige uma agregação massiva de dados. Normalmente, terias de migrar tabelas para um servidor maior para lidar com o workload complexo. No Snowflake, simplesmente fazes spin up de um virtual warehouse maior, corres o relatório pesado em minutos e desligas o warehouse quando terminares. As tabelas subjacentes nunca se movem. A terceira camada que une tudo são os Cloud Services. Este é o cérebro da plataforma. É um conjunto de serviços que coordena tudo em todo o sistema. Lida com a autenticação de utilizadores, gere a infraestrutura, faz o parse das queries recebidas e otimiza os caminhos de execução. Também gere metadados, rastreando exatamente onde partes específicas dos dados residem na camada de storage, para que as queries possam correr com eficiência sem precisarem de fazer scan a tudo. A conclusão mais poderosa é que, no Snowflake, o scaling de performance é apenas um interruptor no compute cluster, enquanto as tabelas de dados massivas permanecem completamente estáticas. Se estás a gostar da série e queres apoiar o projeto, podes encontrar-nos pesquisando por DevStoriesEU no Patreon. Por este episódio é tudo. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 2 de 17. E se pudesses escrever Python puro, mas executá-lo como SQL distribuído hiperotimizado? Esta é exatamente a mudança de paradigma que vamos abordar hoje com uma introdução ao Snowpark. Tradicionalmente, trabalhar com grandes datasets em Python significava extrair dados da tua base de dados. Escreves uma query, puxas os dados pela rede para a memória local ou para um cluster de processamento externo, corres as tuas transformações e, a seguir, envias os resultados de volta. Esta abordagem cria bottlenecks na rede, aumenta os custos de infraestrutura e introduz riscos de segurança ao mover dados para fora de um ambiente controlado. O Snowpark inverte este modelo. Em vez de mover os dados para o compute, o Snowpark leva o compute até aos dados. Um equívoco comum é pensar que o Snowpark é um motor de processamento externo. Muitas vezes, as pessoas assumem que precisam de levantar e gerir um cluster de compute separado só para correr código Python. Não é o caso. As computações do Snowpark correm diretamente dentro do Snowflake. Estás a usar exatamente os mesmos virtual warehouses que executam as tuas queries SQL standard. Não há infraestrutura nova para provisionar ou manter. Ao escreveres código usando a API Python do Snowpark, estás a interagir com um objeto DataFrame. Isto é muito semelhante a trabalhar com ferramentas de dados Python que já conheces. Fazes chain de operações, definindo como selecionar, filtrar, agrupar ou agregar os teus dados. No entanto, a library Snowpark não executa estas operações localmente. Em vez disso, traduz nativamente as operações do teu DataFrame Python em construções SQL complexas. O Snowflake depois processa estas statements SQL usando o seu motor de execução standard. Aqui está o ponto chave. O Snowpark usa lazy evaluation. Quando defines o teu DataFrame e aplicas várias transformações, nenhuns dados são realmente movidos ou alterados. A API do Snowpark simplesmente constrói um plano lógico. Regista a tua intenção passo a passo. A execução real só é disparada quando chamas uma ação específica, como pedir ao sistema para devolver os resultados finais ou gravá-los numa nova tabela. Este modelo de lazy evaluation, combinado com a tradução SQL nativa, reduz drasticamente a transferência de dados. Imagina um cenário em que és um data engineer encarregue de filtrar mil milhões de linhas de dados transacionais para isolar algumas anomalias específicas. Escreves a tua lógica de filtro num script Python local. Como a execução é adiada até a ação ser chamada, a API tem tempo para otimizar toda a chain de operações e traduzi-la numa única query SQL altamente eficiente. A filtragem em si acontece inteiramente dentro do Snowflake. A base de dados faz todo o trabalho pesado. Os únicos dados que viajam pela rede até à tua máquina local são o pequeno subset final de anomalias. Acabaste de processar mil milhões de linhas usando a sintaxe de Python sem puxar um único registo raw para a tua memória local. A verdadeira vantagem aqui é manter a developer experience nativa em Python, enquanto tiras partido do motor da base de dados para o que ele faz melhor. Tu escreves Python, mas o Snowflake executa SQL. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 3 de 17. Os boilerplates de conexão costumam ser um pesadelo de segurança, repletos de passwords hardcoded e variáveis de ambiente dispersas. Queres dar à tua equipa uma command line tool local, mas não podes, de forma alguma, embutir credenciais no código. A solução é estabelecer uma Session de forma limpa usando as features de configuração nativas do Snowpark. Qualquer script do Snowpark começa por criar um objeto Session. Este é o teu link ativo para o environment do Snowflake. Ele encapsula a tua autenticação, o teu target warehouse e o teu context. Para o construíres, usas o objeto builder disponível na classe Session. A abordagem mais direta é passar um dictionary. Crias um dictionary Python com keys para a tua account, user, password, role, database e warehouse. Passas esse dictionary para o método configs do session builder, e depois chamas o método create. A lógica flui diretamente do teu dictionary para o backend do Snowflake. Mas ter credenciais hardcoded dentro de um script Python é um enorme risco de segurança, tornando esta abordagem inadequada para ferramentas partilhadas. Para removeres as credenciais do teu código, o Snowpark depende de um ficheiro de configuração standard chamado connections.toml. Colocas este ficheiro na root do teu projeto ou num diretório oculto snowflake dentro da tua home folder de utilizador. O ficheiro TOML contém blocos de conexão. Podes definir um bloco default, um bloco dev e um bloco prod, cada um com os seus próprios parâmetros de conexão. Aqui está o ponto chave. Quando usas um ficheiro TOML, o teu código Python simplifica-se drasticamente. Não passas qualquer dictionary. Apenas chamas o método get ou create no session builder. O Snowpark faz o scan automático dos diretórios standard, encontra o teu ficheiro TOML, lê o bloco default e instancia a Session. Se quiseres um environment específico, passas o nome da conexão para o método configs antes de criares a Session. O teu código mantém-se limpo, e as credenciais ficam seguras na máquina local. Podemos proteger a nossa command line tool ainda mais. Mesmo com um ficheiro TOML, podes não querer que os developers guardem passwords permanentes localmente. Podes eliminar as passwords por completo usando single sign-on baseado no browser. No teu ficheiro TOML, omites a key password. Em vez disso, adicionas uma key chamada authenticator e defines o seu valor como externalbrowser. Quando o teu script chega à etapa de criação da Session, a execução faz uma pausa. O Snowpark interceta o processo e abre automaticamente o web browser default do utilizador. Ele redireciona o developer para o identity provider da tua organização. O developer faz o login normalmente, satisfazendo quaisquer requisitos de multi-factor authentication. Assim que o identity provider aprova o login, envia um token de autenticação temporário de volta para uma porta local onde o Snowpark está a escutar. O script recebe o token, estabelece a Session segura do Snowflake, e a execução de Python é retomada. A tua CLI tool tem agora acesso totalmente autenticado ao Snowflake sem que uma única password alguma vez toque nos teus ficheiros de configuração ou no teu source code. A credencial mais segura é aquela que nunca toca no teu código, e delegar a autenticação para o browser mantém os teus scripts locais seguros e totalmente focados nos dados. Gostaria de tirar um momento para te agradecer por estares a ouvir — ajuda-nos imenso. Fica bem!

Olá, daqui é o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 4 de 17. Queres testar uma transformação rápida de dados, mas o teu ambiente Python local está com problemas outra vez. As tuas connection strings estão desatualizadas, e acabaste de perder vinte minutos a tentar autenticar-te. E se pudesses escrever código num ambiente totalmente configurado diretamente no teu browser, com zero setup? Esse é exatamente o problema resolvido pelas Python Worksheets no Snowsight. As Python Worksheets são um editor de código nativo integrado diretamente na interface web do Snowflake. Elas removem a fricção da configuração do ambiente local. Imagina prototipar um script rápido de limpeza de dados sobre live data. Em vez de abrires um IDE e gerires credenciais, abres um separador no browser e começas a escrever código imediatamente. A lógica de execução depende de um entry point designado. Não escreves um script procedural solto. O Snowflake precisa de uma função específica para fazer trigger ao teu código. Por omissão, esta é uma função handler chamada main. Esta função recebe um único argumento, que é o objeto session ativo. Como já tens o login feito na interface do Snowflake, o sistema lida com a autenticação automaticamente e passa uma live session diretamente para a tua função main. Usas esta session para ler tabelas, executar queries e manipular dados usando os métodos standard do Snowpark. Aqui está o ponto chave em relação a dependências. Podes estar à espera de abrir um terminal e usar o pip para instalar as tuas bibliotecas, mas não é assim que as worksheets operam. Não usas o pip de todo. O Snowflake integra-se nativamente com o repositório Anaconda. Dentro da interface da worksheet, há um menu dropdown dedicado a packages. Basta pesquisares a biblioteca de que precisas, como pandas ou scikit-learn, selecionares a versão, e o Snowflake provisiona-a instantaneamente para o teu ambiente de execução. Isto cobre os inputs e o setup. E quanto aos outputs? A tua função handler tem de retornar um valor, e tu configuras como o Snowflake interpreta este valor usando as settings da worksheet. Escolhes principalmente entre dois return types, Table ou String. Se definires o return type para Table, a tua função main precisa de retornar um Snowpark DataFrame. O Snowflake pega nesse DataFrame e renderiza-o como uma grid limpa e interativa no painel de resultados. Isto é perfeito para inspecionar o output do teu script de limpeza de dados. Se definires o return type para String, a tua função tem de retornar um valor de texto escalar. Usas isto quando queres retornar uma mensagem de status, um agregado numérico com cast para texto, ou um payload JSON. Tens de alinhar o teu código com as settings da worksheet. Se configurares a worksheet para esperar uma Table, mas a tua função retornar uma String, a execução vai falhar. O verdadeiro poder das Python Worksheets não é construir aplicações massivas com múltiplos ficheiros. É a capacidade de validar lógica de transformação contra dados à escala de produção em segundos, de forma segura, sem nunca configurares uma máquina local. Obrigado por estares aí. Espero que tenhas aprendido algo novo.

Olá, daqui é o Alex do DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 5 de 17. Se instanciares um DataFrame a representar mil milhões de linhas, quanta memória é que ele usa no teu portátil? Quase zero. O motivo para isso prende-se com a mecânica central de construção de DataFrames do Snowpark. Um DataFrame do Snowpark não é um container que guarda a tua informação. É simplesmente uma referência lógica a dados que residem no Snowflake. Quando defines um DataFrame no teu código Python, estás a construir um query plan. Isto baseia-se num conceito chamado lazy evaluation. Com lazy evaluation, o Snowpark adia a execução do SQL subjacente até fazeres trigger explícito de uma ação que exija um resultado final. Até que esse trigger aconteça, cada DataFrame que constróis é apenas um conjunto leve de instruções. A principal forma de começar a construir estas instruções é através do método session dot table. Passas o nome de uma table ou view existente do Snowflake como uma string. Podes fornecer apenas o nome da table, ou um fully qualified name incluindo a database e o schema. Um erro frequente que os novos utilizadores cometem é assumir que chamar session dot table faz o download do conteúdo da table para o seu ambiente Python local, de forma semelhante a como o Pandas opera. Isso não acontece. Se apontares o session dot table para um transaction log de dez terabytes, a função Python retorna em milissegundos. Não viajam dados pela rede. O objeto DataFrame apenas regista essa table específica como o root node do teu execution plan. Outra abordagem é o método session dot sql. Usas isto quando queres definir um DataFrame usando uma raw SQL string. Isto é particularmente útil se tiveres uma query existente que queiras migrar, ou se preferires expressar uma extração inicial específica em SQL. Tal como o método table, passar uma query para o session dot sql não envia a query para o Snowflake para execução imediata. Cria um DataFrame que representa o output dessa query específica. Podes pensar nisto como definir uma inline view. O terceiro mecanismo é o método session dot create dataframe. Este opera de forma diferente porque começa com dados que já estão na tua máquina local. Podes passar uma list Python, um dictionary, ou um DataFrame do Pandas para este método. Quando executado, o Snowpark pega nesses dados locais, faz o upload para o Snowflake, e coloca-os dentro de uma temporary table. O método depois retorna um DataFrame do Snowpark a apontar para essa nova temporary table. Aqui está o ponto chave. Como o session dot create dataframe move fisicamente os dados da tua máquina para o Snowflake, a sua performance depende inteiramente do tamanho do teu dataset local e da tua ligação de rede. Usas isto para fazer push de pequenas lookup tables ou parâmetros de configuração para o Snowflake, para que possam interagir com os teus datasets maiores. Podes deixar o Snowpark inferir os nomes das colunas e os data types a partir dos teus objetos locais, ou podes definir explicitamente um schema usando um objeto StructType do Snowpark para garantir precisão. Sempre que constróis um DataFrame do Snowpark, independentemente do método, estás a definir uma relação com os dados, em vez de obteres os dados em si. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 6 de 17. Escreves dez operações complexas de DataFrame seguidas, mas o sistema não executa dez queries separadas. Em vez disso, atrasa a execução e constrói uma única instrução SQL perfeitamente otimizada nos bastidores. Hoje, vamos falar sobre transformar DataFrames. Quando transformas um DataFrame, estás a preparar uma receita para moldar os teus dados. Para construir esta receita, precisas de uma forma fiável de referenciar as colunas de dados subjacentes. Fazes isso usando uma função chamada col. Passas o nome de uma coluna como uma string para esta função, e ela devolve um objeto de coluna. A seguir, usas este objeto dentro de outros métodos para construir expressões, como verificar se o valor de uma coluna é igual a um número ou a uma string de texto específica. Vamos ver um cenário concreto. Tens dois DataFrames. Um contém perfis de clientes e o outro contém registos de transações. Queres identificar utilizadores de alto valor e ligá-los às suas compras recentes. Se escrevesses isto em raw SQL, poderias acabar com uma query grande e aninhada, que te obrigaria a ler a lógica de dentro para fora. Com DataFrames, usas method chaining para escrever a lógica de cima para baixo. Primeiro, pegas no teu DataFrame de clientes e chamas o método filter. Dentro desse filter, usas a função col para apontar para a coluna do nível de gastos, e especificas que deve ser igual ao teu nível mais alto. Logo a seguir a esse filter, encadeias um método select. Usas a função col novamente para indicar que só queres manter o ID do cliente e o endereço de email. Cada transformação devolve um novo DataFrame, permitindo-te anexar a instrução seguinte diretamente ao final da anterior. Agora, a segunda parte disto é trazer os dados das transações. Chamas o método join no teu DataFrame de clientes filtrado. Passas o DataFrame de transações como primeiro argumento. Depois, especificas a condição para o join, como corresponder a coluna de ID do cliente de ambos os datasets. Também podes definir o tipo de join, como um inner join ou left join. A lógica lê-se sequencialmente. Fazes filter, fazes select e fazes join. Aqui está o ponto chave. À medida que o Python lê esta chain de métodos, o Snowpark não toca nos dados reais. As transformações são avaliadas de forma lazy. O DataFrame funciona simplesmente como um blueprint. Regista cada filter, select e join que pedes, mas não os executa passo a passo. Esta execução atrasada permite que a framework olhe para toda a tua sequência de operações e a otimize antes de qualquer coisa realmente correr. A execução só é acionada quando finalmente pedes um resultado concreto. Isto requer a chamada de um método de ação. Se quiseres imprimir uma pequena amostra dos dados no teu terminal, chamas o método show. Se quiseres descarregar os resultados totalmente processados de volta para a tua memória Python local, chamas o método collect. No momento em que chamas o collect, o Snowpark traduz o teu blueprint numa única query SQL eficiente e envia-a para o Snowflake. Tens o benefício de escrever Python legível e passo a passo, enquanto o motor da base de dados processa os dados numa única passagem altamente otimizada. É tudo por este episódio. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 7 de 17. Estás a construir um data pipeline e de repente precisas de uma manipulação complexa de strings ou de uma conversão matemática obscura. Não tens de escrever essa lógica do zero em Python. A base de dados já sabe como o fazer. É aí que entra a chamada de system functions. O Snowflake tem centenas de system functions built-in, escritas em C++ altamente otimizado. Elas lidam com tudo, desde fazer o parsing de texto até calcular desvios padrão. O Snowpark permite-te acionar estas funções SQL nativas diretamente a partir do teu código Python. Tens a estrutura familiar do Python, mas o trabalho pesado acontece inteiramente dentro do Snowflake. Os dados em si nunca saem do servidor para serem processados no teu ambiente Python local. Para acederes a estas funções, importas o módulo snowflake dot snowpark dot functions. Este módulo contém wrappers de Python diretos para a maioria das operações SQL standard. Se precisares de converter texto para maiúsculas, basta chamares a função upper deste módulo e passares-lhe o teu column object. Nos bastidores, o Snowpark traduz o teu código Python para a sintaxe SQL equivalente e faz o push down para a base de dados para execução. Isto cobre a maioria dos use cases. Mas o que acontece quando o Snowflake lança uma nova função SQL, ou precisas de usar uma system function especializada que ainda não tem um wrapper de Python explícito no módulo? Não tens de esperar pela próxima release da library Snowpark para a usares. Esta é a parte que interessa. Podes usar um método dedicado chamado call_function para invocar qualquer system function do Snowflake pelo seu nome SQL exato. Imagina um cenário em que tens uma tabela com milhões de linhas que contêm medições de ângulos em graus, e o teu modelo de machine learning downstream precisa delas em radianos. Em vez de escreveres uma transformação matemática custom em Python que arrasta todas essas linhas para a memória, deixas o motor da base de dados fazer o trabalho. Importas o call_function. A seguir, invocas o método passando a string radians como primeiro argumento. O segundo argumento é o column object que queres transformar. O Snowpark faz instantaneamente o push down disso como uma operação SQL nativa radians em todo o teu dataset. Isto é executado com a velocidade de código C++ compilado, e demora-te exatamente uma linha de Python a escrever. O método call_function é flexível. Se a função SQL subjacente exigir múltiplos inputs, simplesmente passas-os em sequência a seguir ao nome da função. Estes inputs podem ser outros column objects, ou podem ser valores literais, como uma string ou um número específico. O Snowpark mapeia os teus argumentos de Python diretamente para os parâmetros SQL esperados. Este design mantém o teu código limpo enquanto maximiza a performance. Não perdes o acesso ao poder bruto das funções SQL nativas do Snowflake só porque estás a escrever numa linguagem diferente. Ao tirares partido das system functions, tratas o Python como o orquestrador, deixando o motor da base de dados fazer exatamente aquilo para que foi construído. Obrigado por ouvires. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 8 de 17. Escalar um pipeline pandas existente tradicionalmente significava deitar fora o teu código e reescrever tudo numa framework distribuída como o Spark. E se pudesses lidar com um dataset cem vezes maior apenas alterando um único import? Essa é a premissa do pandas no Snowflake. O pandas é o standard universal para manipulação de dados em Python. É expressivo, legível e está profundamente enraizado na forma como os data engineers e data scientists trabalham. O problema é que o pandas é fundamentalmente limitado pela execução single-node. Exige que todos os teus dados caibam na memória local. Quando o teu dataset ultrapassa os limites do teu portátil ou da tua cloud instance, o pandas standard falha. O pandas no Snowflake representa uma mudança completa de paradigma para estes pipelines legacy. Atua como uma ferramenta de migração zero-friction. Imagina que tens um script Python existente que limpa e agrega logs de transações diárias. Funciona perfeitamente com dez gigabytes de dados, mas de repente pedem-te para processar um terabyte. Para escalar isto, não precisas de reescrever a tua lógica em SQL. Nem sequer precisas de aprender a sintaxe específica da API standard de DataFrames do Snowpark. Só tens de alterar uma linha no topo do teu ficheiro. Removes o import standard pandas as pd. E substituis por import snowflake.snowpark.modin.pandas as pd. É aqui que a coisa fica interessante. Um ponto comum de confusão é como é que isto realmente processa os dados. Muitos developers assumem que se trata apenas do pandas standard a operar numa live connection, a puxar milhões de rows para a tua máquina local para processar. Isso está incorreto. Quando usas este import específico do Modin, nenhum dado é descarregado para a tua máquina. Em vez disso, esta library interceta cada comando pandas que escreves no teu script. Quando encadeias um filter, um group-by e uma agregação de média, o engine subjacente traduz essa sequência exata numa query SQL otimizada do Snowflake. Ele transpila a tua sintaxe pandas para SQL e, em seguida, submete esse SQL ao compute engine do Snowflake. A operação é executada inteiramente dentro do teu warehouse Snowflake. A tua máquina local é responsável apenas por orquestrar os comandos. O heavy lifting é distribuído pelos clusters do Snowflake. Isto dá-te a exata developer experience do pandas, mas suportada por uma base de dados massivamente paralela. Esta mudança resolve duas grandes dores de cabeça organizacionais de uma só vez. Primeiro, elimina o problema de data egress. Como as operações são pushed down para a base de dados, os teus dados raw nunca saem do perímetro seguro do Snowflake. Segundo, poupa meses de retraining de developers. A tua equipa continua a escrever os dataframes, joins e agregações familiares que já conhecem perfeitamente. Apenas os correm contra a cloud em vez do seu processador local. O verdadeiro poder do pandas no Snowflake é que desacopla a linguagem que usas para descrever as tuas transformações de dados do engine que realmente as executa. Se achas estes technical deep dives úteis, podes apoiar o programa procurando por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 9 de 17. O teu código agora é inteligente o suficiente para saber exatamente quando usar a memória do teu portátil e quando arrancar um cluster na cloud. Este é o conceito central por trás do pandas no Snowflake: Hybrid Execution. Quando usas o pandas standard, todas as operações correm na memória da tua máquina local. Se carregares um dataset gigante, o teu processo crasha. A API de pandas do Snowpark resolve isto mapeando os teus comandos de pandas para SQL e executando-os no warehouse do Snowflake. Mas nem todas as funções de pandas têm um equivalente direto em SQL. Certas operações, como fazer plots ou aplicar funções custom de Python específicas, exigem a biblioteca pandas local para serem executadas. O desafio é alternar de forma transparente entre o engine na cloud e o teu ambiente local, sem arrastar gigabytes de dados raw pela rede. A Hybrid Execution lida com esta transição de forma dinâmica. É um modelo de execução construído inteiramente à volta da otimização para o menor custo possível de transferência de dados. Quando corres um script usando a API de pandas do Snowpark, o engine atua como um router inteligente. O seu comportamento default é manter os dados na cloud. Ele traduz o teu código para queries SQL e executa-as usando o compute do Snowflake. Vamos ver um cenário prático. Começas com uma tabela com dez milhões de linhas. Escreves uma linha de código para filtrar registos inválidos e, a seguir, agrupas os dados para calcular uma média. Até este ponto, o engine traduz os teus comandos de filter e agregação diretamente para SQL. O warehouse do Snowflake faz o trabalho pesado. A tua máquina local não faz o download de uma única linha desse dataset gigante. A agregação reduz essas dez milhões de linhas para uma tabela de resumo com exatamente sete linhas. Para o teu próximo passo, escreves um comando para fazer o plot dessas sete linhas num gráfico. O plotting é inerentemente uma operação local. O database engine do Snowflake não consegue desenhar um gráfico por ti. Aqui está o ponto-chave. O engine reconhece que o comando de plotting requer uma transição para o backend local de pandas. Como o engine processa as tuas operações de forma inteligente, ele olha para o estado dos teus dados imediatamente antes da operação local ser pedida. Ele sabe que a agregação anterior resulta em apenas sete linhas. Portanto, em vez de mover as dez milhões de linhas originais para o teu portátil para processar a agregação localmente, ele deixa o Snowflake terminar os cálculos na cloud. Depois, dispara um download apenas dessas sete linhas finais para a tua memória local. Assim que os dados chegam ao teu ambiente local, o pandas standard assume o controlo. A biblioteca local executa o comando de plot usando essas sete linhas. Quaisquer operações subsequentes que faças nessa estrutura de dados específica vão continuar a correr localmente, porque os dados já cruzaram a fronteira da rede. O sistema isola a manipulação pesada de dados dentro da infraestrutura da cloud. Ele adia a transferência de rede até que uma operação exija estritamente a execução local. Quando essa exigência ocorre, os teus passos de manipulação de dados geralmente já reduziram o dataset para uma fração do seu tamanho original. Manténs a sintaxe da API que já conheces, mas evitas completamente o bottleneck da rede. A característica principal da Hybrid Execution não é apenas fazer fallback para a memória local, mas sim encolher estrategicamente o payload na cloud antes de dar o salto. É tudo por agora. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 10 de 17. E se pudesses fazer uma query a uma base de dados PostgreSQL a partir do teu script Python no Snowflake? Normalmente, mover dados de uma base de dados operacional para o Snowflake exige um intermediário externo. Configuras uma ferramenta de extração num servidor separado, geres credenciais, fazes stage de ficheiros e agendas jobs só para preparares os teus dados para análise. A ingestão de dados externos diretamente via Snowpark Python resolve isto, eliminando o intermediário por completo. Esta abordagem permite-te simplificar a tua arquitetura de dados. Ao tirar partido do external network access no Snowflake, o teu código Python pode ligar-se diretamente a outros sistemas. Podes usar bibliotecas DB-API de Python standard ou drivers JDBC para te ligares a bases de dados externas, diretamente a partir de uma stored procedure ou de uma user-defined table function do Snowpark. Considera um cenário concreto. Tens uma base de dados PostgreSQL on-premise legacy de inventário, e precisas de fazer join desses dados de inventário com as tuas tabelas de clientes live no Snowflake. Em vez de configurares um pipeline de ingestão complexo, escreves uma stored procedure em Snowpark Python. Dentro dessa procedure, usas um conector DB-API standard de Postgres. Passas a tua connection string, que referencia credenciais geridas de forma segura pelo Snowflake. Abres a ligação, executas um statement SQL select standard contra a base de dados PostgreSQL externa, e fazes fetch do result set. Assim que os dados estiverem em memória dentro da tua função Python, simplesmente fazes yield das rows de volta para o Snowflake, ou convertes tudo diretamente num DataFrame do Snowpark. Agora tens os teus dados de inventário externos disponíveis como um objeto nativo do Snowflake, prontos para fazer join com as tuas tabelas de clientes numa única query. A lógica flui do sistema operacional externo diretamente para o teu ambiente analítico, de forma segura e sem servidores de staging intermédios. Isto cobre inputs relacionais. E quanto a fontes de dados semiestruturadas, como ficheiros nested colocados num stage? O Snowpark também fornece ferramentas específicas para fazer parsing de formatos complexos. Um excelente exemplo é o reader de XML RowTag. Quando precisas de ingerir um ficheiro XML pesado, não tens de escrever lógica de parsing customizada para navegar por toda a árvore do documento. Em vez disso, especificas uma row tag. Este é o elemento XML específico que representa um único registo. Chamas o método read na tua session do Snowpark, defines o formato como XML, e forneces o parâmetro da row tag. O Snowflake faz scan do documento, identifica cada instância dessa tag, e extrai-a como uma row individual num DataFrame. A hierarquia complexa acima e abaixo dessa tag é flattened ou packed em colunas, dependendo do teu schema. Transforma um documento de texto nested numa tabela limpa e queryable num só passo. Aqui está o ponto chave. Quer estejas a abrir uma ligação JDBC para uma base de dados on-premise antiga ou a apontar um reader de row tag para um ficheiro XML nested, estás a consolidar a tua lógica de ingestão dentro da plataforma de dados. Estás a transformar problemas de integração em simples problemas de execução de código. Obrigado por ouvires. Até à próxima!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 11 de 17. Como é que executas lógica customizada de parsing de strings em Python em mil milhões de linhas sem mover os dados? A resposta está na criação de UDFs escalares, ou User-Defined Functions. As funções SQL standard cobrem a maioria das transformações de dados do dia a dia. Quando o SQL standard falha, as UDFs de Python entram em ação de forma perfeita. Se estiveres a lidar com regras altamente customizadas, como escrever uma regular expression complexa para fazer o parsing de endereços de email mal formatados, o SQL puro torna-se rapidamente ilegível ou impossível. As UDFs escalares resolvem este problema ao permitir-te escrever lógica Python simples e executá-la nativamente dentro do compute engine do Snowflake. Uma função escalar simplesmente processa uma linha de input e devolve exatamente um valor de output. Para fazeres deploy do teu código Python, usas o Snowpark para registar a função. Se só precisares da lógica para o teu script atual, crias uma UDF anónima. A forma mais fácil de fazer isto é usar o decorator at-UDF. Primeiro, escreves uma função Python standard. Vamos chamá-la de extract email domain. Lá dentro, usas o módulo regex standard do Python para fazer o parsing da string de texto e devolver o domínio correspondente. Logo acima da definição da função, colocas o decorator at-UDF. Quando o teu script é executado, o Snowpark serializa automaticamente esta função Python, envia-a para o servidor e devolve uma referência para um objeto UDF. Agora podes passar este objeto para as operações de coluna do teu DataFrame, aplicando o teu parser customizado em tabelas enormes como se fosse uma funcionalidade nativa da base de dados. Alternativamente, podes ignorar o decorator e passar a tua função Python explicitamente para o método session dot udf dot register. Ambos os métodos criam um objeto temporário no database engine. No momento em que a tua sessão do Snowpark é fechada, a UDF anónima é eliminada por completo. É aqui que a coisa fica interessante. Se a tua nova lógica de parsing for valiosa, provavelmente vais querer partilhá-la com outros utilizadores ou disponibilizá-la para pipelines SQL downstream. Para conseguir isto, crias uma UDF permanente e com nome. Usando o mesmo método de registo, adicionas uma flag is permanent definida como true, e forneces um valor de string para o parâmetro name. Este nome dita como a função será chamada na base de dados. Quando tornas uma UDF permanente, o Snowflake precisa de um local físico para persistir o teu código Python, para que continue disponível muito depois de a tua sessão se desligar. Por causa disto, também tens de fornecer um parâmetro de stage location. Isto aponta para um stage interno existente do Snowflake. O Snowpark fará o upload e guardará com segurança os ficheiros Python compilados diretamente nesse stage. Assim que o registo terminar, qualquer pessoa com as permissões corretas na base de dados pode chamar a tua lógica Python customizada diretamente a partir de uma query SQL standard. Ao criar qualquer UDF, o Snowpark tipicamente depende dos type hints do Python para perceber que data types a função aceita e devolve. Se a tua função espera uma string e devolve uma string, adicionas esses type hints standard à definição do Python, e o Snowpark mapeia-os automaticamente para os data types equivalentes do Snowflake. O verdadeiro poder da UDF escalar não é apenas a capacidade de escrever Python, mas a capacidade de executar esse Python dentro da memória distribuída do database engine, eliminando completamente a latência de rede de puxar os dados para fora para processamento. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 12 de 17. Correr packages Python de terceiros dentro de uma base de dados costumava ser um verdadeiro inferno de dependências. Acabavas a criar containers Docker complexos só para passar um array por uma função matemática. Agora, basta exatamente uma linha de código. Este episódio aborda a gestão de dependências para UDFs. Quando escreves uma User-Defined Function, ou UDF, a tua lógica raramente existe no vácuo. Precisas de libraries. Num setup tradicional, mover o teu código Python para onde os dados vivem significa que também tens de mover todo o teu environment. Preocupas-te com pip installs, dependências do compilador e em manter o servidor idêntico à tua máquina local. O Snowflake evita este pesadelo automaticamente através de uma integração built-in com o canal Anaconda. O canal Anaconda do Snowflake aloja milhares de packages Python pre-built e pré-compilados, com garantia de funcionamento dentro do ambiente de execução do Snowflake. Para os usares, não instalas nada manualmente. Simplesmente declaras o que a tua função precisa. Quando defines a tua UDF usando o decorator de Python, adicionas um parâmetro chamado packages. Passas a este parâmetro uma lista de strings, a nomear as libraries de que precisas. Pega num cenário concreto. Queres usar um modelo de machine learning para fazer o score de linhas diretamente dentro de uma query no Snowflake. A tua função de previsão depende do scikit-learn e do pandas. Logo acima da tua função Python, adicionas o decorator da UDF e defines a lista packages para conter as strings scikit-learn e pandas. Não constróis um container, e não corres um package manager. Quando chamas essa UDF, o Snowflake provisiona um ambiente seguro, faz pull desses exatos packages do canal Anaconda, e executa o teu código. Se precisares de uma release específica, podes fazer pin da versão adicionando dois sinais de igual e o número da versão diretamente dentro da string, tal como num ficheiro requirements padrão de Python. Isto cobre as libraries externas. Agora, a segunda parte disto é o teu próprio código custom. Nem tudo o que escreves pertence ao Anaconda. Muitas vezes tens helper functions ou regras de negócio custom escritas num ficheiro Python separado. O Snowflake lida com este código first-party através da tua sessão ativa. Chamas um método chamado add import no objeto da sessão. Passas o path do teu ficheiro custom para o add import. Pode ser um ficheiro Python local no teu portátil, um ficheiro já presente num stage do Snowflake, ou um ficheiro zip contendo uma diretoria mais profunda de módulos. Quando registas a tua UDF, o Snowflake agarra nos ficheiros que especificaste e faz o upload deles. Em runtime, o Snowflake extrai esses ficheiros e coloca-os diretamente no system path do ambiente isolado que está a correr a tua UDF. Dentro do código da tua função principal, usas apenas import statements padrão de Python para trazer os teus módulos custom, exatamente como se estivessem na mesma pasta localmente. Podes combinar livremente estas duas abordagens. Declaras os teus requirements externos através do parâmetro packages, e injetas os teus módulos internos usando o add import. O Snowflake constrói o contexto de execução fazendo o merge seguro dos binários do Anaconda com os teus ficheiros custom em stage antes que uma única linha de dados seja processada. Aqui está o insight principal. Ao gerir as dependências desta forma, o Snowflake desacopla completamente o teu código funcional da infraestrutura necessária para o correr, permitindo-te definir um ambiente de execução seguro e distribuído usando apenas uma lista de nomes e file paths. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 13 de 17. O que fazes quando a tua função Python precisa de devolver uma tabela inteira de resultados em vez de apenas um valor? As user-defined functions normais são ótimas, mas estão estritamente limitadas a devolver um único valor escalar por cada input row. Quando precisas de fazer o explode de um único input para múltiplos outputs, crias uma User-Defined Table Function, ou UDTF. A diferença é fundamental. Uma função standard devolve um valor. Uma UDTF devolve uma relation. Isto significa que devolve uma estrutura tabular à qual podes fazer query, filtrar ou fazer join com outras tabelas, exatamente como se fosse uma tabela física na tua base de dados. Considera um cenário concreto. Tens uma tabela com uma coluna que contém application logs em JSON altamente nested e customizados. Cada row guarda uma log entry enorme, mas essa única entry pode conter cinco, dez ou cinquenta eventos de sistema distintos, escondidos bem no fundo do JSON. Precisas de normalizar estes dados programaticamente. Queres passar uma string JSON e receber de volta uma tabela estruturada onde cada evento individual é extraído para a sua própria row. Para construíres uma UDTF em Snowpark Python, não escreves uma função standalone. Escreves uma class Python. Esta class atua como o handler da table function e orquestra a lógica usando até três métodos específicos. O primeiro é o método de initialization. Este é opcional. O Snowflake executa-o uma vez por partition antes de processar quaisquer rows. Se o teu log parser precisar de compilar uma regular expression complexa ou inicializar um custom state dictionary, fazes isso aqui, para que o setup cost seja pago apenas uma vez por batch de dados. O segundo é o método process. Este é o único método obrigatório na class. O Snowflake chama-o para cada input row individual. No nosso cenário de logging, o método process recebe a string JSON, faz o unpack do array de eventos e faz um loop por eles. É aqui que a conversão acontece. Em vez de devolver um valor final, o método process faz yield de tuples. Cada tuple de que faz yield torna-se instantaneamente numa nova row na tua output table. Se uma log string JSON contiver doze eventos, o método process faz yield de doze tuples separados, e o Snowflake transforma-os em doze output rows distintas. O terceiro é o método end partition. Este também é opcional. O Snowflake aciona-o depois de todas as rows na partition atual terem passado pelo método process. Normalmente, utilizas isto se estiveres a agregar state ao longo da partition e precisares de fazer yield de uma summary row final, ou simplesmente para limpar memória e recursos. Ao registares esta handler class no Snowpark, tens de declarar explicitamente o teu output schema. Como uma UDTF devolve uma tabela, o execution engine da base de dados precisa de saber os nomes exatos das colunas e os data types dos tuples de que estás a fazer yield, antes mesmo de a query ser executada. Aqui está o ponto-chave. As UDTFs preenchem a lacuna entre a lógica complexa de Python e as operações de bases de dados relacionais, permitindo-te fazer o wrap de data unnesting procedural e confuso numa table interface limpa, à qual o resto da tua aplicação pode fazer query nativamente. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 14 de 17. Para de pagar por um servidor de orquestração externo só para correr scripts Python que dizem ao Snowflake o que fazer. Criar stored procedures traz esse control flow diretamente para a plataforma de dados. As pessoas costumam confundir stored procedures com User-Defined Functions, ou UDFs. Uma UDF não serve para orquestração. As UDFs devolvem valores dentro de uma query e transformam os dados linha a linha. As stored procedures são completamente diferentes. Elas correm scripts inteiros, executam múltiplas queries e lidam com o control flow procedural. Usas as stored procedures para orquestrar tarefas, não para calcular valores de colunas. Para criar uma stored procedure no Snowpark Python, escreves uma função Python standard. O requisito crucial é o primeiro argumento dessa função. Tem de ser sempre um objeto Session do Snowpark. Esta Session é o teu link ativo à base de dados. Quando a tua procedure corre, usa esta session para executar statements SQL, construir DataFrames e ler ou escrever dados. Para dizer ao Snowflake que esta função é uma stored procedure, colocas o decorator sproc diretamente acima da definição da tua função. O decorator atua como a camada de configuração. Usas o decorator para especificar o return type da tua procedure e quaisquer packages Python de terceiros que o teu código precise para correr. Quando executas o código de registo, o Snowpark pega na tua função Python, empacota-a juntamente com as suas dependências e regista-a no Snowflake. A partir daí, a lógica vive dentro da base de dados e é executada no compute do Snowflake. Pensa num data pipeline noturno. O teu processo precisa de criar uma tabela temporária, carregar raw data para lá, correr uma série de transformações multi-step e, finalmente, limpar os objetos temporários. Se correres isto a partir de um servidor externo, o teu código Python envia um comando pela rede, espera que o Snowflake termine, recebe o resultado de volta e envia o comando seguinte. Ao escreveres exatamente esta mesma lógica Python como uma stored procedure, todo o script é executado dentro do Snowflake. Usa o objeto session para percorrer as criações de tabelas e transformações de DataFrames nativamente. Há zero latência de rede entre a lógica de orquestração e os dados que ela manipula. Embora uma stored procedure não devolva um valor por linha como uma UDF, continua a devolver um único valor quando o script termina. Defines este return type quando configuras o decorator sproc. Muitas vezes, é uma simples string a confirmar o sucesso, um integer a representar o total de linhas processadas, ou até mesmo um resultado tabular a mostrar um log de execução. Tens opções sobre como fazer o deploy deste código. Podes definir e correr uma procedure anónima dinamicamente num script Python se só precisares dela para uma única session. Para pipelines automatizados, registas a procedure como um objeto permanente. O Snowflake guarda a definição para que qualquer utilizador autorizado, aplicação externa ou tarefa agendada a possa chamar mais tarde. Aqui está o ponto-chave. Escrever uma stored procedure em Snowpark Python significa que estás a tratar o Snowflake como um application runtime, e não apenas como uma storage layer. Estás a mover o cérebro da tua orquestração para bem perto dos dados que ela controla. Se gostas do podcast e queres apoiar o trabalho que fazemos, podes encontrar-nos pesquisando por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 15 de 17. Mover terabytes de dados seguros para um servidor externo de machine learning é lento, caro e arriscado. Gastas horas a transferir dados pela rede, e a tua equipa de segurança fica nervosa sobre onde eles vão parar. E se o compute viesse até aos dados? Esta é a ideia central por trás do treino de modelos de ML dentro do Snowflake. Ao utilizares o Snowpark Python, podes treinar modelos de machine learning single-node diretamente dentro do teu data warehouse usando stored procedures. Os dados nunca saem do perímetro do Snowflake. Isto resolve o problema da data gravity. Em vez de extraíres milhões de linhas para uma instância cloud separada, executas o teu script de treino exatamente onde os dados vivem atualmente. Treinar um modelo de machine learning requer carregar o dataset para a memória. Um virtual warehouse standard no Snowflake é otimizado para queries SQL paralelas, não para manter datasets massivos na RAM do sistema. Se tentares correr um algoritmo complexo num warehouse standard, provavelmente vais deparar-te com erros out-of-memory e o processo vai fazer crash. Para lidar com isto, precisas de um perfil de compute diferente. O Snowflake oferece warehouses Snowpark-optimized especificamente para esta tarefa. Estes warehouses fornecem até dezasseis vezes mais memória por node em comparação com instâncias standard. Vamos analisar um cenário concreto. Precisas de treinar um modelo random forest de scikit-learn num enorme dataset de clientes. Começas por escrever uma stored procedure em Python. Ao registares esta procedure, especificas os packages Python necessários, como scikit-learn, pandas e joblib. O Snowflake provisiona automaticamente estas dependências usando o seu canal Anaconda integrado. Também atribuis a procedure para correr no teu warehouse otimizado para o Snowpark. Dentro da procedure, usas o objeto de session do Snowpark para definir a tua query de dados de treino. De seguida, chamas o método para converter esse dataframe do Snowpark num dataframe pandas standard. Esta ação puxa os resultados da query diretamente para a memória física do node do warehouse. Como provisionaste o compute otimizado, há RAM suficiente para manter todo o dataset de uma só vez. A seguir, inicializas o teu modelo random forest e invocas o método fit, passando o dataframe do pandas. O processador do warehouse lida com o ciclo de treino exatamente como faria num servidor dedicado de machine learning. Assim que o modelo termina o treino, tens um algoritmo fitted na memória temporária do ambiente de execução. Tens de o persistir para previsões futuras antes que a stored procedure termine. É aqui que entra a serialização. Usas uma library como o joblib para empacotar o modelo. Pegas no objeto do modelo treinado em memória e fazes dump para um ficheiro, criando um artifact. De seguida, instruis a stored procedure a escrever esse ficheiro recém-criado diretamente para um stage interno do Snowflake. Um stage atua como uma pasta de storage segura vinculada à tua conta do Snowflake. Aqui está o insight principal. A tua stored procedure atua como um container seguro, ligando as tuas tabelas raw às libraries standard de machine learning do Python. Ao manteres o pipeline inteiramente dentro do Snowflake, reduzes a latência da tua rede para zero, contornas todas as operações de data egress, e manténs controlos de acesso rigorosos, tudo isto enquanto escreves exatamente o mesmo código de treino em Python que já conheces. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 16 de 17. Como é que processas ficheiros não estruturados na ordem dos gigabytes dentro de uma user-defined function sem rebentar com os teus limites de memória? Se tentares mapear ficheiros grandes como dependências estáticas, o sistema tenta fazer o download de tudo logo de início, e o teu código crasha. A solução para isto é o Dynamic File Access com o SnowflakeFile. Para perceberes porque é que isto importa, olha para como o acesso a ficheiros funciona normalmente no Snowpark. Normalmente, usas o parâmetro imports para vincular um ficheiro à tua função. Esta abordagem estática é ótima para pequenos ficheiros de configuração ou para um modelo de machine learning especializado, porque é feito o download do ficheiro para o compute warehouse antes da execução começar. Mas isto falha em grande escala. Se o teu pipeline precisar de processar centenas de ficheiros de log de servidor enormes ou PDFs de alta resolução armazenados num stage do Snowflake, fazer o download de todos eles de forma estática é incrivelmente lento e garante um erro de out-of-memory. É aqui que entra a classe SnowflakeFile. Localizada no módulo snowflake dot snowpark dot files, esta classe permite que a tua função ou stored procedure abra ficheiros diretamente de um stage em runtime. Não vinculas o ficheiro durante a criação da função. Em vez disso, a tua função aceita a localização do ficheiro como um argumento de string standard. Quando chamas a função na tua query SQL ou operação de dataframe, passas essa localização. Dentro do código Python, chamas o método open na classe SnowflakeFile e passas-lhe a string com a localização do ficheiro. Também especificas o modo de leitura, usando as convenções standard do Python, como r para texto ou r b para ler bytes. Aqui está o ponto chave. Chamar o open não carrega o ficheiro. Ele devolve um file-like object que faz stream dos dados. O ficheiro fica no stage, e tu puxas os dados através de um network pipe. Vamos aplicar isto ao cenário de processamento de logs. Tens uma tabela na base de dados onde cada linha contém um scoped URL a apontar para um ficheiro de log grande e diferente, num stage interno. Passas essa coluna de URL para a tua função. Dentro da função, abres a stream e escreves um loop standard para ler o ficheiro linha a linha. À medida que o teu código avalia cada linha para extrair códigos de erro ou timestamps, o Python descarta as linhas anteriores da memória. Podes fazer o parse de um ficheiro de log de cinquenta gigabytes enquanto a tua função mantém apenas uma única linha de texto em memória a qualquer milissegundo. Exatamente o mesmo conceito funciona para ficheiros binários. Se estiveres a extrair texto de PDFs grandes, abres o ficheiro em modo binário e passas a stream resultante diretamente para uma library de parsing de PDFs em Python. A library lê a byte stream sequencialmente, sem exigir que o documento inteiro resida na memória do sistema. O SnowflakeFile também lida com a security boundary automaticamente. Quando passas um scoped URL gerado dinamicamente para a tua função, o Snowflake concede acesso de leitura a esse ficheiro específico apenas durante a duração da query, expirando imediatamente quando a query termina. Fazer streaming de ficheiros especificados dinamicamente mantém o teu memory footprint flat, independentemente do tamanho do ficheiro, permitindo que o teu compute warehouse se concentre inteiramente em processar os dados, em vez de apenas tentar retê-los. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. Snowflake e Snowpark Python, episódio 17 de 17. Tu nunca farias deploy de código de uma aplicação de backend sem unit tests, então por que é que os data pipelines são frequentemente atirados para produção à sorte? O Snowpark muda isto ao tornar a tua lógica de dados modular, o que significa que finalmente a podes testar como software normal. Testar o Snowpark Python é o que traz o rigor da engenharia de software para a data engineering. O Snowpark permite-te extrair a tua lógica de transformação de scripts monolíticos para funções Python independentes. Como estas funções recebem um DataFrame como input e devolvem um DataFrame como output, podes testá-las usando frameworks Python standard. O PyTest é a escolha mais comum. Para correres qualquer código Snowpark, precisas de uma sessão ativa. Em vez de embeberes detalhes de autenticação dentro de cada teste, defines uma fixture de sessão. Fazes isso num ficheiro de configuração dedicado chamado conftest.py, que o PyTest reconhece automaticamente. Dentro deste ficheiro, escreves uma função de setup que estabelece uma ligação ao Snowflake, devolve o objeto da sessão e fecha a sessão quando os testes terminam. Decoras esta função como uma fixture do PyTest. Agora, qualquer teste no teu projeto pode pedir uma sessão ativa simplesmente pedindo-a pelo nome nos argumentos da função de teste. Vamos aplicar isto a um cenário concreto. Tens uma transformação de DataFrame custom e complexa que filtra utilizadores inativos, calcula um risk score e normaliza os nomes das colunas. Precisas de validar esta lógica antes de fazeres deploy do pipeline para produção. Começas por escrever um teste. O primeiro passo dentro desse teste é criar um DataFrame de input contendo algumas rows de mock data cuidadosamente selecionada. Defines os nomes exatos das colunas e os valores das rows necessários para fazer trigger aos edge cases específicos na tua lógica. Usas a tua fixture de sessão para converter esta mock data raw num DataFrame do Snowpark. A seguir, passas este DataFrame de input de mock para a tua função de transformação. A função aplica a tua business logic e devolve o DataFrame de output real. Agora precisas de verificar se a lógica fez o que era suposto fazer. Crias um segundo DataFrame de mock dentro do teu teste, desta vez a representar o resultado esperado exato. Esta é a parte que interessa. Tens de comparar o DataFrame real com o DataFrame esperado. No entanto, não podes simplesmente usar um equality check standard do Python nos próprios objetos DataFrame, porque eles são meramente referências para query plans. Em vez disso, precisas de comparar os dados que eles contêm. Chamas o método collect nos DataFrames real e esperado para puxar os resultados de volta para a memória como listas de objetos row. Como as bases de dados distribuídas não garantem a ordem dos result sets a não ser que sejam explicitamente instruídas, comparar duas listas de rows diretamente pode falhar, mesmo que os dados estejam corretos. Para corrigir isto, fazes sort a ambas as listas de rows antes de fazeres assert de que são iguais. Se os dados reais após o sort corresponderem aos dados esperados após o sort, o teu teste passa. Ao passares pequenos datasets controlados através de funções de transformação isoladas, apanhas erros lógicos localmente antes que eles sequer toquem numa tabela de produção. Isto isola os componentes do teu pipeline e torna o teu workflow de data engineering tão fiável quanto o desenvolvimento de software tradicional. Isto marca o fim da nossa série sobre Snowpark Python. Encorajo-te a explorar a documentação oficial do Snowflake, a tentares escrever estes testes hands-on, ou a visitares devstories.eu para sugerires tópicos para as nossas futuras séries. Gostaria de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Tem um ótimo dia!