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

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 i tag di query (ora in anteprima pubblica), i team che si occupano di dati possono ora beneficiare di tag auto-inseriti pronti all'uso, come dbt_model_name, che arricchiscono ogni esecuzione. Puoi anche associare tag personalizzati (team, centro di costo, ambiente, qualsiasi cosa) 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 più semplice da eseguire con SQL query (per dettagli completi, 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.

Come si integra dbt-databricks con i tag di query

L'adattatore dbt-databricks (versione 1.11+) supporta i tag di query in modo nativo. Esistono tre livelli a cui è possibile applicare i tag, ciascuno basato sui precedenti:

Tag iniettati automaticamente

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

Questi tag automatici consentono di ottenere visibilità per modello senza configurazione: l'adattatore lo fa per voi.Tag a livello di

profilo

L'approccio più semplice: aggiungete un campo query_tags a una destinazione specifica nel 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 (centro_costo), a quale pipeline appartiene (nome_progetto) 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 sua 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 appaiono 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. È possibile eseguire query utilizzando la sintassi standard di accesso alla mappa:

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.

Sulla in basso a destra del Profilo query, sono visualizzati i tag query definiti, che forniscono tutte le informazioni necessarie a colpo d'occhio.

Attribuzione dei costi con tag query

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

Quali modelli dbt consumano la maggior parte delle risorse di magazzino?

È possibile rispondere a questa domanda in due modi: chiedere a Genie in linguaggio semplice 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: Genie

Genie scrive ed esegue la query equivalente e si continua 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.

Il dashboard include:

• Indicatori chiave di performance: totale query taggate, secondi di elaborazione totali, modelli di dbt distinti
• Attività giornaliera: numero di query e tempo di elaborazione al giorno, suddiviso per ambiente
• Ripartizione del modello: Tempo di calcolo per modello, colorato in base al tipo di materializzazione
• Suddivisione della materializzazione: grafico a torta che mostra come il calcolo è distribuito tra tabella, vista e tabella di dettaglio metric_view
• Query: Ogni query taggata con modello, durata, ambiente ed eseguitore

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

Creare questa dashboard richiede pochi minuti con Genie Code: richiedi il tempo di calcolo per modello dbt da system.query.history filtrato in base ai tag 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 viste metriche

Le viste 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:

Notare 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. 

Best practice per l'assegnazione di tag ai 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 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ò consente di mantenere i tag prevedibili ed evitare 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 il nome del modello @@dbt_inserito automaticamente, ottieni una tracciabilità completa: progetto → modello → materializzazione.
• Non esagerare con i tag. 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 su contesti aziendali che dbt non è in grado di dedurre: proprietà del team, centro di costo, identità del progetto.
• Tag esplicitamente le visualizzazioni delle metriche. Poiché le visualizzazioni 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.

Provalo tu stesso

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

Per iniziare:

1. Clona il repository
2. Crea un ambiente virtuale Python 3.12 e installa le dipendenze: pip installa 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 esegui --profiles-dir . per eseguire la pipeline
5. Query system.query.history per vedere i tag in azione
6. Aggiorna dbt_profiles/profiles.yml e databricks.yml per indicare la configurazione corretta.
7. Distribuisci con databricks bundle deploy 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