Snowflake DCM Projects: Infrastructure as Code, in puro SQL

TLDR

• I DCM Projects sono il modo nativo e dichiarativo di Snowflake per gestire gli oggetti come codice. Scrivi DEFINE <object> invece di CREATE <object> (ad esempio DEFINE DATABASE) e Snowflake capisce da solo cosa deve cambiare.
• Il ciclo è: modifichi le definizioni, plan, poi deploy. Il plan è un diff in sola lettura. Il deploy lo applica.
• DCM elimina ciò che smetti di definire. Cancelli una riga, perdi un database. Leggi il plan.
• Un manifest.yml più Jinja ti danno DEV, QA e PROD da un unico set di file.
• DCM può gestire tabelle e viste, ma secondo me non dovrebbe se usi già dbt. Lascia che DCM si occupi della piattaforma (ruoli, database, warehouse, grant) e che dbt si occupi di ciò che sta dentro i database.
• Il design di ruoli e database viene dalla guida di setup di Snowflake di dbt Labs, seguita da centinaia di progetti dbt. Il repo introduce qualche miglioramento e la trasforma in codice.
• Ecco il repo GitHub su cui si basa questo articolo, con CI/CD via GitHub Actions che non tocca mai ACCOUNTADMIN.

Come siamo arrivati fin qui

Se usi Snowflake da un po', probabilmente hai gestito l'infrastruttura del tuo account in uno di questi tre modi:

1. Click-ops. Qualcuno con ACCOUNTADMIN crea un oggetto in Snowsight un martedì qualsiasi. Nessuno ricorda perché. Tre anni dopo nessuno osa eliminarlo.
2. Script di migrazione: V1__create_roles.sql, V2__grant_things.sql, V47__fix_the_grant_from_V2.sql. Strumenti come schemachange li eseguono in ordine. Funziona, ma lo "stato attuale" del tuo account è la somma di 47 file, e buona fortuna a leggerla.
3. Terraform. Dichiarativo e potente. Ma porta con sé HCL, un provider da tenere aggiornato e uno state file da archiviare, bloccare e su cui, ogni tanto, fare interventi chirurgici. Per molti team dati è una disciplina tutta nuova solo per creare un warehouse.

I DCM Projects sono la risposta di Snowflake a tutto questo. Ottieni il modello dichiarativo di Terraform, ma il linguaggio è SQL e lo stato vive in Snowflake.

Il blueprint: le istruzioni di grant che tutti hanno copiato

Prima di entrare nel vivo di DCM, un doveroso riconoscimento. Se hai configurato Snowflake per dbt, è molto probabile che tu abbia letto Setting up Snowflake — the exact grant statements we run di Claire Carroll sul Discourse di dbt. Centinaia di progetti dbt sono stati configurati seguendo quello schema. Io stesso l'ho seguito più volte di quante riesca a contare.

Il design è semplice, ed è per questo che funziona:

• Un database raw per i dati in ingresso e un database analytics per i dati modellati.
• Un ruolo loader che scrive in raw, un ruolo transformer che legge raw e costruisce analytics, e un ruolo reporter che legge analytics e nient'altro.
• Future grants, così i nuovi schemi e le nuove tabelle sono leggibili senza che nessuno muova un dito.

Il problema non è mai stato il design. Il problema è che si tratta di una lista di istruzioni che incolli in un worksheet una sola volta. Sei mesi dopo nessuno sa dire se l'account le rispecchia ancora, e l'estensione per l'"ambiente dev" in fondo al post è lasciata come esercizio al lettore.

Il repo starter mantiene quindi l'impostazione di Claire e cambia alcune cose:

Perché gli inherited grants sostituiscono i future grants

La riga sui grant è il cambiamento più importante, quindi approfondiamo.

I future grants sono stati lo strumento giusto per molto tempo! Sono ciò che rende il setup di Claire a bassa manutenzione. Ma hanno tre problemi, e chiunque abbia gestito Snowflake per qualche anno ne ha incontrato almeno uno:

1. Coprono solo il futuro. Un future grant non fa nulla per le tabelle che esistono già, quindi ogni setup lo abbina a un'istruzione grant select on all tables. Sono due istruzioni per privilegio, e due cose da ricordare.
2. I future grants a livello di schema sovrascrivono quelli a livello di database. Se qualcuno aggiunge un future grant su uno schema, Snowflake ignora i future grants a livello di database per quello schema. Il tuo ruolo reporter smette silenziosamente di ricevere le nuove tabelle lì, e non viene segnalato alcun errore.
3. Sono una copia una tantum, non una regola. Un future grant viene applicato a ciascun oggetto al momento della creazione. Se poi revochi o modifichi il future grant, tutti gli oggetti già toccati mantengono il vecchio privilegio. Il grant che vedi non descrive più l'accesso che le persone hanno davvero.

Un inherited grant è un'unica istruzione su un contenitore (l'account, un database o uno schema) e si applica a ogni oggetto corrispondente al suo interno, esistente e futuro:

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

Questa riga sostituisce in blocco il future grant, il grant on all e la versione per singolo schema di entrambi. Quando vuoi sapere perché qualcuno può leggere una tabella, SHOW GRANTS ha le colonne IS_INHERITED e INHERITED_FROM che puntano al grant responsabile.

È anche una scelta naturale per DCM. Uno strumento dichiarativo vuole una sola riga che enuncia la regola. "Gli analisti possono leggere tutto in ANALYTICS" ora è una riga, non sei.

