Attribuzione granulare dell'utilizzo per pipeline dbt con tag di query

Il progetto dbt esegue 80 modelli ogni notte. Il conto del magazzino è raddoppiato nell'ultimo trimestre. Le prestazioni dei modelli variano notevolmente e gli effetti delle ottimizzazioni più recenti non sono chiari. Il dipartimento finanziario chiede quale squadra è responsabile. Aprite la cronologia delle query e vedete... 80 righe identiche etichettate "Databricks Dbt". Buona fortuna.

Con Query Tags (ora in anteprima pubblica), i team che si occupano di dati possono ora beneficiare di tag auto-inseriti pronti per l'uso, come dbt_model_name, che arricchiscono ogni esecuzione. È inoltre possibile associare tag personalizzati (team, centro di costo, ambiente, ecc.) a ogni query generata dalla pipeline.

I tag vengono registrati in system.query.history, rendendo l'attribuzione dei costi, il debug delle prestazioni e il monitoraggio del carico di lavoro una semplice query SQL (per maggiori dettagli, consultare la documentazione).

Questo blog illustra un progetto dbt completo e open source che illustra i tag di query end-to-end: dalla configurazione ai dashboard di attribuzione dei costi. Tutto ciò che è descritto qui è disponibile come un repository GitHub che puoi clonare e distribuire nel tuo spazio di lavoro o semplicemente chiedere a Genie.

Modalità dbt-databricks di integrazione con i tag di query

L'dbt-databricksadattatore (versione 1.11+) supporta i tag di query in modo nativo. Esistono tre livelli a cui è possibile applicare i tag, ciascuno dei quali si basa sul precedente:

Tag iniettati automaticamente

Oltre ai tag personalizzati, dbt-databricks inserisce automaticamente i metadati relativi a ciascuna esecuzione del modello:

Questi tag automatici consentono di ottenere visibilità per modello senza configurazione: l'adattatore lo fa al posto vostro.

Tag a livello di profilo

L'approccio più semplice: aggiungi un campo query_tags a una destinazione specifica nel tuo profilo dbt. Ogni query del progetto eredita automaticamente questi tag.

Ad esempio, questa singola riga contrassegna ogni query con quattro dimensioni: chi ne è il proprietario (team), dove vanno i costi (cost_center), a quale pipeline appartiene (project_name) e in quale ambiente viene eseguita (env).

Tag a livello di modello

Per un'attribuzione più granulare, è possibile fornire tag su modelli specifici in dbt_project.yml o sulla configurazione del modello nella relativa definizione sql. 

I tag a livello modello si uniscono ai tag a livello profilo. Se entrambi definiscono la stessa chiave, il valore a livello di modello ha la precedenza.

Dove vengono visualizzati i tag: system.query.history

Dopo aver eseguito dbt run, ogni istruzione SQL viene visualizzata in system.query.history con la colonna query_tags popolata come MAP<STRING, STRING>. È possibile eseguire query utilizzando la sintassi standard di accesso alla mappa:

Questa funzione restituisce tutte le query contrassegnate degli ultimi 7 giorni, con i tag personalizzati e quelli auto-inseriti estratti in singole colonne, pronti per l'aggregazione.

È inoltre possibile trovare i tag di query per la query eseguita nell'interfaccia utente Cronologia query o nell'interfaccia utente di monitoraggio SQL Warehouse.

Nella parte inferiore destra del Profilo di query sono visualizzati i tag di query definiti, che forniscono tutte le informazioni necessarie a colpo d'occhio.

Attribuzione dei costi con tag di query

I tag di query consentono di determinare l'attribuzione granulare dell'utilizzo direttamente tramite query SQL, eliminando la necessità di analisi manuale dei log o di suddivisione delle risorse di magazzino.

Quali modelli dbt consumano più risorse di magazzino?

È possibile rispondere a questa domanda in due modi: chiedere a Genie in linguaggio semplice di eseguire un'esplorazione ad hoc oppure scrivere personalmente il codice SQL per ottenere un risultato ripetibile e pronto per la dashboard. Entrambi leggono dagli stessi dati system.query.history.

Opzione 1: Genio

Genie scrive ed esegue la query equivalente e voi continuate a fare approfondimenti sulle domande successive senza toccare alcun codice SQL.

Opzione 2: SQL

Entrambi i percorsi restituiscono la stessa immagine. Nel nostro progetto di riferimento, le quattro tabelle mart (materializzate come tabella) dominano il tempo di calcolo, mentre le visualizzazioni di staging e le visualizzazioni metriche sono quasi istantanee. Questo ti dice immediatamente dove concentrare gli sforzi di ottimizzazione.

Creazione di una dashboard di automonitoraggio

Il nostro progetto di riferimento include una dashboard AI/BI che interroga system.query.history filtrata in base ai tag di query del progetto. Il risultato: la pipeline che analizza i dati di fatturazione tiene traccia anche dei propri costi, alimentando i tag di query stessa.

La dashboard comprende:

