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

I problemi di prestazioni della dashboard raramente derivano da un'unica causa. Sono solitamente l'effetto combinato della progettazione della dashboard, della concorrenza e del caching del warehouse e del layout dei dati nel lakehouse. Se si ottimizza un solo livello (SQL, dimensionamento del compute o layout della tabella), spesso si otterranno solo miglioramenti parziali, ma la dashboard potrà comunque risultare lenta o imprevedibile durante l'uso effettivo.

In questo post, adottiamo un approccio olistico alle prestazioni di Databricks AI/BI. Seguiremo un'interazione con la dashboard end-to-end: dal browser e dal livello di orchestrazione AI/BI, passando per l'ammissione di Databricks SQL e il comportamento della cache, fino alla scansione dei file e al salto dei dati nel Lakehouse. Lungo il percorso, evidenzieremo i pattern che più spesso causano picchi di latenza, accodamento e costi su larga scala, specialmente quando molti utenti interagiscono contemporaneamente con le stesse dashboard.

L'anatomia del refresh di una dashboard di AI/BI

Per ottimizzare le prestazioni, è necessario innanzitutto comprendere il percorso che un singolo clic compie attraverso lo stack. Quando un utente apre una dashboard o modifica un filtro, si verifica una reazione a catena su più livelli. Se un livello è configurato in modo errato, l'utente percepisce il ritardo.

