Come catturare le scie luminose prodotte dai dati con SingleStore
Prima o poi tutti i fotografi si cimentano nell’immortalare scie luminose sfruttando le luci di auto o altre fonti artificiali nella notte. Aumentando il tempo di esposizione della macchina fotografica, ogni fonte luminosa lascia una traccia del proprio movimento. Giocando con i tempi di scatto e con il movimento dei soggetti si possono produrre immagini bellissime e surreali.
Le scie luminose possono rappresentare il concetto di flusso di dati o quello di real-time: anche l’informazione più microscopica, se raccolta in modo opportuno e poi trasformata, insieme a tantissime altre può produrre risultati esaltanti. Se pensiamo a tutti i dati prodotti dalle applicazioni e alle opportunità che possono derivare dal loro sfruttamento, chi non vorrebbe catturare le scie luminose lasciate dai dati?
E’ con questa immagine in mente che vi invito a leggere questo blogpost che parla di real-time analytics, dei diversi volti che assumono i dati oggi e di come evolvono le tecnologie per far fronte a nuovi requisiti creando nuove opportunità. In particolare parleremo di SingleStore (fino a qualche settimana fa noto come MemSQL) e di come si sia affermato tra le tecnologie HTAP, anello di congiunzione tra tecnologie OLTP e OLAP, che permettono l’implementazione di casi d’uso di tipo operational e real-time analytics.
Introduzione
Negli ultimi 40 anni si è affermata la best-practice di implementare use-case analitici su data store separati da quelli adottati per fornire supporto operazionale/transazionale. Questa scelta è stata condizionata dalle performance limitate dei sistemi tradizionali, che rendeva impossibile concentrare volumi elevati di letture e di scritture nello stesso perimetro.
Questo è vero ancora oggi: nella maggior parte dei casi si impiegano database disegnati ed ottimizzati per elaborazioni transazionali (OLTP) per workload di tipo operazionale e si utilizzano tecnologie di tipo OLAP per BI e workload analitici.
Dati Operazionali e Analitici: due facce della stessa medaglia
Ultimamente quando si parla di Data Dichotomy si pone l’accento su una dimensione attorno alla quale i dati sono distinguibili: dati operazionali e dati analitici.
I dati di tipo operazionale servono agli scopi del business permettendo il funzionamento di applicativi e servizi in genere. Sono organizzati tipicamente in Row Store e direttamente su di essi si appoggiano le applicazioni che eseguono accessi puntuali per leggere/scrivere informazioni. Per questo motivo è fondamentale che siano ottimizzati per garantire alti throughput (in particolare per la scrittura) e per sostenere elevata concorrenza. Spesso questi dati sono chiamati “data on the inside” intendendo che questa è la porzione contenuta nel servizio stesso ed esposta solo se necessario via API per stabilire cosa far vedere e a chi. Ci sono diverse tipologie di prodotti tra cui scegliere per questa tipologia di dati: dai classici DB relazionali ai DB a grafo, per casi d’uso dove privilegiare le relazioni tra entità, a quelli NoSQL per maggiore flessibilità e per il supporto all’out-scaling, oppure ancora ai Document Store per gestire dati semi-strutturati. Tra le tecnologie in gioco ci sono grandi player storici come Oracle, PostgreSQL o Microsoft SQL Server, a cui si aggiungono prodotti più recenti che presidiano particolari sotto-aree come Elasticsearch, Redis, Neo4j o MongoDB. A questi si affiancano le offerte dei vari cloud provider tra cui Amazon RDS, Google Cloud SQL o Microsoft Azure SQL
Sull’altra faccia della medaglia ci sono i dati di tipo analitico, che nascono come supporto alla BI e quindi con l’obiettivo di calcolare KPI allo scopo di migliorare processi aziendali. Sono organizzati tipicamente in Column Store e permettono l’interrogazione di grandi volumi di dati con profondità storica. Sono quindi pensati per sostenere elevati throughput di lettura e bassa latenza. Questi dati rientrano nei “data on the outside”, trattandosi di informazioni che sono scambiate tra più componenti tra loro indipendenti: cioè avviene attraverso la propagazione di eventi, lo scambio di file o l’integrazione dei dati in tabelle. Tra i tipi di prodotti che trattano questa categoria di dati ci sono gli object store (soprattutto per raccogliere dati raw costruendo dei data lake), i database analitici (che ottimizzano il formato dei dati per l’interrogazione via SQL) o gli streams (per la propagazione delle informazioni introducendo un disaccoppiamento tra chi produce e chi consuma). Tra le tecnologie citiamo come data warehouse Teradata e Vertica, come Data Platform si affermano invece Cloudera e Snowflake e naturalmente non mancano i prodotti dei cloud provider tra cui Amazon Redshift, Google BigQuery e Azure Synapse Analytics.
Integration
I dati fluiscono tra questi due mondi andando dai sistemi operazionali a quelli analitici. Questo può avvenire in due modalità:
- via batch, trasferendo i dati in modo asincrono e processandoli in lotti che sono disponibili sul target con un ritardo nell’ordine delle ore.
- in streaming, propagando i dati in modo continuo (o quasi) eseguendo dei micro-batch e riducendo il ritardo nell’ordine dei minuti.
Non è escluso naturalmente anche un ciclo di ritorno in cui alcuni dati analitici sono portati sui sistemi OLTP per il loro utilizzo all’interno delle applicazioni (es. app che riporta statistiche settimanali/mensili).
Tuttavia questo fenomeno migratorio dei dati consuma del tempo e il tempo è denaro: i casi d’uso analitici hanno dei veri e propri requisiti temporali per poter garantire un azione contestuale che porti valore. In base a quanto tempo si è disposti ad attendere per l’elaborazione di un insight si possono distinguere varie casistiche a cui corrispondono diversi stack tecnologici: si parla di finestra di reattività.
Siamo in presenza di Strategic Analytics quando il tempo che intercorre tra la produzione di un insight e l’azione è compreso tra mesi e anni: ad esempio se si registrano incrementi delle richieste di mobili, si decide di espandere la linea di produzione. Oppure quando questo intervallo è compreso tra minuti e mesi si parla di Performance Analytics: un caso tipico è una previsione di incremento delle vendite a cui corrisponde l’azione di incrementare le scorte. Per queste prime due categorie di analytics i sistemi tradizionali di BI calzano alla perfezione: sia i Data Warehouse che i Data Lake sono adeguati: si preferirà uno all’altro in funzione del volume dei dati e del loro formato. Il tutto viene reso possibile attraverso una fitta rete di flussi di data integration che raccolgono i dati dai sistemi sorgente e li depositano su questi storage.
E quando i requisiti temporali sono più stretti quali sono gli scenari che si prospettano?
Si parla di Operational Analytics quando la reattività è compresa tra i secondi e i minuti: importante ad esempio per sistemi di vendita online nel momento in cui i profitti sono inferiori agli obiettivi per correggere i prezzi on-the-fly in funzione del volume delle richieste. Mentre per requisiti ancora più stringenti, inferiori al secondo o al massimo nell’ordine dei secondi, si parla di Real-time Analytics: ad esempio durante lo shopping online se il cliente inserisce nel carrello un prodotto si fa recommendation di un prodotto correlato oppure si pensi all’integrazione con sistemi di natural language, processing, di image recognition o di fraud detection che devono reagire in modo tempestivo. Per sostenere queste due categorie di analytics i sistemi tradizionali non sono più adeguati.
Perchè? Proprio per via di come tali sistemi sono strutturati a basso livello: non riescono a rispondere a entrambi i requisiti richiesti, fast ingestion e bassa latenza per query analitiche. Infatti i Row Store supportano fast ingestion trattando i dati nel loro formato nativo senza applicare alcuna ottimizzazione a livello di encoding o compression, ma proprio per questo motivo non sono adeguati per workload analitici. Al contrario i Column Store sono adeguati a workload analitici ma se ricevono grossi volumi di dati in ingresso a distanza troppo ravvicinata vedono un degrado considerevole delle performance di lettura a causa delle operazioni necessarie alla compaction e all’ottimizzazione di tutti i dati ricevuti nel frattempo.
Fortunatamente, negli ultimi 5 anni si è affermato un nuovo tipo di soluzione che cerca di colmare questo buco tecnologico. Si tratta dei sistemi HTAP (Hybrid Transactional and Analytical Processing) o HOAP (privilegiando il termine Operational a Transactional, per non escludere sistemi NoSQL e non relazionali).
I prodotti che rientrano in questa categoria sono molteplici: a partire da SAP Hana, pioniere sul mercato, e continuando con prodotti NewSQL (che portano la scalabilità dei sistemi NoSQL per workload OLTP pur continuando a garantire le proprietà ACID dei sistemi tradizionali). Tra questi spicca SingleStore, di cui parleremo tra poco. Hanno introdotto il supporto a questo tipo di workload anche alcuni sistemi documentali e database NoSQL come Redis Labs e Aerospike o In-Memory Computing Platform come GridGain.
Tuttavia SingleStore rispetto a SAP Hana e ad altri prodotti blasonati ha un TCO decisamente più basso mentre rispetto ai NoSQL ha evidentemente il notevole vantaggio di supportare il linguaggio SQL.
Inoltre un altro aspetto da considerare nel confronto tra prodotti documentali e SingleStore è la flessibilità nella definizione di single view. Infatti, nonostante i documentali permettano ormai di creare cross-reference tra più elementi, quando le viste coinvolgono più di un paio di entità o richiedono interrogazioni complesse ci si scontra presto con un degrado delle performance di aggiornamento delle single view (che può superare la decina di secondi).
Un esempio di vista complessa? ottenere il dettaglio di un cliente che fa 4/5 visite al mese in un negozio e per ogni visita fa uno scontrino da almeno 20 prodotti di categoria X, con le relative promozioni utilizzate.
Entità coinvolte: cliente, negozio, scontrino, prodotti, promozioni
Naturalmente anche i big player come Oracle e SQL Server non sono rimasti a osservare e anche loro hanno previsto copertura per questi workload. Tuttavia SingleStore prevale anche in questo caso dal momento che essendo stato realizzato nativamente per workload HTAP raggiunge performance migliori a parità di risorse computazionali e quindi con TCO inferiore.
Per approfondire il confronto tra SingleStore e i competitor si rimanda a questo link.
Una precisazione è d’obbligo: questo tipo di sistemi non entra in competizione con i prodotti OLAP. Infatti lo use-case primario su cui si fondano i sistemi HTAP è il supporto al real-time analytics sui dati operazionali, per individuare insight a partire dati prodotti dalle applicazioni prima ancora che questi vengano estratti e trasferiti sul Data Warehouse. Tuttavia dal momento che sempre più vendors di storage OLTP annunciano o aspirano ad annunciare l’apertura a workload di tipo HTAP, ci si chiede se avrà ancora senso in futuro fare una distinzione tra OLTP e HTAP. Si stima che nel 2021 i workload di tipo HTAP costituiranno oltre il 40% dei nuovi workload di tipo operazionale (come incremento sugli anni precedenti).
Overview di SingleStore
SingleStore si posiziona a pieno titolo tra le tecnologie HTAP e questo grazie principalmente a 3 features:
- Fast Data Ingest
- Low Latency Queries
- High Concurrency
Grazie a queste features permette un’alimentazione in real-time garantendo la fruibilità del dato in pochi istanti con tempi di lettura ridotti e costanti anche in presenza di elevata concorrenza, soddisfando quindi i requisiti per use case di tipo Operational e Real-Time Analytics.
Queste features sono sorrette a livello tecnico da un utilizzo efficiente della memoria, che sfrutta sia il disco che la memoria volatile, da un’architettura distribuita e scalabile orizzontalmente e da un’interfaccia relazionale verso utenti e applicazioni basata su linguaggio SQL e binary compliant con MySQL (la connessione a SingleStore via JDBC avviene con driver MySQL)
A livello fisico i dati sono organizzabili su due tipologie di storage:
- In-Memory RowStore, particolarmente indicato per l’ingestion di stream di dati ed elaborazioni real-time
- ColumnStore che sfrutta la capacità di dischi fisici, più adatto all’interrogazione di grosse moli di dati storici
La tipologia di storage viene scelta in fase di creazione di una tabella e i dati possono fluire tra le tabelle (e quindi gli storage corrispondenti) attraverso le pipeline: per sfruttare il formato più efficiente in ogni situazione.
SingleStore ha avviato ormai da diversi mesi un progetto chiamato Universal Storage con cui sta cercando sempre più di far convergere questi due formati. Lavorando in tal senso, la versione 7.1 ha escogitato diverse soluzioni, tra cui citiamo:
- la possibilità di consentire al RowStore di gestire un volume di dati molto superiore alla quantità di RAM disponibile, riducendo il TCO e preservando le performance. Questo grazie soprattutto alla compressione di valori NULL, che permette di risparmiare molta memoria per dataset sparsi.
- il supporto ad accessi puntuali per il ColumnStore per sostenere workload con elevata concorrenza di read/write, introducendo Hash Indexes, Row-Level Locking e Subsegment Access.
L’ingestion dei dati può avvenire via streaming o attraverso l’esecuzione di batch. Mentre le tipologie di dati supportati spaziano dal chiave-valore, ai formati semi-strutturati come JSON e Avro, ai dati geo-spaziali e alle time-series. Inoltre SingleStore può essere usato ovunque: dal deploy on-premise, all’utilizzo di container su Kubernetes oppure ancora in modalità SaaS (con la versione SingleStore Managed).
Con queste caratteristiche ha tutte le carte in regola per coprire sia use-case analitici che operazionali. E’ evidente quindi come siano tante le tipologie di situazioni in cui si può impiegare SingleStore: di seguito si tratterà un primo set di use case che ruotano attorno al concetto di omnicanalità e all’architettura del Digital Integration Hub. Per chi fosse curioso di scoprirne altri, vi invito a registrarvi a questo link dove troverete il webinar che abbiamo fatto di recente con Quantyca: al suo interno parliamo anche dell’adozione di SingleStore per costruire un feature store per modelli di machine learning o ancora per generare single view all’interno di un serving layer.
Qualche use case a proposito di Digital Integration Hub
Ultimamente quando si parla di omnicanalità e viene sempre più spesso citato il Digital Integration Hub (DIH). Infatti il DIH è un pattern architetturale con cui è possibile raccogliere in real-time dati provenienti da più sistemi, senza sovraccaricare questi ultimi, e renderli fruibili a una fitta rete di micro-servizi esposti via API che li adattano alle esigenze degli utenti finali per costruire piattaforme omnicanale. Tuttavia, questa architettura non può gravare sulle spalle dei sistemi legacy sottostanti:
- la maggior parte di questi sistemi può essere già a corto di risorse
- tipicamente non si tratta di sistemi in grado di scalare orizzontalmente
- i costi di licenza o legati al consumo di risorse sono elevati
La scelta critica per implementare questa architettura è quindi la scelta dello storage per costruire le single view, asset logici con cui interagiscono micro-servizi e applicazioni di real-time analytics, e la loro alimentazione a partire dai sistemi sottostanti. Questo layer deve poter garantire supporto OLAP e OLTP, ingestion e consumo in real-time ed essere capace di scalare orizzontalmente per far fronte a volumi crescenti di dati o di consumers. Il tutto riducendo il più possibile il TCO.
Con questa architettura si può rispondere a uno scenario molto diffuso: risolvere i limiti del pattern di Event Sourcing per i micro-servizi. Questo pattern prevede che ad ogni modifica ai dati corrisponda la produzione di un evento sul data bus e che ogni consumer interessato debba ricevere tutto lo storico di eventi per saper ricostruire lo stato in un dato istante temporale. Se da un lato questo approccio va bene per scenari complessi, dall’altro è eccessivo richiedere la riproduzione di tutti gli eventi a un micro-servizio che avesse bisogno solo di un accesso puntuale a una porzione dei dati. Per ovviare a questo limite si può impiegare il pattern del DIH introducendo SingleStore come High Performance Data Store che consuma tutti gli eventi prodotti dai micro-servizi creando uno stato condiviso accessibile a tutti. A questo punto i mini-servizi (chiamati così perchè condividono il data store) che hanno bisogno di fare un’accesso puntuale possono semplicemente interrogare SingleStore via SQL. Questo inoltre semplifica scenari come il calcolo di metriche cross-entità o l’aggregazione di dati in una singola entità, che richiederebbero diversi sforzi in assenza dello store condiviso e del supporto SQL.
Un’altra casistica in cui il DIH può venire in nostro soccorso è quella della modernizzazione dei sistemi legacy: attraverso l’integrazione dei dati prodotti da essi in un’architettura che li renda fruibili ad altri sistemi senza impatti sul legacy stesso. Questo è possibile collegando un Change Data Capture al transaction log dei sistemi legacy e riproducendo tutti gli eventi sul Data Bus. In dati sono scodati in real-time dal bus e salvati sull’High Performance Data Store da cui poi i micro-servizi possono leggere le informazioni. I micro-servizi che hanno anche l’esigenza di modificare i dati pubblicano eventi sul Data Bus, da cui verranno scodati ed eseguiti in modo asincrono i “command” (seguendo il pattern CQRS) da parte del sistema legacy. I dati modificati seguiranno poi il percorso già descritto. In questo modo si genera un loop di modifica e propagazione dell’informazione che genera una finestra di incosistenza eventuale: letture intercorse prima del termine del loop si baserebbero su dati consistenti ma non ancora aggiornati. E’ fondamentale quindi la scelta di un prodotto che garantisca fast intestion e bassa latenza per ridurre l’ampiezza di questa finestra. SingleStore risulta quindi perfetto per lo scopo.
Un’ultima situazione che si cita è quella relativa alla gestione delle informazioni provenienti da sensori IoT. Anche in questo caso gli eventi sono raccolti sul Data Bus, per disaccoppiare produttori e consumatori sia in termini temporali (ritmi diversi tra chi scrive e chi legge) che spaziali (evitando connessioni punto punto tra sistemi). Dal Bus gli eventi sono poi propagati sull’High Performance Data Store dove si possono attuare sia analisi classiche di BI, sia algoritmi di real-time analytics, ad esempio per generare delle azioni correttive sui sensori. Ancora una volta SingleStore calza perfettamente come data store da impiegare per questo caso d’uso grazie alla sua capacità di scalare orizzontalmente e alla fast-ingestion. Inoltre in questo contesto, grazie al supporto per le time-series e per le funzioni geo-spaziali, permette lo sviluppo di applicazioni avanzate con sforzo minimo.
Integrazioni con altri prodotti
Tra le integrazioni con prodotti di terze parti vale la pena citare:
- Confluent Kafka. Integrazione possibile in modalità pull, con le Pipeline di SingleStore, o in modalità push, attraverso il Connector di Confluent per Singlestore
- Spark. Utilizzando un connettore ad-hoc che supporta la traduzione delle operazioni fatte sui dataframe in SQL e il push-down della computazione su SingleStore. A questo link potete trovare un webinar sul tema.
- Talend. Attraverso un set di componenti ad-hoc
- Strumenti di BI in genere. Utilizzando il driver jdbc di MySQL
Conclusioni
Le società stanno sempre più prediligendo soluzioni di analytics avanzato per il supporto a decisioni strategiche agendo in misura sempre crescente sulla riduzione della finestra di reattività .
I prodotti emergenti di tipo HTAP permettono di coprire quello che era un punto cieco, fare analytics subsecond, e rispondere a domande che prima non potevano essere espresse. Sono tanti gli use-case che possono trarre vantaggio da queste nuove soluzioni. Grazie a tecnologie come SingleStore, sorgono nuove opportunità per rispondere meglio e più in fretta alle esigenze analitiche e per rispondere quindi più efficacemente a decisioni importanti per il business.
Spero che questo blogpost vi sia piaciuto e abbia fatto luce sugli aspetti fondamentali di SingleStore, dei contesti in cui impiegarlo e delle sfide che permette di risolvere. Se vi è piaciuto lasciate qualche clap per farmelo sapere e state sintonizzati sul profilo ufficiale di Quantyca su linkedin e qui su medium.
Per chi è interessato a questo link potete iscrivervi al webinar che parla dei temi citati in questo blogpost e di altri ancora.
