Analisi dati con il modello HTAP: meno complessità per risultati efficaci

Analisi dati con il modello HTAP: meno complessità per risultati efficaci

Sarai d’accordo con me che l’analisi dei dati è diventata una componente fondamentale per le aziende moderne, consentendo loro di trarre informazioni significative per prendere decisioni strategiche.

Tradizionalmente, l’analisi dei dati è un componente critico dell’infrastruttura informatica che prevede l’integrazione di due sistemi generalmente presenti nella piattaforma dati: i sistemi transazionali e quelli analitici.

Potremmo identificare i sistemi transazionali (OLTP - Online Transaction Processing) con le “banche dati” operative, ovvero a supporto delle operazioni quotidiane legate processi aziendali. Ad esempio operazioni bancarie online, acquisti, inserimento di ordini, di dati di produzione o invio di messaggi di testo.

D’altra parte, i sistemi analitici (OLAP - Online Analytical Processing) hanno uno scopo diametralmente opposto. Spesso vi accedono pochi utenti, e servono ad analizzare grandi moli di dati per trarne informazioni strategiche. Ad esempio, il management di un sito di e-commerce vorrà conoscere il volume delle vendite dell’anno precedente a confronto con l’anno in corso.

Perché mantenere un sistema di analisi dati tradizionale può essere un sfida?

Per capire il motivo per il quale mantenere un sistema di analisi può essere una sfida si devono considerare le differenze tra i sistemi transazionali ed analitici.

I sistemi OLTP sono caratterizzati quindi da una frequenza di operazioni di scrittura e lettura dati molto intensa e spesso vi hanno accesso numerosi utenti, anche in contemporanea. Queste operazioni hanno bisogno di tempi di risposta molto brevi per non pregiudicare l’operatività degli utenti. Inoltre, molto spesso, la singola transazione coinvolge pochi dati.

I sistemi OLAP, come visto in precedenza hanno una funzionalità completamente diversa in quanto non supportano l’operatività a supporto delle singole transazioni. Si concentrano piuttosto sull’analisi puntuale di una grandissimi quantità di dati. I sistemi OLAP quindi sono ottimizzati per la lettura, dal momento che la loro operatività non prevede la creazione di dati. Inoltre vi hanno accesso molti meno utenti. Ed anche le considerazioni sulle performance saranno diverse in quanto non ci si aspetterà un risposta “immediata” come i sistemi transazionali.

I dati che vengono analizzati dai sistemi OLAP sono perciò quelli “prodotti” sui sistemi transazionali OLTP. Generalmente per essere a disposizione sui sistemi analitici, i dati vengono estratti dai sistemi transazionali e trasferiti in un data warehouse o un data lakehouse dedicato per l’analisi.

Questo approccio comporta tuttavia dei fattori che devono essere tenuti in considerazione come la latenza nell’aggiornamento dei dati e la complessità nell’integrazione di dati provenienti da diverse fonti. Ad esempio i data engineer si occupano di creare sistemi software (data pipeline e processi ETL) a questo scopo, come si vede nell’immagine sottostante (fonte Microsoft).

Inoltre, l’integrazione dei dati in tempo reale (esigenza sempre più diffusa) può diventare complessa. Occorre infatti garantire l’aggiornamento continuo dei dati analitici senza compromettere le prestazioni.

Tuttavia la realizzazione di un data warehouse o di un data lakehouse è sempre l’unica soluzione percorribile?

E’ possibile avere un sistema più snello, per necessità di analisi dati più semplici?

Non sempre la mole e l’eterogeneità dei dati giustificano la realizzazione di un’infrastruttura complessa come un data warehouse o un data lakehouse.

Capita che le aziende abbiano bisogno di analizzare solo una parte dei loro dati, magari quella più rilevante per il loro business o per i loro obiettivi. Inoltre, molte aziende hanno bisogno di analizzare i loro dati in tempo reale o quasi reale.

In questi casi, una soluzione basata su data warehouse o data lakehouse può essere sovradimensionata. Per questo motivo, molte aziende stanno cercando alternative più agili ed efficienti per l’analisi dei dati.

Tuttavia l’evoluzione tecnologica degli ultimi anni, ha messo a disposizione delle tecnologie che permettono alle aziende di sviluppare sistemi di analisi più leggeri e snelli che in alcuni casi, possono offrire una alternativa interessante rispetto alle implementazioni di analisi tradizionale.

Due di queste tecnologie sono i database in-memory e l’indicizzazione e compressione dei dati in forma colonnare (introdotte su SQL Server nella versione 2012). Spesso questi due approcci vengono utilizzati insieme per ottenere il massimo delle prestazioni.

