Tutorial: Come rilasciare in sicurezza le modifiche alle dashboard AI/BI su scala con i Declarative Automation Bundles

L'idea che una riunione del consiglio di amministrazione inizi con una dashboard piena di errori dovrebbe togliere il sonno ai team di analytics. Lo stesso vale per il fatto di scoprire, a cose fatte, che un piano di assunzioni, il lancio di un prodotto o una previsione dei ricavi si basavano su una metrica errata. O che un team di supporto ha emesso troppi rimborsi perché una dashboard riportava in modo errato la cronologia degli acquisti di un cliente.

Questi fallimenti sono raramente causati da un'analisi errata. Come per qualsiasi sistema di produzione, spesso derivano dal fatto che le dashboard vengono aggiornate manualmente man mano che i modelli di dati e i requisiti si evolvono, senza controllo delle versioni, senza un processo di revisione affidabile o senza un modo ripetibile per promuovere le modifiche tra i vari ambienti.

Questo post del blog sostiene una tesi semplice: le dashboard di livello di produzione che guidano il business devono essere gestite con la stessa disciplina del codice di produzione. Poiché Databricks AI/BI viene eseguito sulla stessa Data Intelligence Platform delle pipeline di dati e del livello di governance, i team possono applicare queste stesse pratiche di produzione (controllo delle versioni, configurazione specifica per l'ambiente e deployment controllato) anche alle dashboard.

Per rendere questo concetto concreto, presenteremo come gli analisti possono utilizzare le funzionalità di livello di produzione di Databricks senza modificare il modo in cui creano le dashboard giorno per giorno.

Nello specifico, mostreremo come questo flusso ti consente di:

• Revisionare e approvare ogni modifica a una dashboard
• Monitorare la cronologia di una dashboard e collegare le modifiche al codice ai requisiti aziendali
• Ripristinare una dashboard a una versione precedente

Prerequisiti

Questo flusso di lavoro richiede una configurazione iniziale dell'infrastruttura che la maggior parte delle organizzazioni ha già predisposto. Se non l'hai ancora fatto, chiedi al tuo gruppo DevOps o IT interno di aiutarti a configurare:

• Almeno due workspace Databricks (ad esempio, un workspace di sviluppo e uno di produzione) per creare, testare e distribuire dashboard
• Cartelle basate su Git in Databricks (AWS | Azure | GCP), utilizzate per gestire le versioni delle definizioni delle dashboard
• Declarative Automation Bundles (DAB) (AWS | Azure | GCP) configurati per il progetto

Introduzione: un flusso di lavoro strutturato per distribuire le modifiche alle dashboard in sicurezza

Esamineremo uno scenario realistico: possiedi una dashboard Sales Performance utilizzata settimanalmente dalla leadership di Finance e Sales. È nata come progetto di uno stagista creato direttamente in un workspace, ma si è evoluta nel tempo e ora viene utilizzata in diverse revisioni esecutive.

Un cambiamento di priorità derivante da una riunione del consiglio di amministrazione introduce un nuovo requisito: Finance ora deve monitorare gli importi delle vendite impegnati e non impegnati, sostituendo una singola metrica di vendita aggregata, e la dashboard deve riflettere la nuova definizione prima della prossima revisione delle previsioni.

Questi valori influiscono direttamente sulle decisioni aziendali reali, inclusi i calcoli di compensi e bonus, quindi prendiamo questa dashboard e inseriamola per la prima volta in un percorso di deployment disciplinato.

Passaggio 1: aggiungi la dashboard a un Declarative Automation Bundles

Prima di iniziare il processo, collabora con il tuo gruppo IT per configurare alcuni strumenti di codice di base: un repository Git con un "Declarative Automation Bundles" vuoto e alcuni script CI/CD per distribuire automaticamente il bundle.

Un repository Git è uno strumento per tracciare le modifiche ai file: per iniziare, dobbiamo collegarlo a Databricks in modo da poter tracciare le modifiche alla configurazione della dashboard. Dal workspace Databricks, crea una cartella Git e incolla l'URL del repository nella finestra di dialogo di configurazione. In questo modo Databricks riconoscerà il repository e potremo aggiungervi la dashboard nel passaggio successivo.

Un Declarative Automation Bundles è un modo per raggruppare file di codice (in questo caso, una dashboard). Se il repository contiene già un bundle, questo viene rilevato automaticamente e può essere aperto utilizzando l'icona a forma di freccia. In caso contrario, è possibile creare un nuovo bundle dal menu Crea nella cartella Git.

All'interno dell'editor di Asset Bundle, puoi aggiungere componenti sia nuovi che esistenti al bundle attualmente vuoto. Per includere la dashboard, apri il menu Aggiungi e seleziona Aggiungi dashboard esistente. Dopo averla aggiunta, vedrai apparire la dashboard all'interno della cartella src come parte del bundle.

Da questo momento in poi, la dashboard viene gestita come un asset distribuibile, semplificando la promozione della stessa dashboard nei workspace di sviluppo, test e produzione.

Infine, esegui il commit della dashboard nel repository. In questo modo si acquisisce lo stato corrente della dashboard come baseline e si stabilisce un punto di partenza chiaro per tracciare e revisionare le modifiche future.

Vedrai che la dashboard è stata aggiunta al repository, insieme ad alcuni file di configurazione generati automaticamente (che terminano con .yml). Questi file descrivono come deve essere distribuita la dashboard nei diversi ambienti; non è necessario modificarli.

Aggiungi una breve nota che descrive cosa hai fatto nel campo del messaggio di commit, quindi seleziona Commit & Push. Questo crea un checkpoint per la dashboard (uno stato sicuramente funzionante a cui poter tornare in seguito) in modo che le modifiche future possano essere confrontate, revisionate e distribuite in sicurezza.

Passaggio 2: aggiorna la dashboard

Ora che è stato eseguito il commit della dashboard esistente, puoi iniziare a modificarla senza influire su ciò che è già in produzione, e Git traccerà le modifiche specifiche che hai apportato.

La prassi comune consiste nel creare un branch Git, ovvero una versione della dashboard su cui lavorare senza influire sugli altri. Puoi farlo tramite il pulsante Create Branch, quindi assegnargli un nome descrittivo come il tuo nome, la funzionalità o un numero di ticket associato alla modifica. Pensa a questa come a una versione privata per il tuo aggiornamento: puoi modificare, testare e perfezionare liberamente la dashboard, per poi decidere separatamente quando le tue modifiche sono pronte per essere revisionate e distribuite.

Ora puoi apportare le modifiche alla dashboard! In questo caso, modificherai il numero delle vendite in alto a sinistra per aggiungere i contatori delle vendite non confermate e confermate (in blu e rosso grassetto per una maggiore visibilità).

Noterai che l'esperienza di creazione non cambia affatto: apporta queste modifiche come faresti normalmente utilizzando l'editor UI della dashboard.

Una volta che la dashboard appare corretta in fase di sviluppo, puoi procedere per portare le modifiche in produzione. Usa lo stesso pulsante Git in alto come prima per registrare queste modifiche con un breve messaggio di commit.

Step 3: Revisione della modifica

Successivamente, sbloccherai un altro vantaggio chiave di questo flusso di lavoro: uno spazio in cui altri possono esaminare le modifiche e offrire feedback prima che queste raggiungano la produzione. Richiedere la revisione di una seconda persona è una best practice generale, ma, cosa altrettanto importante, crea uno spazio sicuro per discutere idee, convalidare ipotesi e perfezionare la modifica prima che influisca sulla reportistica.

Per avviare la revisione, crea una Pull Request (PR) nel tuo provider Git, che è fondamentalmente una pagina di revisione per l'aggiornamento della dashboard. Chi esegue la revisione può vedere esattamente cosa è cambiato, lasciare commenti a cui rispondere e approvare l'aggiornamento una volta che tutto è a posto.

Durante la revisione, la dashboard di produzione rimane invariata. Solo dopo aver risposto al feedback e approvato la modifica, questa andrà avanti.

Sebbene le modifiche alla dashboard vengano memorizzate e tracciate come file di configurazione dietro le quinte, spesso è difficile capire cosa sia effettivamente cambiato. Per questo motivo, la maggior parte dei team utilizza una piccola automazione per distribuire automaticamente una versione di test temporanea della dashboard per la revisione ogni volta che viene aperta una PR. In questo modo, i revisori possono vedere le metriche, i calcoli e i layout proposti nel contesto prima che qualsiasi cosa raggiunga la produzione, individuando eventuali problemi di logica dei dati o dell'UI. Consentire allo sviluppatore o al revisore di includere screenshot o link alla dashboard di test direttamente nella PR rende il feedback più rapido e sicuro.

I revisori possono aggiungere commenti e approvare; queste azioni vengono registrate in modo che la modifica sia più facile da comprendere in seguito.

Step 4: Distribuzione della dashboard in produzione utilizzando il bundle

Una volta approvata la modifica, puoi distribuire la dashboard in produzione.

Le dashboard spesso richiedono impostazioni diverse in produzione rispetto allo sviluppo - ad esempio, puntando a un catalogo o schema di produzione anziché a un dataset di sviluppo, oppure utilizzando un SQL warehouse diverso.

La buona notizia è che queste differenze sono previste e gestite come parte del processo di distribuzione.

Quando hai aggiunto la dashboard all'Asset Bundle, Databricks ha generato un piccolo file di configurazione .yml che acquisisce queste impostazioni specifiche dell'ambiente. Questo file consente di sovrascrivere i valori in base all'ambiente senza modificare la logica della dashboard stessa. Nel nostro caso, abbiamo specificato che il catalogo utilizzato dalla dashboard in produzione deve essere diverso da quello di test, utilizzando un valore ${variable} per il nome del catalogo.

Infine, il file databricks.yml collega tra loro tutte le risorse del bundle e definisce quale catalogo viene utilizzato in ciascun ambiente, semplificando la gestione di distribuzioni coerenti tra i workspace di sviluppo, test e produzione.

Una volta che la Pull Request è stata approvata e unita nel branch principale, l'automazione della distribuzione viene eseguita e utilizza i valori specifici dell'ambiente definiti in databricks.yml. Lo stesso codice della dashboard viene riutilizzato in tutti i workspace, mentre impostazioni come catalogo, schema e warehouse vengono applicate in base all'ambiente di destinazione. Ciò elimina la necessità di mantenere copie separate della dashboard per ciascun workspace e garantisce che le modifiche si comportino in modo prevedibile ovunque.

Per la maggior parte dei provider Git, potrai vedere l'automazione della distribuzione direttamente sulla pull request, in modo da monitorare il deploy e confermare quando viene completato (o se riscontra un problema). Se si verifica un problema, la distribuzione si interrompe senza influire sulla dashboard di produzione esistente per consentirti di risolvere il problema. Una volta completata con successo la distribuzione, la dashboard aggiornata è attiva in produzione e pronta per gli stakeholder!

Bonus 1: E se volessi esaminare la cronologia?

Una volta che l'aggiornamento della dashboard è attivo, potresti aver bisogno di comprendere la cronologia di cosa è cambiato, quando e perché. Un vantaggio di questo flusso è che la modifica è ora tracciabile. Invece di una modifica occasionale apportata direttamente in un workspace, appare come una sequenza di versioni salvate.

Ogni voce rappresenta un aggiornamento della dashboard, insieme all'autore e al timestamp. Puoi aprire qualsiasi voce per esaminare le modifiche e ripristinare una versione precedente se necessario.

Bonus 2: E se avessi bisogno di annullare una modifica?

Anche con un'attenta revisione e test, possono comunque emergere problemi, come una dashboard che non si carica o la definizione di una metrica che si rivela errata.

Poiché la dashboard è gestita attraverso questo flusso di lavoro, puoi ripristinare una versione sicuramente funzionante utilizzando lo stesso processo controllato impiegato per distribuire l'aggiornamento.

Inizia aprendo la cronologia delle modifiche della dashboard nel repository e individuando l'aggiornamento che desideri annullare. Da lì, puoi esaminare cosa è stato modificato per confermare che stai ripristinando la modifica corretta prima di procedere.

Dai dettagli della modifica, segui il link per tornare alla pagina di revisione. Per annullare l'aggiornamento, seleziona Revert. Questo crea una nuova modifica di "annullamento" che inverte solo quello specifico aggiornamento, ripristinando la dashboard alla sua logica precedente e mantenendo intatto il resto della cronologia della dashboard.

Una volta unito il cambiamento nel branch main, la stessa automazione che ha distribuito la dashboard in produzione ne eseguirà il rollback. Ciò significa che potrai rispondere a un'interruzione o a un problema di calcolo ad alto impatto in pochi minuti, senza aggirare i controlli già predisposti.

Bonus 3: cosa succede se le tue origini dati vengono aggiornate?

La maggior parte delle dashboard è strettamente collegata alle proprie origini dati, il che significa che gli aggiornamenti di una dashboard sono spesso strettamente legati agli aggiornamenti delle pipeline. La buona notizia è che gli Asset Bundle sono progettati per raggruppare i componenti correlati in un unico pacchetto.

Questo garantisce che una modifica al modello dati upstream non ti colga mai di sorpresa e, quando le modifiche alla visualizzazione richiedono aggiornamenti del modello dati, puoi implementare entrambe le modifiche in un'unica distribuzione.

Conclusione

Considerare le dashboard AI/BI come prodotti dati di livello di produzione è essenziale per prendere decisioni aziendali affidabili e mitigare i rischi. In questo flusso di lavoro, una serie limitata di passaggi aggiuntivi rende le modifiche alle dashboard visibili, esaminabili e reversibili, senza cambiare il modo in cui crei le dashboard giorno per giorno.

Gestendo le dashboard con Git e i Declarative Automation Bundle, i team stabiliscono un flusso di lavoro di aggiornamento routinario e prevedibile: apporta la modifica, esaminala, testala e distribuiscila. Lo stesso processo si applica sia che l'aggiornamento sia una piccola regolazione visiva, sia che si tratti di una modifica significativa alla logica aziendale.

Con la giusta disciplina di distribuzione, le modifiche alle dashboard smettono di essere una fonte di rischio e diventano una fonte affidabile di insight che si evolve con il business, anche in situazioni ad alto rischio come una riunione del consiglio di amministrazione.

Scopri di più e passaggi successivi

Se hai trovato l'ispirazione e desideri approfondire gli elementi utilizzati in questo flusso di lavoro, ecco alcune risorse utili per iniziare:

• 'Strategia di branching' (AWS | Azure | GCP)
  Scopri come le modifiche vengono unite e distribuite utilizzando un modello di branching che segue le best practice.
• Declarative Automation Bundle (AWS | Azure | GCP)
  Scopri come vengono utilizzati gli Asset Bundle per pacchettizzare e distribuire le risorse Databricks in modo coerente tra i vari ambienti.
• CI/CD per la distribuzione automatizzata su Databricks (AWS | Azure | GCP)
  Scopri come implementare la CI/CD con gli script di GitHub Actions iniziali (AWS | Azure | GCP)
• Utilizzo degli Asset Bundle dall'interfaccia utente dell'area di lavoro di Databricks (AWS | Azure | GCP)
  Scopri come creare, modificare e distribuire i bundle direttamente dall'area di lavoro.
• Cartelle basate su Git in Databricks (AWS | Azure | GCP)
  Scopri come funziona l'integrazione di Git in Databricks e come il controllo della versione si inserisce nei flussi di lavoro di analisi quotidiani.

Se desideri fare il passo successivo con Databricks AI/BI, puoi scegliere una delle seguenti opzioni:

• Versione gratuita e di prova: fai un'esperienza pratica registrandoti per la nostra versione gratuita o di prova.
• Documentazione: approfondisci i dettagli con la nostra documentazione.
• Pagina web: visita la nostra pagina web per saperne di più.
• Demo: guarda i nostri video demo, fai i tour del prodotto e segui i tutorial pratici per vedere AI/BI in azione.
• Formazione: inizia con la formazione gratuita sul prodotto tramite Databricks Academy.

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