• Il browser (lato client): questa è la prima linea di difesa. Per i set di dati con meno di 100.000 righe e di dimensioni inferiori a 100 MB, il browser agisce come un motore locale, gestendo istantaneamente in memoria i filtri dei campi e le interazioni tra grafici. Se i dati superano questa soglia, ogni interazione deve tornare al warehouse.
• Progettazione della dashboard (l'orchestratore): il servizio di AI/BI determina quali query devono essere eseguite. Un design a "pagina singola" invia contemporaneamente la query di ogni widget, creando un enorme picco di concorrenza. Un design a "più pagine" richiede i dati solo per la tab visibile, modellando in modo efficace la domanda sulle compute.
• Databricks SQL (il motore): il tuo SQL Warehouse (idealmente Serverless) riceve la raffica. Controlla la cache, che ha più livelli, per vedere se il lavoro è già stato eseguito. In caso contrario, l'Intelligent Workload Management (IWM) ammette la query, scalando automaticamente i cluster in pochi secondi per gestire il carico senza accodamento.
• The Lakehouse (l'archiviazione): infine, il motore accede ai dati. Esegue la scansione dei file Delta in Cloud Object Storage. Qui, Liquid Clustering e i tipi di dati determinano l'efficienza di I/O. L'obiettivo è saltare quanti più dati possibile utilizzando statistiche e metadati a livello di file per restituire il set di risultati alla catena.

Ottimizzando ciascuna di queste quattro fasi, si abbandona il compute brute-force per passare a un'architettura ottimizzata che scala con gli utenti.

Prerequisito: comprendere i dati e la dashboard

Prima di ottimizzare qualsiasi cosa, devi prima definire per cosa stai ottimizzando. La performance della dashboard non è un concetto unico e i miglioramenti hanno senso solo se legati a un obiettivo chiaro. Gli obiettivi comuni includono la riduzione del tempo necessario alla prima visualizzazione, il miglioramento della latenza di interazione, il mantenimento di performance stabili in condizioni di concorrenza o la riduzione del costo per visualizzazione della dashboard.

Una volta che l'obiettivo è chiaro, è necessario comprendere i parametri che lo definiscono. Questi includono le dimensioni e la crescita dei dati, il numero di utenti e i loro modelli di accesso e il modo in cui le query si comportano nella pratica: quante ne vengono eseguite al caricamento della pagina, quanti dati analizzano e se i risultati vengono riutilizzati o ricalcolati costantemente. Senza questo contesto, l'ottimizzazione diventa un'ipotesi e spesso sposta i costi o la latenza da un livello all'altro.

L'ottimizzazione efficace della dashboard è, quindi, intenzionale: scegli un obiettivo misurabile, comprendi i dati e i modelli di utilizzo che lo influenzano e solo allora applica le ottimizzazioni tecniche che seguono.

Ottimizzazione n. 1: organizzare la dashboard in pagine (tab) 

Ogni riquadro visibile è un potenziale trigger: viene eseguito al primo caricamento e può essere rieseguito quando cambiano filtri/parametri, al refresh e quando gli utenti tornano a una pagina. Le tab limitano queste riesecuzioni alla pagina attiva, riducendo le raffiche e il blocco head-of-line.

Le dashboard AI/BI consentono di creare report multi‑pagina. Raggruppa le visualizzazioni in pagine allineate all'intento dell'utente (Panoramica → Analisi → Approfondimento), in modo che venga eseguita solo la pagina corrente. Ciò riduce il blocco head-of-line, modella la concorrenza in burst più piccoli e aumenta i tassi di hit della cache per le query deterministiche ripetute.

Tipi di pagina consigliati:

• Panoramica: contatori veloci e linee di tendenza per il primo rendering, evitare join/window pesanti nella landing page.
• Indagine: esplorazione incentrata sull'entità (cliente/prodotto/regione) con filtri che eseguono il push dei predicati in SQL (parametri) quando è necessaria una riduzione della pre-aggregazione.
• Approfondimento: aggregazioni dispendiose basate su refresh pianificati o viste materializzate/metriche (è possibile esportare un set di dati della dashboard in una vista materializzata).

Preferisci i riquadri deterministici (evita NOW()) per massimizzare gli hit della cache dei risultati, monitora le query di picco in coda e aumenta le dimensioni del cluster o il numero massimo di cluster se il valore è costantemente > 0. 

La funzionalità di drill-through nelle dashboard AI/BI consente la navigazione da visualizzazioni di alto livello a pagine dettagliate, mantenendo il contesto selezionato. È una strategia utile per applicare un design basato su pagine, posticipando le query onerose finché l'intento dell'utente non è chiaro, migliorando le prestazioni di first-paint e riducendo i picchi di concorrenza non necessari.

Callout — Perché questo aiuta su qualsiasi tipo di warehouse: raffiche più piccole e prevedibili fanno sì che l'IWM Serverless reagisca rapidamente ed eviti l'over-scaling, e impediscono a Pro/Classic di saturare gli slot del cluster durante il caricamento delle pagine. 

Per maggiori dettagli, consultare: https://www.databricks.com/blog/whats-new-in-aibi-dashboards-fall24 

Ottimizzazione n. 2: ottimizza il "First Paint" con valori predefiniti intelligenti

La prima impressione di una dashboard è definita dal suo primo rendering, ovvero il tempo che intercorre tra l'apertura della dashboard e la visualizzazione di risultati significativi. I valori di filtro Default svolgono un ruolo fondamentale perché determinano quali query vengono eseguite immediatamente al caricamento della pagina e la quantità di dati che tali query devono elaborare.

Quando i filtri non hanno default, le dashboard di AI/BI spesso caricano l'intero set di dati alla prima apertura. Ciò massimizza il volume di scansione, aumenta il fan-out delle query tra i riquadri e ritarda il momento in cui gli utenti visualizzano informazioni dettagliate utili. Il risultato è una prima esperienza lenta e imprevedibile, particolarmente problematica durante i picchi di concorrenza quando molti utenti aprono la stessa dashboard.

I valori predefiniti intelligenti risolvono questo problema limitando la forma della query iniziale. Esempi comuni includono:

• Impostare come predefiniti i filtri data su un intervallo di tempo recente (ad esempio, gli ultimi 7 o 30 giorni).
• Preselezionare una regione, una business unit o un'entità di primo livello comuni.
• Scegliere un'opzione "Tutto" sensata che sia comunque selettiva (ad esempio, l'anno fiscale corrente invece dell'intera cronologia).

Tecnicamente, i filtri default riducono la quantità di dati analizzati, migliorano i tassi di hit della cache e consentono il riutilizzo dei risultati tra gli utenti che aprono la dashboard con lo stesso stato iniziale. Questo migliora direttamente il time-to-first-visual e rende le prestazioni molto più costanti.

Il principio di progettazione fondamentale è semplice: ottimizzare per l'esperienza di landing. Rendi la prima visualizzazione rapida e informativa, quindi lascia che gli utenti ne amplino l'ambito intenzionalmente mentre esplorano. Un first paint veloce crea fiducia, incoraggia l'adozione e imposta la baseline delle prestazioni per ogni interazione successiva.

Per maggiori dettagli, vedere: https://docs.databricks.com/aws/en/dashboards/filters#-set-default-filter-values

Ottimizzazione n. 3: utilizzare i parametri per suddividere set di dati di grandi dimensioni

I parametri sono uno dei modi più efficaci per scalare le dashboard di AI/BI perché modellano la query prima che venga eseguita. Iniettando i valori direttamente nell'SQL, si applicano i predicati in una fase iniziale, in modo che Databricks possa eseguire il pruning dei dati più rapidamente e svolgere molto meno lavoro per ogni query (idealmente, filtrando prima dei join e delle aggregazioni).

I filtri di campo si comportano in modo diverso. Se il set di dati sottostante è abbastanza piccolo da essere memorizzato nella cache del browser (≤ 100.000 righe e ≤ 100 MB), i filtri di campo e le interazioni tra filtri possono essere valutati lato client senza un round-trip al warehouse. Una volta che i set di dati superano tale threshold, i filtri di campo vengono in genere inviati al warehouse tramite il wrapping della query del set di dati (spesso tramite una CTE), il che attiva l'esecuzione SQL del back-end e potrebbe non ridurre il costo di scansione con la stessa efficacia dei predicati parametrizzati applicati prima dei join e dell'aggregazione.

I parametri sono particolarmente efficaci per lo slicing per intervalli di date, aree geografiche, unità aziendali o altre dimensioni che riducono in modo significativo il volume dei dati. Rendono anche le prestazioni più prevedibili: ogni riquadro esegue query meno costose e i picchi di concorrenza diventano più facili da assorbire per il warehouse.

C'è un compromesso. Poiché valori di parametri diversi producono firme di query diverse, il riutilizzo della cache può essere inferiore quando gli utenti scelgono costantemente valori univoci. In pratica, questo è solitamente il giusto compromesso: una query piccola ed economica senza un hit della cache è di gran lunga migliore di una query grande e costosa che dipende dal caching per funzionare. È possibile bilanciare ulteriormente questo aspetto utilizzando default sensati e un set limitato di valori di parametri comuni, in modo che i percorsi più popolari possano ancora beneficiare della cache dei risultati.

Una regola pratica è: mantenere i set di dati abbastanza piccoli da rientrare nella cache del browser e utilizzare i filtri di campo per l'interattività (caso ottimale: nessun round trip al data warehouse). Se non si ha la certezza che il set di dati rimanga in modo affidabile entro i limiti della cache del browser, utilizzare i parametri per ridurlo in anticipo, in modo che il data warehouse legga meno dati all'inizio, e quindi applicare i filtri per un'esplorazione più approfondita. Questo trasforma le dashboard di tipo “scansiona tutto e filtra in seguito” in query selettive e scalabili che rimangono veloci man mano che i dati e gli utenti aumentano.

Per maggiori dettagli, vedi:

• https://medium.com/@andrea0pica/databricks-ai-bi-caching-explained-0c4de1aa946b

Ottimizzazione n. 4: Utilizzare la cache del browser

Il caching del browser è più utile quando le interazioni si basano su filtri di campo su set di dati di piccole dimensioni. Una volta che i parametri modificano l'SQL o i set di dati superano la soglia del browser, le interazioni tornano all'esecuzione nel warehouse.

Le dashboard di Databricks AI/BI possono memorizzare nella cache i risultati dei set di dati direttamente nel browser dell'utente, consentendo a molte interazioni di essere gestite interamente lato client senza round trip al SQL warehouse.

Quando un set di dati è inferiore a circa 100.000 righe, il browser diventa un motore di esecuzione locale. Il filtro incrociato, l'ordinamento e le aggregazioni semplici possono essere risolti istantaneamente in memoria, producendo interazioni con latenza quasi nulla ed eliminando del tutto la pressione della concorrenza del back-end. Ecco perché le pagine di panoramica ben progettate spesso sembrano "istantanee", anche in condizioni di utilizzo intenso.

La cache del browser viene utilizzata automaticamente quando:

• Il set di dati è abbastanza piccolo da poter essere caricato in sicurezza nel browser.
• Le interazioni si basano su filtri di campo o selezioni tra grafici che possono essere valutate lato client.
• Nessuna modifica dei parametri forza una nuova esecuzione SQL sul warehouse.

Una volta che i set di dati superano questa soglia, o quando i parametri modificano l'SQL sottostante, l'interazione viene rinviata al warehouse e la memorizzazione nella cache del browser non è più applicabile.

Il punto chiave della progettazione è il dimensionamento intenzionale del set di dati. Mantenere i set di dati della pagina di destinazione e di riepilogo compatti, pre-aggregati e focalizzati su KPI comuni in modo che siano idonei per la cache del browser. Ciò offre un "first paint" istantaneo, riduce il fan-out delle query e preserva la capacità del warehouse per le pagine di analisi più approfondite in cui l'esecuzione del backend è inevitabile.

Per maggiori dettagli, vedere: https://docs.databricks.com/aws/en/dashboards/caching#dataset-optimizations

Ottimizzazione n. 5: massimizza l'utilizzo della cache dei risultati

La query più economica e veloce è quella che non viene eseguita. 

Il caching dei risultati di Databricks SQL trasforma le interazioni ripetute sulla dashboard in risposte quasi istantanee, restituendo i risultati dalla cache invece di ricalcolarli.

Come funziona il caching dei risultati (cosa viene memorizzato nella cache, dove e per quanto tempo)

Databricks SQL controlla i risultati memorizzati nella cache prima di eseguire una query:

• Cache dei risultati locale (tutti i warehouse): cache per-cluster.
   
• Cache dei risultati remota (Serverless): a livello di workspace e persiste anche dopo i riavvii del warehouse.

Entrambe le cache hanno un TTL di circa 24 ore e vengono invalidate quando le tabelle sottostanti cambiano, in modo da mantenere i dati aggiornati e beneficiare al contempo del riutilizzo.

Progettare le dashboard in modo che i riscontri nella cache siano probabili

Gli hit della cache non sono automatici, sono il risultato di una progettazione. Si ottiene il massimo valore quando molti utenti pongono al warehouse la stessa domanda allo stesso modo.

1) Rendi deterministici i riquadri
Evita le funzioni non deterministiche (ad es. NOW() / current_timestamp()), perché modificano il risultato della query e ne impediscono il riutilizzo. Preferisci parametri di data/ora espliciti e mantieni stabile il testo della query in modo che le selezioni identiche possano essere servite dalla cache.

2) Riutilizzare i set di dati e mantenere coerente la "forma" della query
La cache e il riutilizzo migliorano notevolmente quando i riquadri condividono la stessa logica del set di dati e una forma coerente di predicato / GROUP BY. Quando più elementi visivi possono essere soddisfatti dalla stessa query di backend (o dallo stesso set di dati canonico), si riduce il numero di istruzioni inviate e si aumentano i tassi di riscontro nella cache.

