Web database: la questione MapReduce (Parte Seconda)

Quando si accede e si analizzano i dati esistono tre tipi di processo che vale la pena siano presi in considerazione: elaborazione batch di dati statici, elaborazione interattiva di dati statici ed elaborazione dinamica di dati in-flight. Un ambiente di Business intelligence, per esempio, prevede l’elaborazione Sql di dati statici di un datawarehouse. Questa può avvenire in modalità batch o interattiva. Sql può anche essere usato per analizzare e trasformare dati catturati da sistemi operazionali che servono ad alimentare un datawarehouse.
MapReduce è utilizzato per processare grandi volumi di dati in modalità batch. Risulta perciò particolarmente utile per elaborare dati non strutturati o dati sparse che fanno riferimento a dimensioni diverse. Non è invece adatto per elaborazione interattiva. Sarebbe molto utile, per esempio, per trasformare grandi volumi di dati non strutturati che devono alimentare datawarehouse od operazioni di data mining.
Né MapReduce, né Sql si dimostrano invece adatti per una elaborazione dinamica di dati in-flight, come per esempio dati riferiti a un particolare evento. Questo è il motivo per cui si introducono estensioni Sql (come StreamSql) così come nuove tecnologie di stream and complex event processing per gestire elaborazioni dinamiche. MapReduce, a ogni modo, è utile per compiere operazioni di filtering e trasformazione di event file quali possono essere considerati i Web log.

MapReduce e la coesistenza e integrazione con il modello relazionale

