Le 10 migliori best practice per l'ottimizzazione delle prestazioni delle dashboard di AI/BI (Parte 2)

Questo post è la seconda parte di una serie in due parti sull'ottimizzazione delle prestazioni delle AI/BI dashboard di Databricks su larga scala. 

Nel post precedente, ci siamo concentrati su come layout, filtri, parametri e caching determinano la quantità di lavoro che il sistema esegue per ogni clic. Queste ottimizzazioni sono spesso sufficienti per rendere le dashboard veloci. 

In questo post, ci concentriamo sulle fondamenta della piattaforma che la mantengono veloce con l'aumentare dell'utilizzo. Esamineremo la selezione e il dimensionamento del warehouse, la modellazione dei dati e le scelte dello schema, il layout dei file e il clustering e quando affidarsi alla materializzazione invece che alla rielaborazione per ottenere prestazioni stabili e prevedibili.

Ottimizzazione n. 6: scegli la configurazione del warehouse adatta al progetto 

Abbina la forma della dashboard (pagine, mix di query, picchi di attività degli utenti) al tipo e alle dimensioni del DBSQL warehouse in modo che il sistema accetti il lavoro rapidamente senza accodamenti.

Poiché i widget visibili vengono inviati insieme, le dashboard generano naturalmente picchi di concorrenza di breve durata. Se il warehouse non è in grado di assorbire il picco, si verificherà l'accodamento (Peak Queued Queries > 0) e i tempi di caricamento dei riquadri saranno incoerenti, soprattutto nelle ore di punta.

Come funziona la concorrenza dei warehouse DBSQL

• Serverless + IWM: Serverless utilizza l'Intelligent Workload Management per prevedere i costi, ammettere e dare priorità alle query ed eseguire rapidamente la scalabilità automatica. La startup tipica è di 2-6 secondi, quindi i picchi rimangono a bassa latenza senza ottimizzazione manuale.
• Pro/Classic: Limite fisso di "10 query simultanee per cluster", la scalabilità automatica aggiunge cluster in base a thresholds a livello di minuto e lo startup richiede più minuti; pianifica la capacità in base alla concorrenza prevista ed evita picchi al caricamento della pagina.
• Monitora e dimensiona correttamente: controlla Peak Queued Queries e Query History; se i picchi persistono al di sopra di 0, aumenta le dimensioni del cluster (soprattutto se Query Profile mostra uno spill su disco) o aumenta il numero massimo di cluster. 

Perché Serverless prima di tutto

• Serverless consigliato per la BI interattiva: startup più rapido, concorrenza dinamica tramite IWM e I/O più efficiente.

Euristiche pratiche di dimensionamento

