Infra As Code avec snowflake

Published in

Mistertemp’s kitchen

4 min readSep 13, 2022

Suite au snowflake summit 2022 à Las Vegas dont certains d’entre nous ont pu participer, nous avons appris, en regroupant plusieurs sessions les bonnes pratiques DevOps et surtout l’Infra As Code (IaC) qui nous est chère chez Mistertemp’.

Dans les bonnes pratiques de développement, il y a le versionning et le stockage des sources en utilisant entre autres des outils comme git. Cela permet d’avoir un suivi, un historique et de compiler une application dans une certaine version . Dans la data cette bonne pratique n’est pas toujours une évidence, mais chez Mistertemp’, elle l’est. Elle est à la base du déploiement continu et des pratiques DevOps.

Dans le cadre de snowflake, les composantes qu’il faut versionner, déployer et utiliser peuvent être divisés en deux parties distinctes :

Les objets infrastructure like (warehouse, users, role, pipe, etc…)
Les objets dataset (Table, View, Stream)

Infrastructure objects with terraform

Terraform est un outil d’IaC qui permet de convertir des fichiers de configuration en infrastructure. Il fonctionne avec la plupart des clouds publics (AWS, GCP, Azure) mais il permet aussi d’ajouter des providers pour pouvoir gérer d’autres clouds (fivetran, snowflake, …). Les providers sont créés soit par hashicorp (les développeurs de Terraform), soit par les clouds provider ou la communauté. Dans le cadre de snowflake, le provider a été développé initialement par la communauté et a depuis peu été récupéré par snowflake-labs. La récupération du projet par snowflake est une bonne nouvelle, car elle montre un intérêt fort de snowflake sur l’IaC. De plus les nouveautés pourront être intégrées plus rapidement au provider.

Le provider snowflake permet donc assez facilement de créer un nouveau warehouse par exemple:

resource snowflake_warehouse w {
    name= "my_iac_warehouse"
    comment = "my iac created warehouse"
    warehouse_size = "small" 
}

Ou bien de créer une database (DB) et un schema dans cette DB en utilisant des variables :

resource "snowflake_database" "my_db" {
  name                        = "my_iac_db"
  data_retention_time_in_days = 3
}resource snowflake_schema schema {
  database = snowflake_database.my_db.name
  name     = "my_iac_schema"  is_transient        = false
  is_managed          = false
  data_retention_days = 3
}

Le fait de pouvoir ajouter et utiliser des variables va permettre de créer de nouveaux environnements facilement. L’IaC permet de versionner l’infrastructure snowflake sous forme de code et de la recréer “from scratch” mais aussi de la faire évoluer de manière incrémentale grâce à Terraform.

Les bonnes pratiques sont d’éviter un maximum d’avoir les tables dans Terraform, mais d’utiliser plutôt un outil comme DBT pour les générer et de traiter le “change management” de la data.

Database change management

Approche declarative vs imperative

Imperative:

Création de plusieurs scripts qui s’exécutent dans un certain ordre pour mettre à jour la structure de la base de données.

# v1
CREATE TABLE Foo {
  Column1 INT,
  Column2 DATE,
};# v2
ALTER TABLE Foo ADD Column3 VARCHAR;

Avantage:

Très flexible

Inconvénients:

Les scripts doivent s’executer dans le bon ordre
Error-prone
Version/state à sauvegarder pour chaque DB

Déclarative:

Mise à jour d’un fichier et un utilitaire s’occupe de faire la différence et mettre à jour la base de données.

CREATE TABLE Foo {
  Column1 INT,
  Column2 DATE,
  
  # added for v2
  Column3 VARCHAR
};

Avantages:

Une seule définition de l’objet
Pratique pour le développement
Moins complexe/ moins error prone

Inconvénients:

Les migrations de données sont sport
Il faut un outil de différenciation de schema

On va ici développer la partie déclarative qui est plus user friendly et a une approche plus proche de l’IaC.

Outils de migration déclarative pour snowflake

Il en existe aujourd’hui deux qui valent le coup d’être utilisés : Terraform et DBT.
Terraform, qu’il ne faut pas utiliser pour les tables, mais permet de déployer le reste sans problème (warehouse, procédures stockées). C’est un bon moyen de mettre en place l’environnement depuis zéro.

Le deuxième, DBT, est un outil de transformation de data (ETL) qui comprend une fonctionnalité intéressante de Materializations table qui permet à chaque run de rebuild votre model dbt en table dans snowflake.

Exemple d’un Models DBT avec une table matérialisé:

# models/store_sales.sql
{{ config(
    materialized="table",
    schema="sales"
) }}with source_store_sales as (
    select * from {{ source('sample_data', 'store_sales') }} limit 10
),final as (
    select * from source_store_sales
)select * from final

Proposition d’une structure IaC snowflake avec terraform et DBT

En utilisant les outils vus précédemment et en les mettant en commun, une pipeline de déploiement IaC pour une stack peut être créée selon le modèle suivant :

Il est possible d’obtenir une stack avec deux repos git qui permettent de créer l’infra snowflake d’un côté grâce à Terraform et de déployer les modèles de données dans DBT d’un autre côté qui permettra l’ingestion des données et des tables dans snowflake.

Petit bonus quelques photos des alentours avant d’aller au summit :