• Indicatori chiave di performance: totale delle query taggate, totale dei secondi di calcolo, modelli DBT distinti
• Attività giornaliera: numero di query e tempo di elaborazione al giorno, suddiviso per ambiente
• Suddivisione del modello: tempo di calcolo per modello, colorato per tipo di materializzazione
• Suddivisione di materializzazione: grafico a torta che mostra come il calcolo viene distribuito tra tabella, vista e vista_metrica
• Tabella dei dettagli della query: ogni query contrassegnata con modello, durata, ambiente ed esecutore

Nel nostro progetto di riferimento, i quattro modelli mart hanno rappresentato il 92% del tempo di calcolo: senza i tag di query, questa informazione era invisibile.

Creare questa dashboard autonomamente richiede pochi minuti con Genie Code: richiedi il tempo di calcolo per modello dbt da system.query.history filtrato in base ai tag di query, e Genie Code scrive il codice SQL e assembla le immagini. Se preferisci passare direttamente al risultato finale, la dashboard viene fornita anche nel progetto di riferimento e viene distribuita con un installazione di pacchetto databricks insieme al processo dbt (vedi il repository Github per una guida dettagliata).

Tagging delle visualizzazioni metriche

Le visualizzazioni metriche Databricks (disponibili con dbt-databricks 1.12 e successive) sono un nuovo tipo di materializzazione che definisce la semantica aziendale riutilizzabile sotto forma di dimensioni e misure direttamente nel catalogo Unity (vedi la documentazione completa). Possono contenere tag di query proprio come qualsiasi altro modello, utilizzando il parametro di configurazione query_tags:

Si noti la distinzione: i tag query_sono associati alle query SQL che creano o aggiornano la vista metrica (tracciati in system.query.history), mentre i tag databricks_tag sono tag di catalogo Unity sull'oggetto stesso (per la governance e la rilevazione). Il primo è per il monitoraggio a livello di query, mentre il secondo è a livello di oggetto del catalogo Unity per la rilevabilità generale dei dati. 

Procedure consigliate per taggare progetti dbt

In questo articolo, abbiamo trattato il processo olistico per creare una solida pratica FinOps in cui i tag di query sono fondamentali per l'attribuzione dei costi. Ecco cosa abbiamo imparato creando il progetto di riferimento e parlando con gli utenti esperti di dbt:

• Utilizzare una gerarchia di tag coerente. Definisci tag a livello di profilo per tutta l'organizzazione (team, centro costi, nome_progetto, env) e riserva tag a livello di modello per casi eccezionali. Ciò mantiene i tag prevedibili ed evita la dispersione della configurazione per modello.
• Taggare sempre l'ambiente. Utilizzare valori env diversi per lo sviluppo locale (local-dev) e i processi distribuiti (dev, staging, prod). Ciò consente di separare le query di sviluppo ad-hoc dalle esecuzioni di produzione pianificate nelle analisi. Nel nostro progetto di riferimento, il profilo locale imposta "env": "local-dev" mentre il profilo distribuito imposta "env": "dev".
• Utilizzare `nome_progetto` per distinguere le pipeline. Quando più progetti dbt condividono un magazzino, project_name consente di attribuire i costi per pipeline senza dividere i magazzini. In combinazione con l'auto-injected@@dbt_model_name, si ottiene una tracciabilità completa: progetto → modello → materializzazione.
• Non esagerare. I tag inseriti automaticamente riguardano già il nome del modello, il tipo di materializzazione e le versioni dell'adattatore. Raramente è necessario duplicare queste informazioni nei tag personalizzati. Concentra i tag personalizzati sul contesto aziendale che dbt non è in grado di dedurre: proprietà del team, centro di costo, identità del progetto.
• Tagga esplicitamente le visualizzazioni delle metriche. Poiché le visualizzazioni delle metriche sono una materializzazione più recente, è utile etichettarle con una chiave di funzionalità (ad esempio, "feature": "metric_view") in modo da poter filtrare facilmente le query di creazione di visualizzazioni metriche nell'analisi dei costi.

Provate voi stessi

Il progetto di riferimento completo è disponibile su GitHub: github.com/databricks-solutions/dbt-query-tags

Per iniziare:

1. Clona il repository
2. Creare un ambiente virtuale Python 3.12 e installare le dipendenze: pip install dbt-databricks>=1.12.0a1
3. Aggiorna profiles.yml con l'host dell'area di lavoro, il percorso HTTP di SQL Warehouse, il catalogo e i tag di query personalizzati
4. Esegui dbt deps && dbt run --profiles-dir . per eseguire la pipeline
5. Interroga system.query.history per vedere i tag in azione
6. Aggiornare dbt_profiles/profiles.yml e databricks.yml per indicare la configurazione corretta.
7. Distribuzione con databricks distribuzione in pacchetto per esecuzioni pianificate e la dashboard di analisi

Scambia i valori del tuo team e del tuo centro di costo. Il modello funziona per qualsiasi progetto dbt su Databricks.

Clona il repository oggi stesso! È sufficiente una riga nel profilo per sbloccare la visibilità dell'attribuzione di utilizzo a livello di modello in tutto il magazzino.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale