Snowflake DCM Projects : l'infrastructure as code, en pur SQL

TL;DR

• Les DCM Projects sont la solution native et déclarative de Snowflake pour gérer vos objets sous forme de code. Vous écrivez DEFINE <object> au lieu de CREATE <object> (par exemple DEFINE DATABASE), et Snowflake détermine ce qui doit changer.
• Le cycle : modifier les définitions, planifier, puis déployer. Le plan est un diff en lecture seule. Le déploiement l'applique.
• DCM supprime ce que vous cessez de définir. Une ligne supprimée, une base de données en moins. Lisez le plan.
• Un manifest.yml et un peu de Jinja suffisent pour obtenir DEV, QA et PROD à partir d'un seul jeu de fichiers.
• DCM peut gérer les tables et les vues, mais à mon avis il ne devrait pas dès lors que vous utilisez déjà dbt. Laissez DCM gérer la plateforme (rôles, bases de données, warehouses, grants) et dbt gérer ce qui se trouve dans les bases.
• Le design des rôles et des bases de données reprend le guide de configuration Snowflake de dbt Labs, suivi par des centaines de projets dbt. Le repo y apporte quelques améliorations et le transforme en code.
• Voici le repo GitHub sur lequel s'appuie cet article, avec une CI/CD via GitHub Actions qui ne touche jamais à ACCOUNTADMIN.

Comment en est-on arrivé là

Si vous utilisez Snowflake depuis un moment, vous avez probablement géré l'infrastructure de votre compte de l'une de ces trois façons :

1. Le click-ops. Quelqu'un avec ACCOUNTADMIN crée un objet dans Snowsight un mardi. Personne ne se souvient pourquoi. Trois ans plus tard, personne n'ose le supprimer.
2. Les scripts de migration : V1__create_roles.sql, V2__grant_things.sql, V47__fix_the_grant_from_V2.sql. Des outils comme schemachange les exécutent dans l'ordre. Ça fonctionne, mais l'état actuel de votre compte est la somme de 47 fichiers, et bon courage pour lire ça.
3. Terraform. Déclaratif et puissant. Mais il apporte aussi HCL, un provider à maintenir à jour, et un fichier d'état à stocker, verrouiller et, de temps en temps, opérer à cœur ouvert. Pour beaucoup d'équipes data, c'est toute une discipline à apprendre juste pour créer un warehouse.

Les DCM Projects sont la réponse de Snowflake. Vous obtenez le modèle déclaratif de Terraform, mais le langage est le SQL, et l'état vit dans Snowflake.

Le modèle de départ : les grants que tout le monde a copiés

Avant d'entrer dans DCM, rendons à César ce qui est à César. Si vous avez configuré Snowflake pour dbt, il y a fort à parier que vous ayez lu l'article de Claire Carroll Setting up Snowflake — the exact grant statements we run sur le Discourse de dbt. Des centaines de projets dbt ont été mis en place en suivant ce schéma. Je l'ai moi-même suivi un nombre incalculable de fois.

Le design est simple, et c'est pour cela qu'il fonctionne :

• Une base raw pour les données entrantes, et une base analytics pour les données modélisées.
• Un rôle loader qui écrit dans raw, un rôle transformer qui lit raw et construit analytics, et un rôle reporter qui lit analytics et rien d'autre.
• Des future grants, pour que les nouveaux schémas et tables soient lisibles sans que personne ne lève le petit doigt.

Le problème n'a jamais été le design. Le problème, c'est qu'il s'agit d'une liste d'instructions que l'on colle une fois dans un worksheet. Six mois plus tard, personne ne peut dire si le compte y correspond encore, et l'extension environnement de dev en bas de l'article est laissée en exercice au lecteur.

Le repo de démarrage conserve donc la structure de Claire et change quelques éléments :

Pourquoi les inherited grants remplacent les future grants

Cette ligne sur les grants est le changement le plus important, alors creusons un peu.

Les future grants ont longtemps été le bon outil ! C'est ce qui rend le setup de Claire si peu coûteux à maintenir. Mais ils posent trois problèmes, et quiconque administre Snowflake depuis quelques années en a rencontré au moins un :

1. Ils ne couvrent que le futur. Un future grant ne fait rien pour les tables qui existent déjà, donc chaque setup l'associe à une instruction grant select on all tables. Cela fait deux instructions par privilège, et deux choses à retenir.
2. Les future grants au niveau schéma écrasent ceux au niveau base. Si quelqu'un ajoute un future grant sur un schéma, Snowflake ignore les future grants définis au niveau de la base pour ce schéma. Votre rôle reporter cesse discrètement de recevoir les nouvelles tables à cet endroit, sans la moindre erreur.
3. C'est une copie ponctuelle, pas une règle. Un future grant est appliqué à chaque objet au moment de sa création. Révoquez ou modifiez le future grant plus tard : tous les objets qu'il a déjà touchés conservent l'ancien privilège. Le grant que vous voyez ne décrit plus les accès dont les gens disposent réellement.

