CI/CD e DevOps in Snowflake (Parte 1): funzionalità e strumenti a confronto

Il DevOps nasce dall'idea di unire sviluppo e operations per realizzare, testare e rilasciare software in modo più rapido e affidabile. Si fonda su automazione, collaborazione e riduzione al minimo del rischio di errori in produzione. È una metodologia che combina le best practice di più ambiti con un obiettivo preciso: automatizzare tutto il possibile coprendo ogni fase del processo. Il codice va compilato, distribuito e testato ogniqualvolta serve. Il DataOps applica lo stesso approccio ai team che lavorano sui dati. Anziché limitarsi a gestire il codice applicativo, il DataOps tratta pipeline dati, trasformazioni e analytics come fossero software: versionati, testati e distribuiti in modo automatico. In sintesi, è il DevOps trasferito al mondo dei dati. Snowflake mette già a disposizione numerose funzionalità che, combinate fra loro, permettono di costruire pipeline dati automatizzate e gestire il deployment dell'infrastruttura. Vediamole nel dettaglio.

Declarative Change Management

Una delle prime cose da affrontare è la definizione tramite codice della propria infrastruttura Snowflake o di database. A questo scopo Snowflake mette a disposizione la funzionalità CREATE OR ALTER, che consente di definire gli oggetti Snowflake in modo dichiarativo. Dichiarativo significa che non occorre gestire il versioning né applicare le modifiche in modo incrementale: basta definire lo stato finale desiderato. Si specifica, ad esempio, come dovrà presentarsi lo schema di una tabella, un task o una view, e Snowflake fa il resto. Confronta automaticamente lo stato attuale con la definizione e applica dietro le quinte solo le modifiche necessarie.

CREATE OR ALTER

Con CREATE OR ALTER è sufficiente scrivere uno script DDL utilizzando questa parola chiave, e Snowflake garantisce che, una volta eseguito, l'oggetto rispecchi lo stato definito, senza doverlo ricreare. Si tratta di un aspetto particolarmente importante per oggetti come le tabelle, in cui eliminare e ricreare l'oggetto per modificarne lo schema (ad esempio aggiungendo o rimuovendo una colonna) potrebbe causare perdita di dati. CREATE OR ALTER, invece, preserva lo stato esistente e applica soltanto le modifiche indispensabili.

Ad alto livello, CREATE OR ALTER esegue queste operazioni:

• Confronta lo script con lo stato attuale nel database
• Genera le istruzioni DDL necessarie ad aggiornare l'oggetto
• Esegue tali istruzioni

Snowflake supporta già un'ampia gamma di oggetti a livello di database e di account definibili tramite CREATE OR ALTER, fra cui:

• Warehouse
• Database
• Schema
• Table
• View
• Stage
• Role
• Database Role
• Application
• Function
• External Function
• Procedure

⠀...e l'elenco si arricchisce regolarmente!

EXECUTE IMMEDIATE FROM

Un'altra potente funzionalità DevOps di Snowflake è EXECUTE IMMEDIATE FROM, che consente di eseguire comandi SQL direttamente da file salvati in uno stage interno o in un repository GitHub. Questi file possono contenere istruzioni SQL standard o blocchi Snowflake Scripting.

È esattamente ciò che serve per fare il deploy degli oggetti in Snowflake. Anziché ricorrere a complessi meccanismi di importazione, si possono salvare gli script DDL con le definizioni degli oggetti ed eseguirli direttamente dallo stage: semplice ed efficiente. Tra le novità più recenti spicca il supporto al templating Jinja. Con i template Jinja gli script SQL e le definizioni DDL diventano molto più dinamici, grazie all'integrazione di:

• Variabili
• Cicli
• Condizioni
• Macro e altro ancora

Le variabili d'ambiente, ad esempio, permettono di parametrizzare i deployment e di scegliere dinamicamente l'ambiente di destinazione. I cicli consentono di iterare su utenti, warehouse o qualsiasi altro oggetto definito, semplificandone creazione e manutenzione. All'interno dei template è persino possibile richiamare contenuti da altri file presenti negli stage. Possibilità che si moltiplicano.

EXECUTE IMMEDIATE aggiunge un valore notevole quando si predispongono deployment automatizzati. Cosa serve a questo punto? Senza dubbio, mettere gli script DDL sotto version control. Non si sa mai cosa possa succedere: servono la possibilità di tornare indietro sulle modifiche, di tracciare ciò che è stato cambiato e di sapere chi ha apportato ogni intervento. Il version control garantisce trasparenza, responsabilità e sicurezza nei deployment.

