Da quando ho iniziato a usare Snowflake, c'è una cosa che ho sempre ritenuto mancasse: un'integrazione Git nativa. Senza version control era facile compromettere la propria infrastruttura, ma per fortuna ora le cose sono cambiate. L'integrazione Git di Snowflake è stata rilasciata ad aprile 2024 ed è una funzionalità che personalmente avevo richiesto più volte! Vediamola più da vicino, capiamo come utilizzarla e analizziamo alcuni casi d'uso tipici.
Cos'è l'integrazione Git di Snowflake?
L'integrazione Git di Snowflake permette di collegare nativamente il proprio account Snowflake a una delle piattaforme Git supportate (GitHub, GitLab, ecc.) e di sincronizzare il contenuto di un repository remoto con l'account Snowflake. Per questa sincronizzazione, Snowflake utilizza un tipo speciale di stage chiamato repository stage. Il repository stage viene sincronizzato con il repository Git remoto e diventa un repository locale con un clone completo di quello remoto, comprensivo di tutto ciò che ci si aspetta: branch, commit e così via.
Grazie a questa sincronizzazione si dispone di un clone completo del repository direttamente nel proprio account Snowflake. È possibile utilizzare i file recuperati nelle applicazioni Snowflake oppure scrivere UDF e stored procedure il cui handler code è memorizzato in un repository Git remoto e sincronizzato con il repository stage. In questo modo è facile mantenerlo sotto version control e aggiornare lo stage ogni volta che il repository viene modificato.
È inoltre possibile utilizzare qualsiasi file da qualsiasi branch o commit direttamente in Snowflake.
Perché questa nuova funzionalità è così interessante?
Grazie a questa integrazione è possibile semplificare il ciclo di sviluppo del codice quando lo si vuole mantenere sotto version control. Prendiamo come esempio l'handler code di una stored procedure. Prima di questa integrazione, il version control andava gestito autonomamente e al di fuori di Snowflake. Si scriveva e testava l'handler code in VS Code. Terminato lo sviluppo, bisognava fare il commit delle modifiche su un repository remoto per mantenerle sotto version control. In parallelo, occorreva anche fare il deploy del codice in Snowflake e creare una stored procedure usando quel codice come handler.
Questo significava caricare manualmente il codice in uno stage Snowflake e creare poi la stored procedure, oppure utilizzare la Snowflake CLI per gestire sia il caricamento che la creazione della stored procedure. In entrambi i casi si trattava di un passaggio aggiuntivo non direttamente collegato al codice versionato. Per ogni modifica si doveva ripetere l'intero processo: sviluppare il codice, fare il commit sul repository e aggiornare il file handler in Snowflake.
Vediamo come l'integrazione Git nativa snellisca tutto questo. Poiché è possibile referenziare l'handler code direttamente nel repository stage, ogni volta che si effettua il commit delle modifiche e si sincronizza il repository stage, l'handler della stored procedure viene aggiornato automaticamente e resta sotto version control. Niente più processi multipli e separati (version control e aggiornamento delle SP): un unico flusso di lavoro snello.
L'integrazione Git di Snowflake permette di collegare repository Git dalle seguenti piattaforme supportate:
- GitHub
- GitLab
- BitBucket
- Azure DevOps
- AWS CodeCommit
Esempio end-to-end dell'integrazione Git
In questo esempio scriveremo un semplice handler di stored procedure Hello World in Python, faremo il commit delle modifiche su un repository GitHub remoto e lo porteremo in Snowflake tramite l'integrazione Git. Poi modificheremo l'handler code e vedremo con quanta facilità sia possibile aggiornarlo in Snowflake grazie all'integrazione. Iniziamo da un semplice diagramma che illustra ciò che andremo a costruire:
- Per prima cosa sviluppiamo l'handler code localmente in VS Code e ne facciamo il commit su un repository GitHub.
- Successivamente creiamo un repository stage in Snowflake che punta al repository remoto. Dobbiamo anche creare un nuovo secret per memorizzare le credenziali del nostro account Git.
- Una volta creato il repository stage in Snowflake, lo sincronizziamo con il repository remoto per portare il codice in Snowflake.
- Infine, creiamo una stored procedure in Snowflake e importiamo l'handler code dal nostro repository stage.
Vediamo ogni passaggio nel dettaglio.
1. Sviluppo dell'handler code
Ho creato una semplice funzione handler chiamata hello_world e l'ho pushata sul mio repository. Ora possiamo procedere con la creazione degli oggetti necessari in Snowflake e collegare questo repository remoto a un nuovo repository stage.
2. Creazione del secret
Iniziamo dalla creazione del secret. Per l'autenticazione utilizzo un personal access token.
3. Creazione dell'API integration
Ci serve anche una nuova API integration per collegare Snowflake con GitHub. Il parametro API_ALLOWED_PREFIXES punta all'URL del mio account GitHub e per l'autenticazione utilizziamo il secret creato al passaggio precedente.
4. Creazione del repository stage
Infine possiamo creare un repository stage Git e passare i valori creati in precedenza. L'origine è il repository Git al quale vogliamo collegarci.
5. Sincronizzazione del repository stage con il remoto
Il repository stage è pronto: sincronizziamolo con il repository remoto.
6. Creazione della stored procedure
Ed è fatta! Abbiamo un'integrazione funzionante tra Snowflake e il repository Git remoto. L'handler della nostra stored procedure proviene dal repository stage, sincronizzato con il repository remoto. Creiamo ora la stored procedure:
7. Sincronizzazione con il repository remoto
Come possiamo provare a eseguirla?
Modifichiamo ora il codice per vedere con quanta facilità sia possibile recuperare gli aggiornamenti in Snowflake. Anche stavolta apporteremo le modifiche localmente in VS Code e ne faremo il commit sul repository remoto. Facciamo una piccola modifica per convertire il messaggio in maiuscolo.
Una volta effettuato il commit delle modifiche sul repository, dobbiamo aggiornare (sincronizzare) il repository stage in Snowflake.
1ALTER GIT REPOSITORY snowflake_git_demo FETCH;
Ora abbiamo l'handler code aggiornato disponibile in Snowflake! Tutto qui: non serve altro. Niente ricreazione della procedura, niente di tutto questo. Basta eseguire la stored procedure per verificare che il codice sia aggiornato:
8. Aggiornamento automatico al merge
C'è un modo per automatizzare questo processo. Supponiamo di lavorare con Git secondo la prassi standard, mantenendo le modifiche al codice su feature branch separati che poi vengono mergiati nel branch main. Possiamo costruire un workflow GitHub Actions che esegua il comando ALTER GIT REPOSITORY al merge della PR, così da aggiornare automaticamente il repository stage ogni volta che si pusha nuovo codice sul branch main!
Ecco un semplice esempio. Per eseguire l'istruzione SQL si può utilizzare SnowSQL oppure SnowCLI.
TORY command when the PR is merged, so the repository stage is automatically updated every time you push new code into your main branch!
Here is a simple example. You can use either SnowSQL or SnowCLI to run the SQL statement.
name: Deploying Stored procedure updates
env:
SNOWSQL_ACCOUNT: ${{secrets.SF_ACCOUNT}}
SNOWSQL_USER: ${{secrets.SF_USER}}
SNOWSQL_PWD: ${{secrets.SF_PASSWORD}}
SNOWSQL_DATABASE: ${{ secrets.SF_DATABASE }}
SNOWSQL_SCHEMA: ${{ secrets.SF_SCHEMA }}
SNOWSQL_ROLE: ${{ secrets.SF_ROLE }}
SNOWSQL_WAREHOUSE: ${{ secrets.SF_WAREHOUSE }}
on:
Espandi il codice
Ed ecco l'output dell'esecuzione del workflow GitHub Actions:
Operazioni aggiuntive
Ora che abbiamo visto come configurare l'integrazione Git, ci sono altre funzionalità che potrebbe valere la pena esplorare:
Gestire i repository in Snowflake
Il nostro esempio ha mostrato solo due operazioni relative ai repository Git in Snowflake: la creazione del repository stage e il comando ALTER per recuperare gli aggiornamenti remoti. Vediamo altri esempi di ciò che si può fare con i propri repository:
Elencare i branch del repository
Possiamo elencare tutti i branch presenti nel repository stage, insieme al path e all'hash del commit.
1SHOW GIT BRANCHES IN snowflake_git_demo;
Elencare i file del repository
Come per gli stage interni o esterni, anche nel repository stage possiamo elencare i file con il comando LIST:
1LS @snowflake_git_demo
Repository stage
Nel caso del repository stage, però, possiamo elencare i file per singolo branch:
1LS @snowflake_git_demo/branches/main
Hash del singolo commit
1LS @snowflake_git_demo/commits/<<add_my_commit_hash>>
Elencare i file per nome di tag
1LS @snowflake_git_demo/tags/tag_name
Verificare le proprietà del repository stage
Come per molti altri oggetti Snowflake, anche per i repository stage sono disponibili i comandi SHOW e DESCRIBE, che mostrano metadati utili: dove si trova il repository stage (nome di database e schema), qual è l'origin del repo remoto, quale API integration viene usata per collegare Git e Snowflake e qual è il nome del secret che custodisce le credenziali per la connessione al repository Git remoto.
Eseguire il codice da un repository
Tenere i file in un repository è utile, ma che dire dell'esecuzione del codice contenuto in quei file? Ci avete pensato? Snowflake mette a disposizione il comando EXECUTE IMMEDIATE FROM, che consente di eseguire codice SQL direttamente dai file. Potete tenere la configurazione del vostro account (creazione di utenti, ruoli, warehouse) in file SQL nel repo ed eseguirla direttamente dal file grazie a questo comando:
EXECUTE IMMEDIATE FROM @snowflake_git_demo/branches/main/sql/users.sql
Copiare il codice dal repository in un worksheet
È inoltre possibile copiare il codice dei file memorizzati nel repository stage nei propri worksheet. Si può copiare il contenuto sia dai file .sql sia dai file .py. Una volta copiato, il codice può essere modificato o eseguito nei worksheet di Snowsight. Basta aprire il file da cui copiare e selezionare l'opzione Copy into worksheet.
Limitazioni
Per salvare le modifiche sul repository è necessario operare sulla copia locale, perché al momento i repository in Snowflake sono in sola lettura, fatta eccezione per i Notebook, che possono anche scrivere. Quindi solo i Notebook permettono di riscrivere sui repository. Altre limitazioni della funzionalità al momento della stesura di questo articolo sono:
- Supporto in sola lettura — vedi sopra
- Solo accesso da internet pubblico. Non è possibile accedere a repository protetti da una rete privata.
- Il repository stage non può essere condiviso tramite data sharing.
- Non è possibile creare un repository stage all'interno di un application package.
- Non è possibile creare un repository stage all'interno di una native app sul lato cliente.
- L'accesso ai file nel repository stage potrebbe essere più lento rispetto agli stage interni di Snowflake. Non usatelo per casi d'uso di data ingestion.
- I submodule al momento non sono supportati.
Casi d'uso dell'integrazione Git di Snowflake
L'esempio end-to-end ha illustrato uno dei possibili casi d'uso dell'integrazione Git in Snowflake: mantenere il codice di procedure e UDF sotto version control in un repository remoto. Ma non è l'unico.
L'integrazione Git è fondamentale anche per gestire il proprio account secondo le pratiche DevOps. È possibile mantenere le definizioni degli oggetti Snowflake (database, warehouse, utenti, ruoli, ecc.) in un repository remoto come file SQL con definizioni CREATE o ALTER ed eseguirle all'interno delle proprie pipeline CI/CD. Grazie ai repository stage si dispone di una copia di tali definizioni direttamente in Snowflake e si può eseguire il codice da lì, senza bisogno di alcun runner esterno per fare il deploy degli oggetti!
Un altro caso d'uso riguarda le app native/Streamlit, in cui il codice può essere integrato nativamente con i repository remoti. Infine, se utilizzate Snowflake per le vostre trasformazioni dati — DAG con task o dynamic tables — potete tenere le definizioni della pipeline sotto version control e integrarle facilmente con i repository stage e l'ambiente Snowflake.
Tomáš Sobotík·Senior Data Engineer & Snowflake SME presso Norlys
Tomas è da tempo Snowflake Data SuperHero ed esperto di riferimento su Snowflake. La sua vasta esperienza nel mondo dei dati si estende per oltre un decennio, durante il quale ha ricoperto i ruoli di data engineer, architect e admin Snowflake in progetti di settori e tecnologie diverse. Tomas è un membro chiave della community e condivide attivamente la sua competenza ispirando gli altri. È anche istruttore O'Reilly e conduce sessioni di formazione live online.