Un inherited grant, c'est une seule instruction sur un conteneur (le compte, une base de données ou un schéma), et elle s'applique à chaque objet correspondant qu'il contient, existant ou futur :

GRANT INHERITED SELECT ON ALL TABLES IN DATABASE {{ env }}_ANALYTICS
  TO ROLE {{ env }}_ANALYST;

Voilà le remplaçant, à lui seul, du future grant, du grant on all et de la version par schéma de chacun. Quand vous voulez savoir pourquoi quelqu'un peut lire une table, SHOW GRANTS dispose des colonnes IS_INHERITED et INHERITED_FROM, qui pointent vers le grant responsable.

C'est aussi un choix naturel pour DCM. Un outil déclaratif veut une ligne qui énonce la règle. Les analystes peuvent tout lire dans ANALYTICS tient désormais en une ligne, pas six.

Quelques compromis à connaître :

• Pas d'exceptions. Vous ne pouvez pas révoquer le privilège sur une table pour l'exclure. La documentation Snowflake prévient que la révocation semble réussir alors que le rôle conserve l'accès via l'inherited grant. Si une table nécessite des accès différents, sa place est dans un autre schéma ou une autre base.
• Déplacer ou cloner un objet dans un conteneur change qui peut le voir, sans la moindre instruction GRANT. C'est le but, mais soyez vigilant avec les clones.
• OWNERSHIP ne peut pas être hérité. La propriété reste un grant classique.
• Un paramètre de compte est requis, FEATURE_RBAC_INHERITED_GRANTS, que seul ACCOUNTADMIN peut activer. On y revient dans la partie bootstrap ci-dessous.

Qu'est-ce qu'un DCM Project dans Snowflake ?

Deux choses :

1. Un dossier de fichiers. Un manifest.yml et des fichiers .sql remplis d'instructions DEFINE.
2. Un objet DCM project dans Snowflake. Il vit dans un schéma comme n'importe quel autre objet et conserve l'historique des déploiements.

Voici l'arborescence de mon repo de démarrage :

platform/
  dcm/
    manifest.yml
    sources/definitions/
      roles.sql
      databases.sql
      warehouses.sql
      grants.sql
  migrations/
    000_bootstrap.sql
    001_ci_deployer.sql

Un fichier par type d'objet, c'est ma convention, pas une règle de DCM. Snowflake lit tout ce qui se trouve sous sources/, alors organisez le tout comme bon vous semble.

DEFINE, pas CREATE

Tout le changement de paradigme est là. Avec un script de migration, vous écrivez des instructions :

CREATE ROLE IF NOT EXISTS DEV_LOADER;
ALTER ROLE DEV_LOADER SET COMMENT = 'Owns DEV_RAW';

Avec DCM, vous écrivez l'état final :

DEFINE ROLE DEV_LOADER
  COMMENT = 'Owns DEV_RAW. Used by ingestion tools.';

Si le rôle n'existe pas, DCM le crée. S'il existe avec un commentaire différent, DCM le modifie. S'il correspond déjà, DCM ne fait rien. Vous n'écrirez plus jamais de IF NOT EXISTS, ni d'ALTER pour corriger ce que vous avez écrit la semaine dernière.

Les grants fonctionnent de la même manière. Vous ne faites pas de DEFINE sur un grant, vous l'énoncez, tout simplement :

DEFINE DATABASE DEV_RAW
  COMMENT = 'Landing zone. Schemas and tables are created by ingestion tools.';

GRANT OWNERSHIP ON DATABASE DEV_RAW TO ROLE DEV_LOADER;

Planifier, puis déployer

Chaque changement passe par deux étapes. Avec la CLI Snowflake :

snow dcm plan --from platform/dcm --target DEV \
  --connection my_account --role PLATFORM_DEPLOYER

Le plan compare vos fichiers à ce qui se trouve dans le compte et vous indique précisément ce qu'il créerait, modifierait et supprimerait. Il ne change rien.