3) Presta attenzione all'identità e alla rappresentazione
Il riutilizzo della cache dei risultati è più efficace quando la stessa query viene eseguita nello stesso contesto di accesso. Se la tua configurazione utilizza la rappresentazione per visualizzatore, potresti ridurre il riutilizzo della cache perché i risultati non possono sempre essere condivisi in modo sicuro tra le identità.
Best practice: laddove sia accettabile dal punto di vista della sicurezza e della governance, preferire un'identità di esecuzione condivisa per le dashboard pubblicate (ad esempio, un'entità servizio / un contesto di accesso condiviso) in modo che le visualizzazioni ripetute possano beneficiare del riutilizzo della cache. Se è necessario utilizzare la rappresentazione per utente, compensare massimizzando il riutilizzo del set di dati e concentrandosi su percorsi comuni deterministici e parametrizzati.

Preferire Serverless per le interazioni ripetute

Serverless aggiunge la cache dei risultati remota, che è condivisa a livello di workspace, resiste ai riavvii ed è utilizzata anche dai client ODBC/JDBC e dall'API SQL Statement. Per le dashboard con aperture ripetute e percorsi di filtro comuni, questo spesso produce il maggior guadagno di prestazioni 'gratuito'.

Riscaldare le cache in modo proattivo

Per le dashboard pubblicate, aggiungere una pianificazione. Le esecuzioni pianificate eseguono la logica del set di dati prima delle ore di punta e popolano le cache, migliorando il first paint e attenuando i burst di inizio ora.