Integrazione GIT

Snowflake offre anche un'integrazione Git nativa, che permette di salvare il codice in un repository remoto e sincronizzarlo con uno stage interno. In questo modo tutti i file sono disponibili per l'esecuzione direttamente all'interno di Snowflake. Pur essendo attualmente in sola lettura (con qualche eccezione), l'integrazione Git colma un'ulteriore lacuna nella costruzione di una pipeline di deployment completa e automatizzata.

Proviamo a sfruttare l'integrazione GIT con EXECUTE IMMEDIATE per eseguire uno script di creazione utente dal repository:

1: Crea il file users.sql

CREATE USER joe;
GRANT ROLE developer TO USER joe;

2: Esegui il commit delle modifiche sul repository:

git add users.sql
git commit -m "Adding new user"
git push

3: Recupera gli aggiornamenti dal repository remoto nello stage del repository Snowflake

1ALTER GIT REPOSITORY snowflake_git_demo FETCH;

4: Esegui il codice dal file in Snowflake

1EXECUTE IMMEDIATE FROM @snowflake_git_demo/branches/main/sql/users.sql;

Abbiamo approfondito l'argomento in un articolo dedicato, che offre una panoramica completa delle capacità di integrazione Git di Snowflake e una guida passo passo. Scoprirai:

• Che cos'è la Git Integration di Snowflake
• Perché è una funzionalità così interessante
• Come utilizzarla per fare il deploy con facilità di un handler di stored procedure
• Quali operazioni sono supportate in Snowflake
• Limiti attuali
• I vari casi d'uso dell'integrazione Git

Ora che sappiamo come definire l'infrastruttura come codice, eseguirla e versionarla, cosa ci manca? L'ultimo tassello è l'orchestrazione, che va letta da due punti di vista:

1. La prospettiva Snowflake – come connettersi, selezionare i file giusti ed eseguire le query 2. La prospettiva di processo – come racchiudere tutto in una pipeline autonoma attivabile da eventi diversi

Per ora concentriamoci sulla prospettiva Snowflake. Tratteremo l'aspetto di processo nella prossima parte, dove costruiremo una pipeline completa da zero.

SnowSQL

È il client CLI originale di Snowflake e permette di svolgere molte delle attività disponibili tramite interfaccia utente: eseguire query, gestire oggetti, importare ed esportare dati e così via. Supporta tutti i principali sistemi operativi e offre diversi metodi di autenticazione. Per molti anni SnowSQL è stato lo strumento di riferimento, in particolare per gli amministratori, ma è arrivato il momento di voltare pagina: Snowflake CLI è il nuovo standard e dovrebbe diventare la scelta privilegiata d'ora in avanti, anche perché alcune funzionalità potrebbero non essere più aggiunte a SnowSQL.

Snowflake CLI

Si tratta di un progetto open source, nato dalla community e oggi interamente mantenuto da Snowflake. La CLI funge soprattutto da interfaccia per gli sviluppatori per gestire diversi tipi di codice in Snowflake — stored procedure, funzioni, native app e Streamlit app, Snowpark, Snowpark Container Services, repository Git e molto altro. Copre un'ampia gamma di casi d'uso pensati per semplificare la gestione di codice e infrastruttura in Snowflake. Dal punto di vista DevOps, entrambi i tool CLI consentono di eseguire query in Snowflake, quindi la scelta dipende spesso dalle preferenze personali. Nel nostro caso utilizzeremo il client CLI per connetterci a Snowflake ed eseguire queste operazioni:

• Sincronizzare lo stage Git con il repository remoto
• Distribuire il codice eseguendo comandi EXECUTE IMMEDIATE per creare oggetti infrastrutturali come role, warehouse, database e altro

Abbiamo passato in rassegna i mattoni fondamentali che Snowflake mette a disposizione in ambito DevOps. Combinando queste funzionalità si possono costruire pipeline solide e automatizzate per gestire la propria infrastruttura Snowflake. Le capacità native di Snowflake, però, non sono l'unica strada: esistono numerose alternative altrettanto valide. Vediamo le più diffuse per avere un quadro più completo.

Terraform

