Análisis a fondo de la integración de Git en Snowflake

La integración de Git en Snowflake te permite conectar de forma nativa tu cuenta de Snowflake con alguna de las plataformas de Git compatibles (GitHub, GitLab, etc.) y sincronizar el contenido de un repositorio remoto con tu cuenta. Para esta sincronización, Snowflake utiliza un tipo especial de stage llamado repository stage. Este repository stage se sincroniza con el repositorio remoto de Git y se convierte en un repositorio local con un clon completo del remoto, con todo lo que esperarías: ramas, commits, etc.

Con esta sincronización tienes un clon completo del repositorio disponible directamente en tu cuenta de Snowflake. Puedes usar los archivos descargados en tus aplicaciones de Snowflake o escribir UDFs/stored procedures cuyo código de handler vive en un repositorio remoto de Git y se sincroniza con el repository stage. Así lo mantienes bajo control de versiones sin complicaciones y refrescas el stage cada vez que el repositorio se actualiza.

También puedes usar cualquier archivo de cualquier rama o commit directamente en Snowflake.

Gracias a esta integración puedes simplificar el ciclo de desarrollo de tu código si quieres mantenerlo bajo control de versiones. Tomemos como ejemplo el código del handler de un stored procedure. Antes de esta integración tenías que gestionar el control de versiones por tu cuenta y fuera de Snowflake. Escribías y probabas el código del handler en VS Code. Al terminar el desarrollo tenías que hacer commit de los cambios a un repositorio remoto para mantenerlos versionados. Al mismo tiempo, también tenías que desplegar el código en Snowflake y crear un stored procedure con ese código como handler.

Esto implicaba subir manualmente el código a un stage de Snowflake y luego crear el stored procedure, o bien usar el Snowflake CLI para gestionar tanto la subida como la creación del stored procedure. En cualquier caso, era un paso adicional que no estaba conectado directamente con tu código versionado. Si necesitabas modificar el código, tenías que volver a pasar por todo el proceso: desarrollarlo, hacer commit al repositorio y actualizar el archivo del handler en Snowflake.

Veamos cómo la integración nativa de Git puede simplificar este proceso. Como puedes referenciar el código del handler directamente desde el repository stage, cada vez que haces commit de los cambios y sincronizas tu repository stage, el handler del stored procedure se actualiza automáticamente y se mantiene bajo control de versiones. Se acabaron los procesos paralelos (control de versiones y actualizaciones del SP por separado): un único flujo de trabajo unificado.

La integración de Git en Snowflake te permite conectar repositorios de Git desde las siguientes plataformas compatibles:

• GitHub
• GitLab
• BitBucket
• Azure DevOps
• AWS CodeCommit

En este ejemplo vamos a escribir un sencillo handler de stored procedure Hello World en Python, hacer commit de los cambios a un repositorio remoto de GitHub y traerlo a Snowflake mediante la integración de Git. Después modificaremos el código del handler y veremos lo fácil que resulta actualizarlo en Snowflake gracias a esta integración. Primero, veamos un diagrama sencillo de lo que vamos a construir:

1. Primero desarrollamos el código del handler localmente en VS Code y le hacemos commit a un repositorio de GitHub.
2. Después creamos un repository stage en Snowflake que apunta al repositorio remoto. También necesitamos crear un nuevo secret para guardar las credenciales de nuestra cuenta de Git.
3. Una vez que tenemos el repository stage en Snowflake, lo sincronizamos con el repositorio remoto para traer el código a Snowflake.
4. Por último, creamos un stored procedure en Snowflake e importamos el código del handler desde nuestro repository stage.

Veamos cada paso con más detalle.

1. Desarrollo del código del handler

Creé una función handler sencilla llamada hello_world y la subí a mi repositorio. Ahora podemos crear los objetos necesarios en Snowflake y vincular este repositorio remoto a un nuevo repository stage.

2. Creación del secret

Empecemos por la creación del secret. Yo uso un personal access token para la autenticación.

3. Creación de la API integration

También necesitamos una nueva API integration para conectar Snowflake con GitHub. El parámetro API_ALLOWED_PREFIXES apunta a la URL de mi cuenta de GitHub y, para la autenticación, usamos el secret creado en el paso anterior.

4. Creación del repository stage

Por último, ya podemos crear un repository stage de Git y pasarle los valores que creamos antes. El origin es nuestro repositorio de Git, al que queremos conectarnos.

5. Sincronizar el repository stage con el remoto

Ya tenemos el repository stage listo; sincronicémoslo con el repositorio remoto.

6. Creación del stored procedure

¡Y eso es todo! Ahora tenemos una integración funcionando entre Snowflake y el repositorio remoto de Git. El handler de nuestro stored procedure se obtiene del repository stage, que está sincronizado con el repositorio remoto. Creemos un stored procedure:

7. Sincronización con el repositorio remoto

¿Cómo lo probamos?

Ahora modifiquemos el código para ver lo fácil que es traer las actualizaciones a Snowflake. De nuevo, haremos los cambios localmente en VS Code y los subiremos al repositorio remoto. Hagamos un cambio sencillo para convertir el mensaje a mayúsculas.

Una vez que los cambios están en el repositorio, hay que actualizar (sincronizar) nuestro repository stage en Snowflake.

1ALTER GIT REPOSITORY snowflake_git_demo FETCH;

¡Listo! Ya tenemos el código actualizado del handler disponible en Snowflake. Nada más que hacer: ni recrear el procedure ni nada parecido. Basta con ejecutar el stored procedure para comprobar que el código está actualizado:

