Nelle release notes di luglio 2026 su AWS, Databricks ha annunciato il cost attribution automatico per le materialized view e le streaming table in Databricks SQL. La feature cambia il modo in cui la piattaforma contabilizza i costi di refresh di questi oggetti, con implicazioni concrete per i team che gestiscono ambienti condivisi e devono fare charge-back per business unit.
Le materialized view e le streaming table sono due dei costrutti più usati in Databricks SQL per esporre dati aggiornati senza richiedere a ogni consumer di rieseguire query pesanti. Il trade-off è il costo di refresh: ogni volta che un oggetto viene ricalcolato o aggiornato, si consumano DBU. Fino a questa feature, l’attribuzione di quei costi non era diretta — rendeva difficile rispondere a domande semplici come “quanto ci costa mantenere aggiornata questa materialized view?” a livello di catalog o schema.
Perché conta per chi gestisce una piattaforma dati
Con il cost attribution automatico, Databricks SQL associa i costi di refresh direttamente all’oggetto — materialized view o streaming table — piuttosto che all’utente o al warehouse che ha eseguito il refresh. Questo rende il billing breakdown più granulare e direttamente leggibile per chi produce report di costo interni.
Il beneficio pratico è duplice. Da un lato, i team di platform engineering possono finalmente rispondere in modo preciso a “chi usa cosa e quanto spende” senza costruire pipeline di tagging custom. Dall’altro, i data owner possono vedere il costo effettivo dei propri oggetti e prendere decisioni informate sulla frequenza di refresh o sull’architettura: se una materialized view costa troppo da mantenere rispetto al valore che genera, è un segnale che vale la pena valutare alternative come una vista non materializzata o un refresh meno frequente.
Per chi usa streaming table con Delta Live Tables in modalità serverless, il vantaggio è altrettanto concreto: i costi dei micro-batch di refresh, prima difficili da tracciare per singolo oggetto, diventano visibili e attribuibili. Questo semplifica la revisione periodica delle pipeline e l’identificazione di oggetti che consumano sproporzionatamente rispetto alla loro utilità effettiva.
Dal punto di vista dello sviluppo, la feature è trasparente: nessuna modifica alla sintassi SQL, nessun cambiamento nel comportamento dei refresh. Chi scrive query o gestisce pipeline DLT non nota nulla di diverso; il cambiamento è tutto nella visibilità del billing.
In sintesi
- Databricks SQL attribuisce ora automaticamente i costi di refresh delle materialized view e streaming table all’oggetto proprietario, non all’esecutore del refresh.
- Il charge-back per team e business unit diventa più preciso senza richiedere tagging manuale o logiche custom di monitoraggio.
- Nessun impatto sulla scrittura SQL o sul comportamento delle pipeline: la feature è completamente trasparente per chi sviluppa.
Fonte: July 2026 | Databricks on AWS — https://docs.databricks.com/aws/en/release-notes/product/2026/july
Hai qualcosa da aggiungere? Unisciti alla discussione.