Terraform è probabilmente lo strumento più diffuso in questo ambito. Consente di definire gli oggetti Snowflake come codice e di gestirli alla stregua di qualsiasi altra infrastruttura cloud. Chi ha già dimestichezza con l'Infrastructure as Code (IaC) lo percepirà come un'estensione naturale. Per molti team Terraform è la prima scelta, soprattutto se viene già impiegato per gestire l'infrastruttura cloud: estenderne l'uso a Snowflake risulta quasi automatico. Il provider Snowflake ufficiale è maturato in modo significativo nel tempo ed è recentemente passato in General Availability. Il supporto per nuovi oggetti viene ampliato di continuo. Per approfondire l'uso di Terraform con Snowflake, dai un'occhiata al nostro articolo dedicato.

Permifrost

Permifrost è uno strumento open source pensato espressamente per gestire i permessi in Snowflake tramite codice. Scritto in Python, permette di definire ruoli, grant e ownership in file YAML. Gestire i privilegi tramite codice offre un approccio più scalabile e controllato rispetto alla configurazione manuale dall'interfaccia o alla scrittura di grant SQL grezzi. Permifrost adotta un modello dichiarativo per gestire i permessi in Snowflake. Il suo perimetro, però, è limitato: si occupa esclusivamente di permessi e ruoli, non della creazione o dell'eliminazione degli oggetti, e risulta quindi meno completo rispetto ad altre alternative.

Titan

Titan è un altro strumento open source per il deployment dell'infrastruttura Snowflake come codice. Scritto in Python, punta a superare alcuni limiti di Terraform: consente di passare dinamicamente da un ruolo all'altro (ad esempio SECURITYADMIN vs SYSADMIN), utilizza definizioni in Python (eliminando la necessità di imparare un nuovo linguaggio o una nuova sintassi) e supporta SQL. Inoltre non si appoggia a file di stato come Terraform.

Titan, tuttavia, utilizza i nomi come identificatori univoci: rinominare una risorsa comporta quindi la creazione di una nuova risorsa. E poiché è ancora in attivo sviluppo, il supporto per alcune risorse potrebbe essere limitato.

Una breve nota: il progetto è portato avanti principalmente da una sola persona, oggi impegnata su altri fronti. Tienine conto al momento di valutare le opzioni.

Schema change

L'ultimo in elenco è forse il più datato. È uno strumento imperativo basato su Python: le modifiche vengono distribuite come una serie di alterazioni (istruzioni ALTER) applicate agli oggetti originari. Occorre mantenere script versionati e tenere traccia dello storico di applicazione delle modifiche. Schema Change applica poi solo le novità rispetto a quanto già registrato. Se, ad esempio, si crea una tabella con Schema Change e in un secondo momento si rende necessario aggiungere o rimuovere una colonna o apportare altre modifiche, bisognerà scrivere uno script ALTER con un nuovo numero di versione.

Schema Change lavora con due tipologie di script: versioned e repeatable. Gli script repeatable vengono distribuiti a ogni esecuzione dello strumento (se viene rilevata una modifica). È un approccio utile per le view, dove ricreare l'oggetto non è considerato un cambiamento distruttivo. Un altro concetto chiave di Schema Change è lo storico degli script applicati, conservato in una tabella del database.

Proviamo a riassumere pro e contro di questi strumenti alternativi in una tabella.

Come si nota dalla tabella, la scelta dello strumento giusto dipende da fattori diversi: gli aspetti che si vogliono automatizzare (infrastruttura, permessi o solo script SQL), le competenze già presenti in team o i requisiti di piattaforma. Ogni strumento può rivelarsi adatto a scenari differenti.

Per concludere, abbiamo passato in rassegna le funzionalità native di Snowflake per il DevOps insieme alle principali alternative disponibili sul mercato, offrendo una panoramica completa delle attività DevOps in Snowflake. Nel prossimo articolo entreremo nel vivo con una guida all'implementazione passo passo!

Tomáš Sobotík·Senior Data Engineer & Snowflake SME presso Norlys

Tomas è da tempo Snowflake Data SuperHero ed esperto di riferimento in tutto ciò che riguarda Snowflake. La sua esperienza nel mondo dei dati si estende per oltre un decennio, in cui ha ricoperto i ruoli di Snowflake data engineer, architect e admin in progetti diversi, attraverso settori e tecnologie eterogenei. È un membro di spicco della community, in cui condivide attivamente le sue competenze e ispira gli altri. È inoltre instructor per O'Reilly, dove tiene sessioni di formazione live online.