• Inizia con una dimensione maggiore (dimensione del cluster) e riducila dopo i test, lascia che la scalabilità automatica Serverless gestisca i picchi di concorrenza e aumenta il numero massimo di cluster solo se i picchi di coda persistono.
• Mantieni separati i carichi pesanti di ETL e BI: dedica warehouse Serverless per ogni carico di lavoro/dominio (per evitare l'inquinamento della cache e consentire a IWM di apprendere il modello del carico di lavoro).
• Dai priorità alle query piccole e frequenti: IWM Serverless protegge le interazioni brevi e si scala rapidamente durante i carichi misti; progetta le pagine in modo che la Panoramica esegua prima i riquadri più leggeri. 

Per maggiori dettagli, vedi: https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior 

Ottimizzazione n. 7: Applicare le best practice di modellazione dei dati

I modelli di dati ben progettati sono una caratteristica fondamentale per le prestazioni delle dashboard di AI/BI. Lo schema a stella rimane il modello di modellazione più efficace e prevedibile per le analitiche interattive perché si allinea direttamente con il modo in cui le query di BI vengono scritte e ottimizzate.

In uno schema a stella, una tabella dei fatti centrale contiene eventi misurabili (vendite, transazioni, clic) e si unisce alle tabelle delle dimensioni circostanti (data, cliente, prodotto, regione). Questa struttura minimizza la complessità dei join, riduce la duplicazione dei dati e consente aggregazioni efficienti con pattern di query semplici e stabili. Di conseguenza, le dashboard eseguono meno join, analizzano meno dati e beneficiano in modo più coerente della memorizzazione nella cache e dell'ottimizzazione delle query.

Un dettaglio fondamentale ma spesso trascurato è costituito dai tipi di dati delle chiavi di join. I join tra tabelle delle dimensioni e dei fatti devono utilizzare chiavi surrogate basate su interi, non stringhe. Le join di interi sono molto più veloci, richiedono meno memoria, migliorano l'efficienza della cache e consentono a Photon di eseguire le join utilizzando percorsi vettorializzati altamente ottimizzati. I join basati su stringhe aumentano il costo della CPU e possono diventare un collo di bottiglia nascosto con l'aumentare dei dati e della concorrenza.

In Databricks, questo pattern si adatta in modo naturale all'architettura Lakehouse. Il gold layer dovrebbe essere modellato come fatti e dimensioni archiviati come tabelle di Unity Catalog, fornendo una base semantica governata e riutilizzabile per le dashboard di AI/BI, le viste delle metriche e le viste materializzate.

La conclusione è semplice: modellare in base a come vengono effettivamente eseguite le query di BI. Uno schema a stella con chiavi di join intere nel gold layer offre un SQL più semplice, join più veloci e prestazioni più prevedibili su larga scala.

Ottimizzazione n. 8: tecniche di ottimizzazione Parquet

Progetta il layout dei tuoi dati in modo che le dashboard leggano molti meno dati per query, quindi lascia che il motore sfrutti le statistiche di Parquet e le letture selettive. 

Considera il layout dei file come una funzionalità per le prestazioni

Databricks SQL è più veloce quando può:

• elimina interi file utilizzando i metadati (statistiche min/max),
• leggere in modo efficiente blocchi di dati grandi e contigui,
• ed evitare di aprire migliaia di file di piccole dimensioni.

Quindi i due vantaggi principali sono: compattare i file in dimensioni ottimali e
raggruppare i dati in modo che i predicati escludano i file.

Maggiori dettagli sono disponibili qui: https://www.databricks.com/discover/pages/optimize-data-workloads-guide

Un classico anti-pattern: un filtro di dashboard come WHERE customer_id = ? Sembra selettivo, ma se i dati non sono raggruppati in cluster, il motore elabora comunque una porzione enorme di file perché le righe corrispondenti sono sparse ovunque.

Tecnica

• Utilizza Photon per beneficiare di Predictive IO integrato su Parquet: Photon applica la lettura selettiva assistita da IA e l'I/O parallelo per saltare i blocchi non corrispondenti ed elencare meno file, offrendo scansioni selettive veloci senza indicizzazione manuale.
• Abilita le ottimizzazioni predittive per le tabelle gestite: Databricks può pianificare ed eseguire automaticamente la manutenzione delle tabelle in base ai modelli di carico di lavoro osservati —OPTIMIZE (compattazione per mantenere le dimensioni dei file sane), ANALYZE (statistiche aggiornate), VACUUM (pulizia) e Liquid Clustering (layout adattivo)— liberandoti dalla sintonizzazione manuale e migliorando al contempo il rapporto prezzo/prestazioni in lettura su larga scala. In pratica, questo aiuta a mantenere sane le dimensioni dei file compattando proattivamente i file di piccole dimensioni (tramite OPTIMIZE), in modo che i metadati Parquet (footer + statistiche min/max) rimangano efficaci per il salto dei dati, le scansioni selettive e le scansioni/concorrenza BI.
• Trigger le stesse attività operative manualmente quando necessario: puoi comunque eseguirle in autonomia quando hai bisogno di un controllo più stretto o di un time-to-benefit più rapido (ad esempio, dopo grandi ingestioni/backfill, modifiche allo schema o prima di un picco di reporting noto) eseguendo comandi come OPTIMIZE e ANALYZE. L'importante è agire in modo intenzionale: allinea la cadenza della manutenzione alla frequenza con cui la tabella cambia e assicurati che il costo di compute sia giustificato dai vantaggi a valle in termini di concorrenza, latenza ed efficienza della scansione.
• Adotta Liquid Clustering invece del partizionamento pesante. Liquid clusterizza i dati in modo incrementale per ricerche puntuali e scansioni selettive e puoi modificare le colonne di clustering in qualsiasi momento (anche ad alta cardinalità) senza una riscrittura completa; il layout si adatta all'evolversi dell'utilizzo.
• Allinea il layout ai predicati della dashboard. Scegli colonne di clustering Liquid che rispecchino le dimensioni comuni di filtro/group-by (ad es. data, clienti, regione) in modo che Predictive IO possa saltare grandi porzioni di dati per le pagine "Investigate" e "Deep dive". 

Risultato: meno file coinvolti, più blocchi saltati e un wall-clock più breve per le stesse informazioni dettagliate, senza indici fragili o tuning manuale. 

Per maggiori dettagli, vedi: 

• https://www.databricks.com/blog/faster-lakeview-dashboards-materialized-views
• https://docs.databricks.com/aws/en/compute/photon
• https://docs.databricks.com/aws/en/delta/data-skipping
• https://docs.databricks.com/aws/en/delta/optimize 

Ottimizzazione n. 9: Utilizzo della materializzazione della vista delle metriche

In Ottimizzazione n. 7: Applicare le best practice di modellazione dei dati, ci siamo concentrati sull'importanza dello schema a stella con fatti, dimensioni e KPI chiaramente definiti. Le Metric Views sono una diretta continuazione di questi principi in Databricks AI/BI.

Le Viste metriche sono progettate sulla base della semantica della BI: sono costituite da misure e dimensioni, il che le rende un'astrazione naturale per la modellazione dei KPI. Consentono ai team di definire le metriche aziendali una sola volta e di riutilizzare gli stessi KPI in modo coerente su più dashboard, agenti e altri strumenti client. Ciò riduce la duplicazione, previene il drift dei KPI e mantiene la logica analitica allineata con l'aumento dell'adozione.

Con la Materializzazione per le viste delle metriche, Databricks precalcola e mantiene automaticamente gli aggregati usati di frequente. Questi aggregati vengono aggiornati in modo incrementale e, al momento della query, l'optimizer riscrive in modo trasparente le query della dashboard per utilizzare il risultato precalcolato più corrispondente. Di conseguenza, le query delle dashboard analizzano molti meno dati per interazione, senza che i team debbano gestire tabelle di aggregazione separate o pipeline personalizzate.

Se non vengono utilizzate le Viste metriche, lo stesso approccio può essere applicato con le Viste materializzate. Ad esempio, una versione aggregata di una grande tabella dei fatti può essere precalcolata e archiviata, consentendo alle dashboard di interrogare un set di dati molto più piccolo e ottimizzato. Ciò migliora notevolmente le prestazioni riducendo la quantità di dati analizzati ed evitando di ricalcolare ripetutamente aggregazioni dispendiose per ogni interazione dell'utente.

Tutte queste tecniche ottimizzano la stessa cosa: analizzare meno dati. Definendo i KPI una volta e precalcolando gli aggregati usati di frequente con Metric Views o Materialized Views, i dashboard evitano di aggregare ripetutamente tabelle di fatti di grandi dimensioni. Un numero inferiore di byte analizzati si traduce direttamente in query più veloci, una latenza più prevedibile e prestazioni migliori su larga scala.

Per maggiori dettagli, vedi: 

• https://docs.databricks.com/aws/en/metric-views/materialization

Ottimizzazione n. 10: ottimizzare i tipi di dati

I tipi di dati influenzano direttamente la quantità di dati che Databricks SQL deve leggere, spostare ed elaborare per ogni query della dashboard. Anche con SQL e caching perfetti, i tipi di dati inefficienti aumentano silenziosamente l'IO, la pressione sulla memoria e il costo della CPU, manifestandosi con riquadri più lenti e una concorrenza ridotta.

Dietro le quinte, Databricks SQL opera su file Parquet colonnari. Tipi di dati più piccoli e scelti con cura significano:

• Meno dati analizzati dallo spazio di archiviazione (colonne più strette),
• Migliore densità della cache (più valori si inseriscono nella memoria e nella cache dei risultati),
• Esecuzione vettorizzata più veloce in Photon (layout compatibili con SIMD),
• Salto dei dati più efficace, perché le statistiche min/max sono più precise.

I meccanismi più importanti sono:

• Utilizzare INT / BIGINT invece di STRING per gli identificatori ove possibile. Le stringhe sono costose da analizzare, confrontare e memorizzare nella cache; le chiavi numeriche sono ordini di grandezza più economiche.
• Preferisci i tipi DATE o TIMESTAMP alle date basate su stringhe. I tipi temporali nativi consentono il predicate pushdown, confronti efficienti e un pruning migliore.
• Utilizzare il tipo numerico più piccolo adatto (INT vs BIGINT, FLOAT vs DOUBLE) per ridurre la larghezza della colonna e l'impronta di memoria.
• Evitare l'uso eccessivo di DECIMAL con precisione eccessiva nelle tabelle rivolte alla BI, a meno che non sia necessario; i decimali ad alta precisione aumentano il costo della CPU durante l'aggregazione.
• Mantenere gli schemi puliti e stabili. I cast impliciti (ad esempio da STRING a INT al momento della query) disabilitano le ottimizzazioni e aggiungono compute non necessari a ogni esecuzione.

Nei carichi di lavoro di BI, queste scelte si sommano rapidamente: una pagina della dashboard può eseguire dozzine di query, ognuna delle quali esegue la scansione di milioni di righe. Colonne strette e ben tipizzate riducono i tempi di scansione, migliorano i tassi di riscontri nella cache e consentono a Photon di operare alla massima efficienza.

Regola generale: considerare la progettazione dello schema come una funzionalità per le prestazioni. Ottimizza i tipi di dati una volta nella Lakehouse e ogni dashboard, attuale e futura, ne beneficerà automaticamente.

Conclusione

Il tema comune a tutte e dieci le best practice è semplice: smetti di pagare il prezzo pieno di un'interazione con la dashboard ogni volta. Fai in modo che il sistema esegua meno lavoro per vista (meno fan-out, meno dati analizzati) e rendi il lavoro che esegue riutilizzabile (set di dati condivisi, query deterministiche, cache e aggregati precalcolati). Quando questi elementi sono allineati, le prestazioni diventano stabili in condizioni di concorrenza e i costi diventano prevedibili.

In pratica, dovresti essere in grado di rispondere "sì" a queste domande per le tue dashboard più utilizzate:

• Gli utenti ottengono una prima visualizzazione rapida (visualizzazione di destinazione leggera + impostazioni predefinite)?
• Un'interazione tipica trigger un numero ridotto di query economiche (i parametri filtrano in anticipo, non dopo la scansione)?
• Le visualizzazioni ripetute si stanno trasformando in hit della cache (tasselli deterministici, riutilizzo tra tasselli, warm-up pianificato)?
• Il warehouse è in grado di assorbire il carico di picco senza accodamento o spilling (il valore di Peak Queued Queries rimane vicino a zero, il Query Profile non esegue lo spill)?
• Il Lakehouse è ottimizzato per le letture (dimensioni sane dei file, Liquid Clustering, tipi di dati puliti e aggregati ad accesso frequente precalcolati)?

Scegli una dashboard con un'adozione reale, esegui una rapida valutazione di base (first paint, latenza di interazione, Peak Queued Queries, spill, tasso di riscontri nella cache), applica un paio delle modifiche a più alto impatto e misura di nuovo. Fallo con costanza e passerai da un AI/BI "a volte veloce" a un AI/BI affidabilmente veloce man mano che i dati e gli utenti crescono.

Riferimenti e approfondimenti

• SQL warehouse dimensionamento, scalabilità, accodamento e monitoraggio, IWM Serverless vs scalabilità automatica Pro/Classic. https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior
• Creare/configurare i warehouse, indicazioni sui cluster per concorrenza.
  https://docs.databricks.com/aws/en/compute/sql-warehouse/create
• Vantaggi del serverless e perché è consigliato.
  https://docs.databricks.com/aws/en/compute/sql-warehouse/
• Tipi di warehouse e funzionalità per le prestazioni (Photon, Predictive IO, IWM, avvio in 2–6s per Serverless).
  https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-types
• Caching dei risultati (per cluster e cache remota dei risultati serverless).
  https://docs.databricks.com/aws/en/lakehouse-architecture/performance-efficiency/best-practices https://learn.microsoft.com/it-it/azure/databricks/sql/user/queries/query-caching
• Dashboard AI/BI: pagine/canvas/modello di dati e componenti.
  https://docs.databricks.com/aws/en/dashboards
• Parametri e filtri di campo, parametri basati su query.
  https://docs.databricks.com/aws/en/dashboards/parameters
• Esporta un set di dati della dashboard in una vista materializzata per accelerare i carichi di lavoro pesanti.
  https://docs.databricks.com/aws/en/ai-bi/release-notes/2025
• Esecuzioni di query della dashboard nei logs di controllo (verificare cosa viene eseguito al caricamento).
  https://docs.databricks.com/aws/en/admin/account-settings/audit-logs

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