Cosa si intende per tecnologia in-memory?

Quando si parla di tecnologia in-memory ci si riferisce alla possibilità di memorizzare e processare i dati in RAM, anziché nei dischi rigidi o nei dispositivi di archiviazione esterni. Dal momento che la velocità di lettura e scrittura in RAM è molto più veloce rispetto all’utilizzo di un disco standard, le prestazioni dei database che sfruttano questo tipo di tecnologia sono elevatissime.

Tuttavia, poiché tutti i dati vengono archiviati e gestiti esclusivamente nella memoria principale, che è volatile, i database in memoria rischiano di perdere dati in caso di errore del processo o del server. Comunque, i database in memoria possono rendere persistenti i dati sui dischi archiviando ogni operazione in un registro o acquisendo istantanee.

Avendo dei tempi di risposta quasi istantanei, sono adatti ai carichi di analisi dati in tempo reale. Tuttavia va considerato che è necessaria una progettazione ad hoc degli oggetti del database (tabelle, viste, procedure) per poter utilizzare l’opzione di memorizzazione in RAM.

Sia Azure SQL che SQL Server supportano la memorizzazione delle tabelle in memoria (In-Memory OLTP), che inoltre, consente di sfruttare al meglio l’architettura ad indici colonnari (columnstore index) per migliorare le prestazioni delle funzionalità di analisi come indicato in questo articolo di Microsoft.

Ma cosa sono gli indici colonnari?

Cosa sono gli indici colonnari e perché sono un valido alleato nei carichi di analisi dati

Per eseguire una query sui dati, questi generalmente vengono “indicizzati” in strutture chiamate, appunto, indici. Tradizionalmente, nei database, gli indici “impacchettano” il dato per riga come si vede nello schema sottostante preso dal sito di Panoply (data warehouse in cloud).

Questo implica che l’indice (almeno l’indice clustered, per il non-clustered è una storia leggermente diversa) riporti integralmente tutta la riga della tabella. Per cui recuperare una singola riga, conoscendone il suo indice, sarà un’operazione velocissima grazie alla struttura ad albero rovesciato su cui è ordinato l’indice stesso.

Questo funzionamento è ottimo in un sistema OLTP dove ad esempio, si deve recuperare una singola riga, modificarne un valore, e persisterla.

Ma nei carichi OLAP di analisi dati, la funzione in genere non è questa. Si tende piuttosto a recuperare un’infinità di valori disposti su tantissime righe, ma solo su poche colonne. Tipicamente quelle che indichiamo come “misure” di un fenomeno. Ad esempio di tutti i dati contenuti in una riga di dettaglio ordine ci interesserà solo l’importo totale per avere una sommatoria del valore di tutti gli ordini effettuati in un arco temporale.

Indice colonnare VS indice tradizionale

A differenza degli indici tradizionali, gli indici colonnari archiviano i dati per colonne anziché per righe, consentendo una compressione più efficiente e una maggiore velocità di ricerca. Questo perché il tipo di dato contenuto in ogni colonna è omogeneo e di conseguenza la compressione può essere conosciuta ed ottimizzata in anticipo. Come si evince dall’immagine sottostante infatti (anche essa presa da Panoply), sarà molto più semplice comprimere una colonna che contiene solo caratteri a lunghezza fissa (SSN, nell’esempio) piuttosto che una riga contenete interi, lunghezze fisse e variabili come nel caso precedente.

Per cui, tornando all’esempio precedente, tramite un indice colonnare sarà possibile recuperare solo gli importi degli ordini in un determinato periodo, senza dover recuperare tutte le righe, e leggerne l’importo.

Ciò si traduce in tempi di risposta più brevi per le query che richiedono l’analisi di un gran numero di righe e un numero di colonne relativamente piccolo.

Questa modalità offre dei vantaggi per le operazioni OLAP, come:

• Una riduzione dello spazio occupato dai dati, grazie alla possibilità di applicare tecniche di compressione più efficaci sui valori omogenei delle colonne.

• Una riduzione del tempo necessario per eseguire le query analitiche, grazie alla possibilità di accedere solo alle colonne necessarie per la query anziché a tutte le righe della tabella.

• Una maggiore velocità nell’esecuzione delle operazioni di aggregazione.

Come creare un indice colonnare su Azure SQL o SQL Server

La creazione di un indice colonnare su SQL Server o Azure SQL è un’operazione semplice in quanto la sintassi è la medesima come per la creazione di altre tipologie di indice. Nell’esempio sottostante, sto utilizzando il database di esempio WorldWideImporters per SQL Server.