8. Actualización automática al hacer merge

Esto se puede automatizar. Supongamos que sigues un flujo estándar de Git, donde mantienes los cambios de código en feature branches independientes que se mergean a la rama main. Podemos crear un workflow de GitHub Actions que ejecute el comando ALTER GIT REPOSITORY cuando se mergea el PR, de modo que el repository stage se actualice automáticamente cada vez que subes código nuevo a tu rama main.

Aquí tienes un ejemplo sencillo. Puedes usar SnowSQL o SnowCLI para ejecutar la instrucción SQL.

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:

Expandir código

Y este es el resultado de la ejecución del workflow de GitHub Actions:

Ya vimos cómo configurar la integración de Git; ahora hay más funcionalidades que tal vez quieras explorar:

Gestión de repositorios en Snowflake

Nuestro ejemplo mostró solo dos operaciones relacionadas con los repositorios de Git en Snowflake: la creación del repository stage y el comando ALTER para traer las actualizaciones remotas. Veamos otros ejemplos de lo que puedes hacer con tus repositorios:

Listar las ramas del repositorio

Podemos listar todas las ramas de nuestro repository stage, junto con la ruta y el hash del commit.

1SHOW GIT BRANCHES IN snowflake_git_demo;

Listar los archivos del repositorio

Igual que se listan archivos en cualquier stage interno o externo, también podemos listar los del repository stage con el comando LIST:

1LS @snowflake_git_demo

Repository stage

Pero en el caso del repository stage, podemos listar los archivos por nombre de rama:

1LS @snowflake_git_demo/branches/main

Hash de commit individual

1LS @snowflake_git_demo/commits/<<add_my_commit_hash>>

Listar archivos por nombre de tag

1LS @snowflake_git_demo/tags/tag_name

Revisar las propiedades del repository stage

Como ocurre con muchos otros objetos de Snowflake, también existen los comandos SHOW y DESCRIBE para los repository stages, que muestran metadatos útiles: dónde está ubicado el repository stage (nombre de la base de datos y el schema), cuál es el origin del repo remoto, qué API integration se usa para conectar Git y Snowflake y el nombre del secret que guarda las credenciales para la conexión con el repositorio remoto.

Ejecutar el código desde un repositorio

Tener archivos en un repositorio es útil, pero ¿y ejecutar el código que contienen? ¿Lo habías pensado? Snowflake tiene el comando EXECUTE IMMEDIATE FROM, que te permite ejecutar código SQL directamente desde archivos. Puedes guardar la configuración de tu cuenta (creación de usuarios, roles, warehouses) en archivos SQL dentro del repo y, gracias a este comando, ejecutarla directamente desde el archivo:

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

Copiar código del repositorio a un worksheet

También puedes copiar código de archivos del repository stage a tus worksheets. Funciona con archivos .sql o .py. Después puedes editarlo o ejecutarlo en los worksheets de Snowsight. Solo tienes que ir al archivo que quieres copiar y seleccionar la opción Copy into worksheet.

Si quieres guardar tus cambios de vuelta en el repositorio, tienes que hacerlo en tu copia local, ya que actualmente los repositorios son de solo lectura en Snowflake, salvo en los Notebooks, que sí pueden escribir de vuelta. Es decir, solo puedes usar Notebooks para escribir hacia los repositorios. Otras limitaciones de la funcionalidad al momento de escribir este artículo:

• Soporte de solo lectura: ver arriba.
• Solo acceso por internet público. No se pueden acceder a repositorios detrás de una red privada.
• El repository stage no se puede compartir mediante data sharing.
• No se puede crear un repository stage dentro de un application package.
• No se puede crear un repository stage dentro de una native app del lado del cliente.
• Acceder a los archivos del repository stage puede ser más lento que hacerlo en un stage interno de Snowflake. No lo uses para casos de ingesta de datos.
• Por ahora no hay soporte para submódulos.

El ejemplo de punta a punta mostró uno de los posibles casos de uso de la integración de Git en Snowflake: mantener el código de tus procedures/UDFs bajo control de versiones en un repositorio remoto. Pero no es el único.

La integración de Git también es clave para gestionar tu cuenta aplicando prácticas de DevOps. Puedes mantener las definiciones de tus objetos de Snowflake (bases de datos, warehouses, usuarios, roles, etc.) en un repositorio remoto como archivos SQL con sentencias CREATE o ALTER y ejecutarlas dentro de tus pipelines de CI/CD. Gracias a los repository stages, tienes una copia de esas definiciones disponible directamente en Snowflake y puedes ejecutar el código ahí mismo, sin depender de ningún runner externo para desplegar esos objetos.

Otro caso de uso tiene que ver con tus native/Streamlit apps, donde puedes tener el código integrado de forma nativa con los repositorios remotos. Y por último, si usas Snowflake para tus transformaciones de datos (DAGs con tasks o dynamic tables), puedes mantener las definiciones de los pipelines bajo control de versiones e integrarlas fácilmente con los repository stages y el entorno de Snowflake.

Tomáš Sobotík·Senior Data Engineer y Snowflake SME en Norlys

Tomas es Snowflake Data SuperHero desde hace años y un referente reconocido en Snowflake. Su amplia trayectoria en el mundo de los datos abarca más de una década, durante la cual ha trabajado como data engineer, arquitecto y administrador de Snowflake en distintos proyectos, industrias y tecnologías. Tomas es miembro activo de la comunidad: comparte su conocimiento e inspira a otros. Además es instructor en O'Reilly, donde imparte sesiones de formación en vivo online.