Verificare gli hit (ed evitare benchmark fuorvianti)

Usa:

• Cronologia query: from_result_cache e cache_origin_statement_id
• EXPLAIN EXTENDED per comprendere l'idoneità della cache

Note:

• La cache locale non inserirà risultati più grandi di ~500 MiB (la cache remota non ha restrizioni di dimensione).
• La cache remota richiede client con supporto per Cloud Fetch (i driver meno recenti potrebbero non disporne).

Per il benchmarking, disabilita la memorizzazione nella cache solo durante i test controllati:
SET use_cached_result = false
… e riabilitala per l'utilizzo reale, in modo che le dashboard beneficino della memorizzazione nella cache in produzione.

Igiene operativa: evitare l'inquinamento della cache

Non mischiare carichi di lavoro non correlati sullo stesso warehouse di BI. I warehouse di BI Serverless dedicati per dominio/carico di lavoro aiutano la cache remota a riempirsi con le query ripetute importanti per quelle dashboard.

Per maggiori dettagli, vedi: https://www.databricks.com/blog/understanding-caching-databricks-sql-ui-result-and-disk-caches 

Prossimamente: Parte 2

Questa parte si è concentrata su come la progettazione della dashboard e i modelli di interazione influenzano le prestazioni, prima ancora che vengano coinvolti il warehouse e i dati. Riducendo il fan-out, ottimizzando il first paint e massimizzando il riutilizzo della cache, spesso è possibile ottenere notevoli vantaggi senza modificare i dati sottostanti. Nella seconda parte, completiamo il quadro approfondendo la piattaforma: come scegliere e dimensionare il SQL warehouse corretto, come la modellazione dei dati e il layout dei file influenzano l'efficienza della scansione e come pre-calcolo, materializzazione e tipi di dati mantengono le dashboard veloci e stabili con l'aumentare dell'utilizzo.

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