La tua dashboard è lenta, e il problema non è la dashboardLa tua dashboard è lenta, e il problema non è la dashboard

Qualcuno chiede perché la dashboard delle vendite impiega quattro minuti a caricarsi. Lo strumento di BI è la parte visibile, quindi è lo strumento di BI a prendersi la colpa. Si discute di una licenza più veloce. A volte la si compra perfino.

Serve di rado, perché quei quattro minuti non sono stati spesi a disegnare grafici. Sono stati spesi a fare lavoro che sarebbe dovuto avvenire ore prima, e che viene rifatto a ogni singolo aggiornamento.

Che cosa sta facendo, di solito, una dashboard lenta

Apri la query dietro un report lento e di solito troverai gli stessi schemi. Unisce cinque tabelle sorgente al momento della lettura. Converte colonne di testo in date perché nessuno ha sistemato i tipi a monte. Filtra su un'espressione calcolata, quindi nessun indice può aiutare. Deduplica le righe, il che significa che la sorgente ha duplicati mai risolti. E rifà tutto questo per ogni utente, ogni mattina, alla stessa ora.

Niente di tutto ciò è un problema di visualizzazione. È un problema di preparazione dei dati spinto sempre più a valle, finché è diventato visibile.

Sposta il lavoro, non ripeterlo

L'approccio a livelli che si chiama Bronze, Silver e Gold non ha niente di affascinante, ed è proprio qui che si guadagna il posto. Bronze è ciò che è arrivato, conservato così com'è arrivato. Silver sono quei dati puliti, tipizzati e deduplicati una volta sola. Gold è la forma di cui la domanda ha davvero bisogno: una tabella dei fatti con le sue dimensioni, già aggregata al livello di dettaglio che le persone chiedono.

Il punto non sono i nomi. Il punto è che ogni operazione costosa avviene una volta, secondo una pianificazione, invece che una volta per ogni utente a ogni aggiornamento. Un report che legge una tabella Gold non fa quasi nessun lavoro: filtra, aggrega, disegna.

Se un calcolo è uguale per tutti gli utenti, non dovrebbe essere eseguito una volta per utente.

La questione incrementale

La seconda cosa che rende lenti i report è rielaborare lo storico. Una pipeline che ogni notte ricostruisce tre anni di ordini per aggiungere quelli di ieri diventerà più lenta ogni notte, per sempre, per come è costruita.

Il caricamento incrementale risolve il problema, ed è soprattutto questione di saper rispondere a due domande: che cosa è nuovo dall'ultima volta, e che cosa significa eseguire tutto due volte. La prima richiede un watermark: una colonna updated-at affidabile, un change feed, una sequenza. La seconda richiede che il caricamento sia idempotente, un tema abbastanza ampio da meritare un articolo a sé.

Che cosa controllare davvero

• Quanto impiega da sola la query più lenta dietro il report, fuori dallo strumento di BI?
• Legge una tabella preparata, o unisce sorgenti grezze al momento della lettura?
• Il job notturno rielabora tutto, o solo ciò che è cambiato?
• I tipi vengono sistemati una volta a monte, o convertiti in ogni query che tocca la colonna?
• Quante persone avviano lo stesso aggiornamento costoso negli stessi dieci minuti?

Se le risposte indicano a monte, e di solito è così, nessuna impostazione della dashboard ti salverà. La buona notizia è che la correzione dura nel tempo. Il lavoro spostato in una pipeline resta spostato.