Più di un vendor di Rdbms analitici (Vertica, GreenPlum, Aster Data Systems) offre soluzioni che utilizzano sia tecnologia MapReduce (MR) che relazionale.
La strategia di Vertica è fondata sulla coesistenza. Con Vertica i programmi MR funzionano nel loro ambiente operativo, ma invece di rilasciare l’output al sistema MR, il programma Reduce genera un output verso il sistema relazionale di Vertica. Il supporto offerto da Vertica si avvale del servizio di Amazon, Elastic MapReduce (Emr), un Web service che fornisce un framework Hadoop che risiede sull’infrastruttura Amazon Elastic Compute Cloud (Amazon EC2) e Amazon Simple Storage Service (Amazon S3). Le informazioni cui si può accedere dal link http://developer.amazonwebservices.com/connect/entry.jspa?externalID=2571
spiegano come utilizzare MR per elaborare e caricare un insieme di dati da S3 al sistema relazionale di Vertica che risiede su Amazon EC2.
La soluzione di Vertica potrebbe essere utilizzata per eseguire operazioni Etl (Extract, transform, load) in modalità batch dove l’input è costituito da grandi volumi di dati (un insieme di Web log per esempio) e l’ouput debba alimentare un datawarehouse gestito da Vertica stessa.
Aster and GreenPlum prevedono invece un’integrazione del framework di elaborazione MR all’interno dello stesso Rdbms in modo da trarre ulteriori vantaggi in attività di elaborazione parallela, scalabilità, backup & recovery e così via.
GreenPlum consente agli sviluppatori di scrivere programmi MR avvalendosi di linguaggi di scripting come Python e Perl. In questo modo gli script MR possono accedere a funzionalità open source per analisi di testo o tool statistici. Agli script è consentito inoltre accedere a flat file e pagine Web così come utilizzare Sql per avere accesso alle tabelle relazionali di GreenPlum. Le tabelle sorgenti possono essere lette da script Map e le tabelle target essere create da script Reduce. Questo tipo di architettura permette agli sviluppatori di sfruttare multiple sorgenti di dati e differenti stili di programmazioni. Consente inoltre di costruire datawarehouse utilizzando sia approcci Etl (i dati vengono trasformati prima che siano caricati nell’ambiente di datawarehouse) che Elt (i dati vengono trasformati dopo che sono stati caricati nel datawarehouse).
E’ possibile utilizzare gli script MR di GreenPlum anche come tabelle virtuali di statement Sql (il job MR viene eseguito on the fly come parte di una query Sql. Il motore Rdbms di GreenPlum esegue tutto il codice – Sql, Map scripts, Reduce scripts – sullo stesso cluster di macchine su cui risiede il database di GreenPlum).
Per ulteriori informazioni è possibile consultare il white paper di GreePlum reperibile all’indirizzo www.greenplum.com/download.php?alias=register-map-reduce&file=GreenPlum-MapReduce-Whitepaper.pdf.
Al contrario di GreenPlum, che tende a enfatizzare l’utilizzo di Sql in programmi MR, Aster adotta un differente approccio, focalizzandosi sull’utilizzo di capacità elaborative di tipo MR all’interno di programmi Sql. Aster fa sì che funzioni MR definite dall’utente possano essere invocate utilizzando Sql. E’ possibile scrivere le funzioni in linguaggi come Python, Perl, Java, C++ e Microsoft .Net (C#, F#, Visual Basic) e possono servirsi di statement per la definizione e manipolazione dei dati. Il supporto a Linux.Net è garantito dal prodotto open source Moni. Le stesse funzioni possono eseguire operazioni read-write da file di tipo flat. Come per GreenPlum le capacità MR di Aster si possono utilizzare per alimentare un datawarehouse sia con un approccio Etl piuttosto che Elt.
Per ulteriori informazioni si può fare riferimento al white paper di Aster reperibile all’indirizzo www.asterdata.com/resources/downloads/whitepapers/Aster_MapReduce_Technical_Whitepaper.pdf.
Sia GreenPlum che Aster permettono di incrociare dati relazionali con dati in stile MapReduce. Una capacità particolarmente utile per attività di trasformazione di dati batch, di integrazione e di data mining intensivo. L’approccio utilizzato dipende dall’applicazione e dalla tipologia dello sviluppatore. In generale si può affermare che i programmatori preferiscono l’approccio GreenPlum mentre gli esperti in Sql tendono a privilegiare l’approccio Aster.

E per quanto riguarda le prestazioni?

I sostenitori di MapReduce affermano con una certa frequenza che questa tecnologia permette prestazioni superiori rispetto a quelle conseguibili con tecnologia relazionale. Tuttavia le performance dipendono fortemente dal carico di lavoro. Andrew Pavlo della Brown University, insieme a Michael Stonebraker e David DeWitt, ha pubblicato di recente un documento che mette a confronto le prestazioni di due Dbms relazionali (Vertica e un Dbms row-oriented) con il MapReduce Hadoop. Dal documento emerge che, “in generale, gli Sql Dbms, pur dimostrando una significativa maggiore velocità e una semplificazione del codice da implementare per i singoli task, impiegano più tempo per le attività di tuning e loading dei dati”. Viene inoltre riconosciuto che “vi sia ancora molto da imparare da entrambi i tipi di sistemi” e che “le Api delle due classi di sistema tendono a convergere”.

Conclusioni

MapReduce ha raggiunto una significativa visibilità grazie all’utilizzo che ne ha fatto Google, alla sua intrinseca capacità di processare grandi volumi di dati Web non strutturati e al dibattito (MapReduce versus tecnologia relazionale) alimentato da sostenitori e detrattori degli opposti schieramenti.
Due cose appaiono chiare. Ai programmatori piace la semplicità di MapReduce e vi è una evidente tendenza verso un’integrazione di capacità MR all’interno di sistemi Dbms tradizionali.
MapReduce si rivela particolarmente adatto per elaborazioni batch di grandi file di dati non strutturati da utilizzare in sistemi di Business intelligence. La mia personale opinione è che, se i programmi MR vengono utilizzati per attività di filtering e trasformazione di dati non strutturati (documenti, pagine Web, Web logs, event file) che devono alimentare un datawarehouse, sia preferibile un approccio Etl e non Elt. Questo perché l’approccio Elt di solito prevede l’archiviazione di dati non strutturati in tabelle relazionali che possono essere manipolate via Sql.
Nello stesso tempo riconosco che vi sono organizzazioni che preferirebbero un framework di database basato su una sola e unica tecnologia di gestione dei dati. Questa è una delle ragioni per la quale i vendor Dbms hanno introdotto supporto aggiuntivo a dati Xml e XQuery all’interno dei loro prodotti Rdbms. La mia preoccupazione è che Sql e i prodotti relazionali stiano diventando troppo complessi, soprattutto per coloro che sviluppano applicazioni.