Una dashboard Qlik veloce indica quanto rapidamente riesce a rispondere a una domanda, non quanto recentemente abbia ricevuto i dati delle attività aziendali sottostanti. Un ordine può essere stato confermato con un commit nel sistema operativo mentre la dashboard mostra ancora lo stato precedente. Migliorare il tempo di risposta dei grafici, di per sé, non colma questa distanza.
Per definire un'aspettativa significativa sull'attualità dei dati, seguite l'evento fino alla vista dell'utente: commit alla fonte, acquisizione o estrazione, arrivo nella destinazione, trasformazione, disponibilità per l'analisi e visualizzazione. Nella diagnosi delle prestazioni delle dashboard, tenete separati la velocità di risposta e il ritardo massimo accettabile dei dati. Entrambi rientrano nella stessa decisione di accettazione, ma misurano aspetti diversi.
Partire dalla modalità di accesso di Qlik
Nella consueta modalità in-memory di Qlik Sense, il ricaricamento dell'applicazione recupera i dati e aggiorna l'istantanea analizzata dagli utenti. I ricaricamenti possono essere pianificati o attivati da un trigger esterno. Gli utenti interrogano l'istantanea dell'applicazione anziché la fonte originale direttamente, come descritto nella documentazione Qlik sulle applicazioni analitiche.
L'acquisizione delle modifiche e il ricaricamento dell'applicazione costituiscono quindi passaggi distinti. L'acquisizione a monte può aver già trasferito una modifica al data warehouse, ma l'applicazione in-memory deve ancora caricare i dati che la contengono. Viceversa, ricaricare più frequentemente un'applicazione non può rendere più aggiornato un dataset a monte.
Direct Query di Qlik Cloud legge i database SQL senza importarne i dati in memoria. Per questa modalità, tracciate il database interrogato e la richiesta che ha prodotto il risultato visualizzato, invece di presumere che un ricaricamento in-memory sia l'ultimo passaggio prima della disponibilità dei dati. Nella valutazione dell'attualità dei dati della vostra installazione, includete il comportamento di eventuali cache e dell'aggiornamento della vista.
La distinzione è pratica: chiedete quale percorso dei dati utilizzi ciascuna visualizzazione rilevante. Non considerate «connesso al database», «CDC abilitato» e «ricaricamento pianificato» come descrizioni equivalenti dell'attualità dei dati.
L'acquisizione in streaming è solo una parte del percorso
La presentazione sul lakehouse in IBM Cloud descrive il trasferimento continuo dei dati dei topic Kafka in file Parquet su object storage. Collega inoltre l'arrivo dei dati in piccoli incrementi all'accumulo di file di piccole dimensioni e descrive la postelaborazione necessaria per le prestazioni e per preparare i dati al consumo semantico.
Questa architettura mette in luce un passaggio importante. La presenza di un record in un file di destinazione non stabilisce quando quel record entri a far parte del dataset preparato per l'analisi. Se la dashboard utilizza una tabella preparata, tracciate la pubblicazione di quella tabella, non soltanto l'arrivo nello storage. Se la postelaborazione non fa parte del percorso che rende visibili i dati, non conteggiatela come un'attesa obbligatoria. Sono le dipendenze effettive a determinare dove si accumula il ritardo.
Decidere dove collocare le trasformazioni in uno stack Qlik e lakehouse è una questione progettuale distinta. Per l'attualità dei dati, il compito immediato è identificare quali trasformazioni debbano terminare prima che un evento aziendale possa essere rappresentato correttamente.
Un approccio diverso emerge dalla proposta LTAP presentata nel keynote Databricks. Databricks ha proposto di unificare lo storage operativo e quello analitico, invece di mantenere una pipeline convenzionale di copia dei dati. La presentazione descriveva il rilascio come futuro. L'idea architetturale consiste nell'eliminare un passaggio di trasferimento. Non stabilisce un requisito di integrazione per Qlik e non elimina la necessità di misurare quando una modifica confermata con un commit diventa visibile all'utente.
Tracciare un evento aziendale e poi verificarne la completezza
Considerate, come esempio, un ordine che attraversa il percorso verso un'applicazione in-memory. Utilizzate timestamp provenienti da orologi sincronizzati e conservate un identificativo stabile dell'ordine, in modo che ogni osservazione si riferisca allo stesso evento. La traccia dovrebbe contenere:
source_commit_at: il momento del commit della transazione nel sistema operativo, non quello in cui qualcuno ha inizialmente inserito l'ordine.captured_at: il momento in cui l'acquisizione o l'estrazione ha rilevato la modifica confermata.landed_at: il momento in cui la modifica è diventata disponibile nella destinazione di arrivo.prepared_at: il momento in cui la preparazione necessaria ha pubblicato la rappresentazione analitica corretta.analytics_available_at: il momento in cui è diventata disponibile l'istantanea dell'applicazione contenente l'ordine.visible_at: il momento in cui il risultato visualizzato dall'utente ha effettivamente incluso l'ordine.
Il tempo trascorso da source_commit_at a visible_at misura il percorso di questo evento. Le differenze tra timestamp consecutivi localizzano le attese e le elaborazioni lungo il percorso. Per Direct Query, sostituite il passaggio dell'istantanea con l'esecuzione della query pertinente e il percorso del risultato. Osservate il risultato visualizzato, invece di presumere che una vista già aperta sia cambiata.
Supponete ora che l'ordine non entri nel dataset preparato utilizzato da un ricaricamento. Il ricaricamento può concludersi correttamente su quel dataset senza includere l'ordine. Un timestamp di completamento recente descrive l'operazione di ricaricamento, ma non può dimostrare che siano arrivati tutti gli eventi attesi da monte. Nemmeno la comparsa di un ordine più recente in un altro punto dei dati dimostra che questo ordine sia presente.
È questa la differenza tra recenza e completezza. Tracciate la visibilità degli eventi, ma riconciliate anche i record e gli stati attesi attraverso il passaggio rilevante. Utilizzate record di prova autorizzati e confrontate la rappresentazione aziendale risultante con la fonte. Quando il connettore e il modello della destinazione lo supportano, includete nei controlli di accettazione anche i record modificati ed eliminati, non soltanto quelli appena creati.
Interpretate letteralmente le etichette dei timestamp. La documentazione Qlik sull'attualità dei dataset usa l'ultimo evento alla fonte per il metodo CDC e l'ultima esecuzione della pipeline per il metodo Reload and compare. Sono riferimenti temporali diversi e nessuno dei due dovrebbe essere implicitamente rinominato come l'istante fino al quale una dashboard è completa.
Definire un'aspettativa di attualità valida anche dopo un'interruzione
Definite l'aspettativa in funzione della decisione aziendale: quali eventi devono essere visibili, quanto ritardo è accettabile e quali controlli di completezza devono essere superati. Distinguete il funzionamento normale dal recupero dopo un'interruzione. Decidete anche cosa debbano vedere gli utenti quando non è possibile stabilire l'attualità dei dati: un avviso, un ultimo stato noto chiaramente etichettato oppure una limitazione all'uso del risultato per una decisione operativa.
La sola pianificazione non basta. Qlik Cloud documenta limiti di durata dei ricaricamenti e di attesa nelle code dovute alla concorrenza che possono causare il fallimento del ricaricamento. Monitorate il completamento effettivo e i dati rappresentati, invece di equiparare la frequenza configurata all'attualità effettivamente ottenuta.
Costruite il monitoraggio attorno ai passaggi della traccia. Registrate l'avanzamento dell'acquisizione, la disponibilità nella destinazione, la pubblicazione della preparazione, la disponibilità nell'applicazione e lo stato osservato sullo schermo, utilizzando le interfacce disponibili nella vostra installazione. Assegnate un responsabile a ogni ritardo. Tenete separato lo stato operativo da una posizione verificata di «completezza fino a», cioè il punto della fonte fino al quale la riconciliazione ha avuto esito positivo.
Obiettivi più stringenti vanno valutati rispetto al lavoro che richiedono. Estrazioni o ricaricamenti più frequenti possono comportare più letture della fonte e più elaborazione. Lotti di pubblicazione più piccoli possono ridurre l'attesa aumentando però il sovraccarico di elaborazione. Per l'accesso diretto al database, valutate il carico analitico imposto a quel database. Confrontate queste opzioni rispetto allo stesso requisito di visibilità e completezza, non soltanto all'intervallo configurato più breve.
Infine, interrompete e riavviate il percorso in un ambiente di test autorizzato. Verificate se il recupero ripristina lo stato aziendale atteso, quanto tempo richiede lo smaltimento dell'arretrato e se la dashboard rimane chiaramente etichettata mentre è in ritardo. Un processo che ha ripreso a funzionare non ha necessariamente recuperato l'arretrato.
Se la vostra dashboard Qlik sembra veloce ma l'attualità dei suoi dati rimane incerta, esaminate il percorso dei dati Qlik con Digiventi. Partite dall'evento aziendale che deve essere visibile e tracciate i passaggi tra il suo commit e la schermata.