[capture d'écran : sortie du plan pour l'ajout d'une base de données]

Satisfait du résultat ? Déployez :

snow dcm deploy --from platform/dcm --target DEV --alias add_marketing_db \
  --connection my_account --role PLATFORM_DEPLOYER

Le --alias est optionnel, mais utilisez-le, vraiment. Sans alias, votre historique de déploiements est une liste de noms auto-générés que personne ne peut lire. Avec, snow dcm list-deployments se lit comme un changelog : add_marketing_db, analyst_read_on_analytics, drop_legacy_loader.

Tout cela est aussi faisable en SQL (EXECUTE DCM PROJECT ... PLAN), et les Workspaces de Snowsight proposent une interface dédiée. Je passe ma vie dans le terminal, donc c'est la CLI que vous verrez ici.

DCM supprime ce que vous cessez de définir

C'est la partie qui peut vous jouer des tours.

Si vous retirez un DEFINE déjà déployé, le prochain déploiement supprime l'objet concerné.

C'est le comportement attendu d'un outil déclaratif. Les fichiers sont le compte. Mais cela rend deux habitudes non négociables :

1. Toujours planifier avant de déployer. Un DROP inattendu dans le plan signifie qu'une définition a disparu, pas que DCM vous rend service.
2. Lire le plan dans votre PR. J'explique plus bas comment j'automatise cela.

Une dernière chose : la documentation Snowflake est claire sur le fait qu'un déploiement en échec peut vous laisser avec une exécution partielle. Ce n'est pas une seule grande transaction. Corrigez la définition et relancez plan → deploy, plutôt que de rafistoler à la main.

DEV, QA et PROD à partir d'un seul jeu de fichiers

Personne ne veut trois copies de roles.sql. Le manifest.yml définit des targets, et chaque target pointe vers son propre objet projet et transmet ses propres variables de templating :

manifest_version: 2
type: DCM_PROJECT
default_target: DEV

targets:
  DEV:
    account_identifier: ABCDEFG-XY12345
    project_name: PLATFORM.DCM.DEV_PLATFORM_DCM
    project_owner: PLATFORM_DEPLOYER
    templating_config: DEV
  # QA and PROD look the same

templating:
  configurations:
    DEV:

Afficher le code

Ensuite, chaque définition utilise {{ env }} comme préfixe :

DEFINE DATABASE {{ env }}_RAW
  COMMENT = 'Landing zone. Schemas and tables are created by ingestion tools.';

DEFINE DATABASE {{ env }}_ANALYTICS
  COMMENT = 'Modelled data. Schemas and tables are created by transformation tools.';

GRANT OWNERSHIP ON DATABASE {{ env }}_RAW TO ROLE {{ env }}_LOADER;
GRANT OWNERSHIP ON DATABASE {{ env }}_ANALYTICS TO ROLE {{ env }}_TRANSFORMER;

Déployez avec --target DEV et vous obtenez DEV_RAW. Déployez avec --target PROD et vous obtenez PROD_RAW. Les mêmes fichiers.

Le point délicat : les objets au niveau du compte

Certains objets n'appartiennent à aucun environnement. Dans mon template, les trois environnements partagent un seul compte, un seul warehouse et un ensemble de rôles maîtres comme LOADER, qui héritent de DEV_LOADER, QA_LOADER et PROD_LOADER.

Si je définissais COMPUTE_XS sans condition, les trois targets le revendiqueraient, et chaque déploiement se le disputerait. Les objets au niveau du compte sont donc définis dans exactement un target, avec un if Jinja et une boucle :

{% if env == 'PROD' %}
{% set envs = ['DEV', 'QA', 'PROD'] %}

DEFINE WAREHOUSE COMPUTE_XS
  WAREHOUSE_TYPE = 'ADAPTIVE'
  MAX_QUERY_PERFORMANCE_LEVEL = XSMALL
  QUERY_THROUGHPUT_MULTIPLIER = 2
  COMMENT = 'Sole compute warehouse for loads and transforms.';

{% for e in envs %}
GRANT USAGE ON WAREHOUSE COMPUTE_XS TO ROLE {{ e }}_LOADER;
GRANT USAGE ON WAREHOUSE COMPUTE_XS TO ROLE {{ e }}_TRANSFORMER;
GRANT USAGE ON WAREHOUSE COMPUTE_XS TO ROLE {{ e }}_ANALYST;
{% endfor %}
{% endif %}

Le piège : ce bloc PROD accorde des privilèges à DEV_LOADER et QA_LOADER, donc DEV et QA doivent être déployés avant PROD. L'ordre de déploiement devient une partie de votre process, et de votre CI.

Si vous placez chaque environnement dans son propre compte, le problème disparaît, mais chaque compte a alors besoin de sa propre copie des objets au niveau du compte. À vous de choisir votre compromis.

Voici le modèle de rôles auquel aboutit le template :

Et le rôle Deployer reçoit directement les rôles propres à chaque environnement :

Votre outil d'ingestion se connecte en tant que {env}_LOADER. dbt se connecte en tant que {env}_TRANSFORMER. Les analystes reçoivent {env}_ANALYST, qui peut lire ANALYTICS et ne voit pas du tout RAW.