OCI HeatWave. Rivoluzione Oracle

Come un raggio di luce in un cielo attraversato da nembi sfilacciati, arriva l’annuncio di Oracle, con cui il colosso di Austin, presenta un nuovo servizio che farà la felicità di molti. Si tratta di un un servizio di database interamente gestito, basato su HeatWave, quello che potremmo definire un in-memory query accelerator. Considerando i data warehouse workloads, la soluzione di Oracle è di gran lunga la più efficace in termini di performance e rapporto costi-benefici e offre, in aggiunta, un’integrazione in-database di machine learning, che viene impiegato per automatizzare diversi aspetti del servizio, riducendo gli oneri di gestione e di ottimizzazione (tuning) del database. HeatWave è al momento l’unico servizio per database in cloud che combina in un unico sistema MySQL transazioni, analitiche, data lake querying e machine learning. Riesce a distribuire dati analitici in real time e in modo sicuro senza la complessità, la latenza e l’aggravio di costi della duplicazione ETL.

HeatWave Lakehouse abilita il querying dei dati presenti nell’archivio oggetti (object storage) in una grande varietà di formati (come ad esempio CSV, Parquet e Avro) ed esportazioni (ad esempio Aurora, Reshift, MySQL, Oracle). Gli utilizzatori possono, così, interrogare centinaia di terabytes di dati contenuti nell’archivio e in modo opzionale combinarli con dati transazionali contenuti in database MySQL. Come scrive Lindsay Clark, Oracle ha fatto anche di più: ha promesso l’accesso futuro ad AWS S3. Insomma, MySQL HeatWave Lakehouse è un'estensione della piattaforma proprietaria di analisi di Oracle che ora supporta l'archiviazione di oggetti all'esterno del database. Il sistema di analisi, costruito sul database MySQL open source, può interrogare i dati nell'archivio oggetti in una varietà di formati di file e combinarli con i dati in MySQL. Nel frattempo, i file nell'archivio oggetti vengono interrogati direttamente da HeatWave senza copiare i dati nel database MySQL.

Come menzionato, la tecnologia Data Lake supporta diversi formati di file. Allo stesso tempo, MySQL Autopilot promette di migliorare le prestazioni e la scalabilità senza richiedere competenze di ottimizzazione del database. Oracle ha dichiarato che su un benchmark di 500 TB TPC-H, rispetto al nuovo Data Lake HeatWave, sul Data Warehouse di AWS le query ci impiegano 9 volte più tempo e, su Snowflake e Databricks. 17 volte di più, mentre BigQuery di Google sarebbe 36 volte più lento. Oracle non ha pubblicato confronti, invece, con Teradata - che inventò nel 1979 il Data Warehouse.

 

La performance di caricamento di MySQL HeatWave Lakehouse:

• 9x più veloce di Redshift;
• 2x più veloce di Snowflake;
• 6x più veloce di Databricks;
• 8x più veloce di Google BigQuery.

Questa velocità record è resa possibile grazie all’architettura scalabile dei processi che operano una partizione perfetta e un bilanciamento delle task e utilizzano tutti i core della CPU disponibili per lanciare prontamente query sui file esterni, garantendo che tutti i 512 nodi nel cluster siano usati in tandem, assicurando una scalabilità massiva.

Al momento il sistema è disponibile solo su Oracle Cloud Infrastructure (OCI), ma Nipun Agarwal, vicepresidente senior di MySQL HeatWave ha dichiarato che è prevista l’estensione del sistema per interrogare i dati conservati nell'archivio oggetti (object storage) in altri cloud tra cui AWS, Azure e GCP.

«Una delle cose su cui voglio guidare l’attenzione - ha affermato Nipun Agarwal - è che i dati nell'archivio oggetti rimangono nell'archivio oggetti. Non copiamo i dati dall'archivio oggetti nel database MySQL. L'elaborazione di questi dati, inoltre, sia che si tratti di caricamento o di query, viene eseguita da HeatWave e non dal motore MySQL. Questo è ciò che gli conferisce un'estrema scalabilità perché il cluster HeatWave può scalare fino a 500 nodi.»

L'utilizzo dei motori di analisi per interrogare i dati esterni al database di casa non è una novità. L'approccio è stato utilizzato da Snowflake, Cloudera e BigQuery di Google con il loro supporto per il formato tabella Apache Iceberg. Allo stesso modo, Databricks, Microsoft e SAP hanno accolto un formato di tabella Delta Lake, basato su open source della Linux Foundation e sviluppato da Databricks. La vera novità è l’integrazione che consente performance così eclatanti in termini di costi-benefici per OLTP, OLAP e Machine Learning.

Una sintesi comparativa tra servizi è disponibile nel sito di Oracle, dove sono state predisposte delle tabelle esaustive sulle performance e i costi di utilizzo. 

Oracle mette a disposizione anche una Technical Overview per approfondire i vari elementi della soluzione.

Nel documento vengono innanzitutto riportate le sfide che oggi devono
affrontare le soluzioni Lakehouse con la crescita esponenziale dei dati:

• La scalabilità e velocità delle interrogazioni.
• Una mappatura efficiente dei contenuti.
• Un accesso omogeneo ai diversi formati di file supportati.
• Convergenza e interoperabilità alle fonti.
• Performance delle query prevedibili per tutte le fonti.
• Machine Learning sull’archivio oggetti (object storage).

Tralasciando gli elementi più tecnici, il documento si sofferma sulla caratteristica dell’architettura di essere scalabile end-to-end e ne precisa le modalità.

Ridimensionare la distribuzione delle scansioni dei dati e delle attività di trasformazione in tutto il cluster può risultare problematico durante l'esecuzione del partizionamento basato sui dati. MySQL HeatWave Lakehouse è ottimizzato per evitare qualsiasi problema di sincronizzazione attraverso i nodi di calcolo con una nuova tecnica chiamata super-chunking con cui divide i dati di origine in unità di lavoro più piccole.

Come ha affermato Holger Mueller, Vice President & Principal Analyst di Constellation Research, «È un dato di fatto, da quando si è iniziato a parlare di Big Data, le queries nei Lakehouse sono sempre state più lente rispetto a quelle in MySQL. HateWave pone per sempre la parola fine a questo divario, dimostrando che le performance di un Lakehouse possono essere identiche alle performance delle transaction query, cosa che era inaudita e persino inpensabile».