USE WideWorldImporters;
GO

-- creazione indice
CREATE NONCLUSTERED COLUMNSTORE INDEX [NCCX_Sales_OrderLines] ON [Sales].[OrderLines]
(
	[OrderID],
	[StockItemID],
	[Description],
	[Quantity],
	[UnitPrice],
	[PickedQuantity]
)
GO

-- query di esempio
DECLARE @StartingTime datetime2(7) = SYSDATETIME();

SELECT ol.StockItemID, [Description], SUM(Quantity - PickedQuantity) AS AllocatedQuantity
FROM Sales.OrderLines AS ol WITH (NOLOCK)
GROUP BY ol.StockItemID, [Description];

PRINT 'Using nonclustered columnstore index: ' + CAST(DATEDIFF(millisecond, @StartingTime, SYSDATETIME()) AS varchar(20)) + ' ms';

SET @StartingTime = SYSDATETIME();

SELECT ol.StockItemID, [Description], SUM(Quantity - PickedQuantity) AS AllocatedQuantity
FROM Sales.OrderLines AS ol WITH (NOLOCK)
GROUP BY ol.StockItemID, [Description]
OPTION (IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX);

PRINT 'Without nonclustered columnstore index: ' + CAST(DATEDIFF(millisecond, @StartingTime, SYSDATETIME()) AS varchar(20)) + ' ms';
GO

Per avere un’idea delle performance lo script sopra esegue una query con e senza l’utilizzo dell’indice columnstore e ne stampa il tempo d’esecuzione. L’utilizzo del columnstore index porta il tempo di esecuzione a circa un decimo del tempo senza utilizzare l’indice colonnare.

Certo l’esempio è molto riduttivo, ma dando uno sguardo ai due piani di esecuzione (il primo con indice columnstore, il secondo senza) si capisce come cambia totalmente la storia nei carichi di analisi. Tutto il carico pesa sull’indice columnstore che viene letto efficientemente da un thread dell’engine di SQL.

Tuttavia va tenuto presente che l’engine di SQL Server e Azure SQL gestisce l’indice columnstore come un processo in background che attende il riempimento di un buffer chiamato “deltastore” prima di rendere visibili le modifiche all’indice, in particolare quando si modificano i dati (quanti ricordi all’esame di certificazione!). Queste e altre considerazioni sono necessarie quando si vuole utilizzare un database OLTP per carichi analitici. Per informazioni più dettagliate sull’implementazione Azure SQL o SQL Server vedi la serie di articoli dedicati di Microsoft.

Oppure chiedimi una consulenza gratuita!

L’approccio ibrido: HTAP per eliminare la complessità

Tutto questo ci porta a trarre delle conclusioni: questo non significa che i sistemi tradizionali per l’analisi dati siano da scartare, anzi! Ma va considerato il caso d’uso concreto.

Tramite tecnologie come quelle viste ora, negli ultimi anni si è sviluppato il modello HTAP (Hybrid Transaction / Analytical Processing) ovvero un sistema che possa supportare sia carichi transazionali che analitici, anche in real-time, in modo piuttosto semplice.

fonte GridGain

• Rimuovendo la latenza associata allo spostamento dei dati dai database operativi ai data warehouse e ai data lakehouse per l’elaborazione analitica, questa architettura consente l’analisi in tempo reale.

• Inoltre le tecnologie in-memory consentono di avere un unico archivio dati in memoria con accesso a bassa latenza in grado di elaborare elevati volumi di transazioni.

• Infine questo ci permette di ridurre notevolmente lo sviluppo e manutenzione dei processi software coinvolti nello spostamento ed elaborazione dei dati.

Il risultato è una struttura più semplice, snella ed economica.

Il segreto è conoscere i propri dati ed avere obiettivi chiari

Per concludere, ci tengo a sottolineare come sia davvero importante conoscere l’essenza dei propri dati e avere chiaro in mente l’obiettivo di business che si vuole raggiungere.

Senza questi due requisiti sarà troppo facile sviluppare soluzioni sovradimensionate, o magari insufficienti.

Tuttavia non è l’unico monito: non smetterò mai di ricordare quanto sia importante rivolgersi a professionisti certificati che sappiano dove mettere le mani! ;-)

Spero che questo articolo ti sia stato utile per capire come poter utilizzare il tuo sistema, già da ora, per eseguire l’analisi suoi tuoi dati!

E se posso esserti utile per informazioni, idee o confronti, non esitare a scrivermi!

Alla prossima informazione!

---

• ← Previous Post
• Next Post →