Alcuni compromessi da conoscere:

• Niente eccezioni. Non puoi revocare il privilegio su una singola tabella per escluderla. La documentazione di Snowflake avverte che la revoca sembra riuscire, mentre il ruolo mantiene l'accesso tramite l'inherited grant. Se una tabella richiede un accesso diverso, deve stare in uno schema o in un database diverso.
• Spostare o clonare un oggetto in un contenitore cambia chi può vederlo, senza alcuna istruzione GRANT da nessuna parte. È proprio questo il punto, ma presta attenzione ai cloni.
• OWNERSHIP non può essere ereditato. L'ownership resta un grant normale.
• Richiede un flag a livello di account, FEATURE_RBAC_INHERITED_GRANTS, che solo ACCOUNTADMIN può impostare. Ne parliamo nel bootstrap qui sotto.

Che cos'è un DCM Project in Snowflake?

Due cose:

1. Una cartella di file. Un manifest.yml e alcuni file .sql pieni di istruzioni DEFINE.
2. Un oggetto DCM project in Snowflake. Vive in uno schema come qualsiasi altro oggetto e conserva la cronologia dei deployment.

Ecco la struttura dal mio repo starter:

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

Un file per tipo di oggetto è una mia convenzione, non una regola di DCM. Snowflake legge tutto ciò che sta sotto sources/, quindi organizzalo come preferisci.

DEFINE, non CREATE

Il cambio di mentalità sta tutto qui. Con uno script di migrazione scrivi istruzioni:

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

Con DCM scrivi lo stato finale:

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

Se il ruolo non esiste, DCM lo crea. Se esiste con un commento diverso, DCM lo modifica. Se corrisponde già, DCM non fa nulla. Non scriverai mai più IF NOT EXISTS, e non scriverai mai un ALTER per correggere qualcosa che hai scritto la settimana scorsa.

I grant funzionano allo stesso modo. Un grant non lo DEFINE, lo dichiari e basta:

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;

Plan, poi deploy

Ogni modifica passa per due fasi. Con la Snowflake CLI:

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

Il plan confronta i tuoi file con ciò che c'è nell'account e ti dice esattamente cosa creerebbe, modificherebbe ed eliminerebbe. Non cambia nulla.

[screenshot: output del plan per l'aggiunta di un database]

Soddisfatto? Fai il deploy:

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

Quel --alias è facoltativo, ma usalo, per favore. Senza, la cronologia dei deployment è una lista di nomi generati automaticamente che nessuno riesce a leggere. Con l'alias, snow dcm list-deployments si legge come un changelog: add_marketing_db, analyst_read_on_analytics, drop_legacy_loader.

Puoi fare tutto questo anche in SQL (EXECUTE DCM PROJECT ... PLAN), e Snowsight Workspaces offre una UI dedicata. Io vivo nel terminale, quindi qui vedrai la CLI.

DCM elimina ciò che smetti di definire

Questa è la parte che può farti male.

Se rimuovi un DEFINE già deployato in precedenza, il deploy successivo elimina quell'oggetto.

È il comportamento corretto per uno strumento dichiarativo. I file sono l'account. Ma significa che due abitudini non sono negoziabili:

1. Esegui sempre il plan prima del deploy. Un DROP inaspettato nel plan significa che una definizione è sparita, non che DCM ti sta facendo un favore.
2. Leggi il plan nella tua PR. Più avanti spiego come lo automatizzo.

Un'altra cosa: la documentazione di Snowflake è esplicita sul fatto che un deploy fallito può lasciarti con un'esecuzione parziale. Non è un'unica grande transazione. Correggi la definizione ed esegui di nuovo plan → deploy, invece di sistemare le cose a mano.

DEV, QA e PROD da un unico set di file

Nessuno vuole tre copie di roles.sql. Il manifest.yml definisce i target, e ogni target punta al proprio oggetto project e passa le proprie variabili di 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:

Espandi codice

Poi ogni definizione usa {{ env }} come prefisso:

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;

Fai il deploy con --target DEV e ottieni DEV_RAW. Fai il deploy con --target PROD e ottieni PROD_RAW. Stessi file.

La parte complicata: gli oggetti a livello di account

Alcuni oggetti non appartengono a un ambiente. Nel mio template, tutti e tre gli ambienti condividono un solo account, un solo warehouse e un set di ruoli "master" come LOADER che ereditano DEV_LOADER, QA_LOADER e PROD_LOADER.

Se definissi COMPUTE_XS senza condizioni, tutti e tre i target lo rivendicherebbero, e i deploy dei vari target se lo contenderebbero. Quindi gli oggetti a livello di account vengono definiti in un solo target, con un if Jinja e un ciclo:

{% 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 %}

L'inghippo: quel blocco PROD concede grant a DEV_LOADER e QA_LOADER, quindi DEV e QA devono essere deployati prima di PROD. L'ordine di deploy diventa parte del tuo processo, e della tua CI.

Se metti ogni ambiente nel proprio account, il problema scompare, ma allora ogni account ha bisogno della propria copia degli oggetti a livello di account. A te la scelta del compromesso.

Ecco il modello di ruoli a cui arriva il template:

Inoltre, il ruolo Deployer riceve direttamente i ruoli specifici per ambiente:

Il tuo strumento di ingestion si connette come {env}_LOADER. dbt si connette come {env}_TRANSFORMER. Gli analisti ricevono {env}_ANALYST, che può leggere ANALYTICS e non vede affatto RAW.