Apache Hadoop

Hadoop [hadoop] è un framework Java open source per la realizzazione di applicazioni distribuite che lavorano su una grande quantità di dati. Il progetto è stato ispirato dagli articoli scritti da Google relativamente al MapReduce [mapred] e al Google File System (GFS) [gfs].
Hadoop è stato creato da Doug Cutting e successivamente è stato ceduto ad Apache che ne cura lo sviluppo. Tra i suoi maggiori contributori si può citare Yahoo che lo usa come framework per il suo motore di ricerca.
In dettaglio, Hadoop è un insieme di sotto-progetti che forniscono un'infrastruttura per il calcolo distribuito e sono di seguito:

1. Core. Un' insieme di componenti e interfacce per i filesystem distribuiti e per la gestione dell' I/O (serializzazione, Java RPC).

2. MapReduce. Un modello e un ambiente per il calcolo di dati in ambiente distribuito su cluster di grandi dimensioni con macchine commodity.

3. Hbase. Un database distribuito column-oriented che usa HDFS per archiviare le informazioni e che supporta anche le interrogazioni batch-style usando MapReduce.

4. HDFS. Un filesystem distribuito che viene eseguito su cluster di grandi dimensioni con macchine commodity.

5. Pig. Un tool per l'esplorazione di grandi dataset su cluster HDFS o MapReduce.

6. Avro. Un sistema per la serializzazione efficiente di dati.

7. ZooKeeper. Un servizio di coordinamento nodi distribuito.

8. Hive. Un data werehouse distribuito che archivia i dati in HDFS e supporta SQL come linguaggio di query.

9. Chukwa. Un sistema per l'analisi dei dati che usa HDFS per l'archiviazione dei dati e
MapReduce per la generazione dei report.

Apache Cassandra

Cassandra è un database distribuito open source originalmente sviluppato da Facebook, fu implementato da alcuni ingegneri provenienti da Amazon che avevano lavorato per il database Dynamo.
Jeff Hammerbacher che guidava il Facebook Data team, descrive Cassandra come un database bastato sul data model di Google BigTable che viene eseguito su una infrastruttura simile a quella di Amazon Dynamo.
Successivamente Cassandra nel Marzo 2009 è stato ceduto ad Apache che ne cura lo sviluppo. A Febbraio 2010 Apache ha fatto entrare Cassandra nel gruppo dei top-level project. Cassandra è un database progettato per gestire una grande quantità di dati distribuiti su un numero elevato di server commodity offrendo un servizio di alta affidabilità con no single point of failure.
Cassandra è una soluzione NoSQL sviluppata da Facebook per risolvere i problemi relativi alla cattive performance della funzionalità di ricerca Inbox del famoso social network.
Questa funzionalità permette di ricercare tra tutti i messaggi che gli utenti di Facebook si scambiano con i loro amici. L'enormità dei dati e la loro crescita esponenziale e gli stringenti requisiti di performance hanno portato alla realizzazione di questa nuova soluzione di storage.
Una tabella in Cassandra è un mappa multidimensionale distribuita su differenti server indicizzata attraverso una chiave di tipo stringa. La chiave non ha restrizioni sulla dimensione, tipicamente è grande da 16 a 36 bytes, il valore, invece, può essere un oggetto generico strutturato.
Le colonne, similmente a quanto accede per in BigTable, sono raggruppate in entità chiamate column families. Esistono due tipi di column families : Semplici e Super columns families. Quest'ultima può essere vista come una column family dentro una column family.
Caratteristica importante di Cassandra è che l'applicazione può impostare l'ordinamento delle colonne in una column family, scegliendo tra : ordinamento per tempo o per nome. Con l'ordinamento per tempo si possono ottenere maggiori performance per tutte quelle applicazioni che lavorano su dati fortemente correlati nella dimensione temporale. Ad esempio, questo approccio viene utilizzato per conservare i messaggi scambiati tra due utenti di un social network, in cui i dialoghi comunemente vengono mostrati nel portale in base ad un ordinamento temporale.

Bisogna notare che Cassandra supporta la nozione di multiple tables anche se spesso non viene usata e quasi sempre in tutte le applicazioni esiste una sola tabella per schema.
Cassandra espone delle semplici API composte essenzialmente da tre metodi :
insert(table; key; rowMutation)
get(table; key; columnName)
delete(table; key; columnName)
dove il campo columnName si può riferire ad una specifica colonna in una column family, ad una column family, ad una super column family o ad una colonna in una super column.

Cassandra non è single points of failure e può scalare da un solo server a diverse migliaia di macchine in cluster in differenti data center. Nella sua architettura non esistono nodi master e ogni dato può essere scritto in ognuno dei nodi del cluster e può essere letto da ogni altro nodo.
Allo stato attuale, Cassandra viene utilizzato come sistema di storage dalle seguenti aziende:

Facebook, il più famoso social network del web, usa Cassandra per la ricerca dei messaggi scambiati tra gli utenti e per altre funzionalità.

Digg, il più grande portale di social bookmarking a Settembre 2009 [digg] ha iniziato la migrazione verso Cassandra che è terminata a Marzo 2010 [digg2].

Twitter, il più grande portale di microblogging, a causa della vastità di dati trattati dal portale ha deciso di utilizzare Cassandra come sistema di database [twitt].

Rackspace, importante azienda che fornisce hosting online, usa Cassandra internamente.

Cisco's WebEx usa Cassandra per conservare i feed e le attività degli utenti.

IBM ha effettuato una ricerca su come costruire un sistema di gestione mail scalabile basato su Cassandra [ibm].

Reddit, famoso portale di social news, ha sostituito memcacheDB con Cassandra nel Marzo 2010 [redd].

Cloudkick, un cloud server management, usa Cassandra per conservare i nomi e le metriche di performance dei nodi server dei propri clienti [ckick].

Ooyala usa Cassandra per supportare le sue soluzioni di analisi e video business intelligence.

Tassonomia dei nosql

Possiamo classificare le soluzioni di database non relazionali identificate sotto l'acronimo di NOSQL in base a quattro differenti fattori [infoqtax]:
1. Come i dati vengono archiviati logicamente (data model).
2. Come i dati vengono archiviati fisicamente su un nodo.
3. Come i dati vengono distribuiti, replicati e riconciliati in un sistema composto da più nodi.
4. Come di dati vengono presentati all'utente e le varie interfacce di accesso ai dati.
Per il primo punto, a cui spesso ci si riferisce con il termine di data model del database schemaless possiamo identificare le seguenti tipologie:

1. Key/Value store. Il modello key/value è quello più semplice e più facile da implementare. Rappresenta nel campo delle basi di dati quello che nell'ambito della programmazione viene chiamato Array Associativo. Si tratta infatti di una collezione di dati composta esclusivamente da una chiave e da un valore, dove ad ogni chiave è associato uno o più valori. L'operazione di ricerca dei valori, comunemente chiamata lookup, può essere effettuata esclusivamente mediante la chiave che viene indicizzata per aumentare le performance in fase di recupero dei dati. Da notare che sia nel campo chiave che nel campo valore si possono avere dati in qualsiasi formato, da stringhe a dati binari.

2. Document-oriented. Sono database orientati all'archiviazione di documenti e contenuti in generale e rappresentano un'evoluzione rispetto al modello key/value. Diversamente da quanto avviene nel modello relazionale in cui ogni ogni attributo di un oggetto di dominio viene mappato in generale ad una colonna nella relativa tabella entità, nel modello document-oriented ogni record rappresenta un documento che ha dei particolari metadati associati. I metadati possono essere associati in qualsiasi momento al documento e possono contenere dati di qualsiasi natura e dimensione. Diversamente da quanto accade per i modelli key/value e column-family, questo modello prevede l'utilizzo di sistemi di indicizzazione che consentono di effettuare delle query sui metadati dei documenti.

3. Graph-oriented. Sono database ottimizzati per trattare network-oriented data, cioè dati che rappresentano strutture a rete topologicamente complesse o in strutture gerarchiche di grandi dimensioni [neo4j]. Diversamente da quanto accade per il modello relazione in cui esistono tabelle, colonne e righe, nel modello graph-oriented le primitive sono: nodi, relazioni e proprietà. Frequentemente questi modelli offrono anche supporto alla gestione di dati semi-strutturati cosi come avviene per gli altri modelli descritti in questo paragrafo.

4. Column-family oriented. E' il modello ispirato dall'articolo di Google sul prodotto BigTable [bigt]. In questo modello i dati non vengono archiviati nella riga come avviene per il modello relazionale ma nella colonna. In particolare sono presenti i concetti di : column, column-family e super-column. La colonna è una tripla composta da un campo: nome, valore, timestamp. Le column-family sono dei raggruppamenti di colonne e hanno la particolarità che tutte le colonne appartenenti alla stessa column-family vengono archiviate fisicamente nello stesso file. Le super-column sono delle colonne che possono contenere altre colonne.

Definiti i diversi data model, passando al secondo punto riguardo i diversi approcci di archiviazione e gestione fisica dei dati (data persistence) nei sistemi schemaless possiamo distinguere :

1. Memory-based. Questi database conservano le informazioni esclusivamente nella memoria per aumentare al massimo le performance in fase di lettura dei dati. Tuttavia hanno come limite il fatto che le informazioni in essi contenente non può superare la dimensione della memoria fisica della macchina sui cui sono installati e inoltre non garantiscono in alcun modo il recupero dei dati nel caso in cui la macchina venga riavviata per problemi di alimentazione o per manutenzione. Per risolvere o limitare al massimo il problema della durabilità dei dati, alcune implementazioni, replicano le informazioni su più server in modo da diminuire la probabilità di power failure contemporanee.

2. Disk-based. Questi database conservano i dati soltanto nell'hard disk e non fanno uso di meccanismi di caching per aumentare le performance. Questo approccio non soffre dei problemi di durabilità dei database memory-based, ma offre peggiori performance in fase di lettura.

3. Combinazione di disk e memory based. Questo è l'approccio più usato in quanto combina la velocità di lettura propria del modello memory-based con la durabilità e l'affidabilità del modello disk-based. Questi database scrivono le informazioni in memoria e parallelamente aggiungono un record in un commit log in modalità append-only per garantire durabilità. Quando il numero di inserimenti o aggiornamenti nel database supera una certa soglia, i dati contenuti in memoria vengono ottimizzati e resi persistenti scrivendoli sul disco rigido. Offrono inoltre grandi prestazioni in lettura nel caso in cui le informazioni richieste dall'utente risiedano in memoria.

Il terzo punto, riguardo la scalabilità dei database, rappresenta sicuramente un fattore importante nella classificazione di sistemi di storage intrinsecamente distribuiti. In linee generali questi si possono distinguere in base al :

1. Supporto al teorema di CAP. Il teorema enunciato per la prima volta da Eric. A. Brewer, capo del reparto ricerca di Yahoo e professore di “Computer Science“ all'università di Berkeley, in una presentazione del 1998 [brewer] afferma che un sistema di dati condiviso è generalmente caratterizzato da tre proprietà: 1consistenza, 2disponibilità, tolleranza al partizionamento di rete3 (Consistency, Availability, tollerance to network Partitions). Il teorema afferma che si possono avere simultaneamente solo due di queste tre proprietà, sacrificando quindi la terza. Ad esempio possiamo avere :

Consistenza e Disponibilità: si tratta di sistemi localizzati che non risentono di partizionamento di rete, come un un database centralizzato o LDAP o un file system.
Consistenza e tolleranza al Partizionamento: sistemi distribuiti, con un elevato partizionamento di rete, in cui il valore della consistenza dei dati è di primaria importanza, a scapito della eventuale elevata latenza e bassa disponibilità (dovuta a politiche di locking pessimistiche).

Disponibilità e tolleranza al Partizionamento: la disponibilità è il valore principale per questo genere di sistemi. Per questo utilizzano protocolli più ottimistici e un approccio best-effort. Un esempio classico sono i DNS.
Molti sistemi di storage appartenenti alla categoria dei database schemaless, caratterizzati da architetture altamente scalabili e distribuite, hanno come obiettivo le prestazioni e l'alta disponibilità trovandosi quindi nella terza delle situazioni citate. Queste soluzioni usano un approccio BASE (Basic Available, Soft-state, Eventual consistency) piuttosto che l'approccio ACID (Atomicity, Consistency, Isolation, Durability) proprio dei database relazionali. Nel campo dei database schemaless questo approccio alla scalabilità e distribuzione dei dati spinto verso la disponibilità ha come capostipite il database di Amazon Dynamo [taxo] che come detto accetta il principio dell'Eventual Consistency e che ha come risultato positivo che il sistema è sempre pronto alla scrittura e non presenta mai periodi di lock.

Oltre a questo approccio orientato alla disponibilità, alcuni sistemi presentano invece un'architettura orientata verso la garanzia della consistenza tipico dei database relazionali. E' questo il caso dei sistemi basati o ispirati dal prodotto Google BigTable, il cui modello tenta di tenere sincronizzati i vari nodi di cui è composto il sistema posizionandosi quindi nella classe Consistenza e tolleranza al partizionamento di rete.

2. Supporto ai Multi Data Center. In alcune soluzioni [multcen] il partizionamento dei dati può avvenire in modo che i dati vengano replicati su server appartenenti a data center differenti distanti geograficamente gli uni dagli altri. Questo risultato è più facile da realizzare per sistemi di storage che adottano una soluzione Eventual Consistency.

3. Supporto all'aggiunta dinamica di server. Alcune soluzioni di storage consentono l'aggiunta dinamica in modalità live di server al cluster in maniera trasparente all'applicazione e all'utente finale che utilizza il programma.

Definiti i diversi data model dei database schemaless e i differenti approcci di gestione fisica
dei dati e di scalabilità, rimane da classificare le diverse interfacce di accesso ai dati e come queste possono essere usate dagli utenti o dai programmatori per recuperare le informazioni in essi contenute. Di seguito possiamo elencare le più comuni modalità di accesso ai dati usate nel contesto dei database schemaless :

1. REST. REST è l’acronimo di Representational Transfer State, ed è un paradigma per la realizzazione di applicazioni Web che permette la manipolazione delle risorse per mezzo dei metodi GET, POST, PUT e DELETE del protocollo HTTP. I database che espongono questo tipo di interfaccia possono essere gestiti remotamente o in locale usando un comune browser oppure mediante le API che ogni linguaggio di programmazione mette a disposizione per effettuare semplici chiamate HTTP.

2. Thrift [thrift]. E' un framework di chiamate a procedure remote implementato inizialmente da Facebook e successivamente ceduto ad Apache. Tramite questo adattatore è possibile interfacciarsi a software implementati in linguaggi di programmazione differenti tra i quali : Java, C++, C#, Ruby, Php, ecc.. Molti database schemaless adottano questo approccio per essere indipendenti dal linguaggio di programmazione adottato dallo sviluppatore.

3. MapReduce. MapReduce [mapred] è un modello di programmazione distribuita per l'analisi di grandi quantità di dati introdotto da Google. MapReduce consiste in due task : il nodo che esegue il processo map prende in input dati sotto forma di coppie chiave/valore ed estrae da essi una porzione generando altre coppie di dati chiave/valore. Facendo ciò il processo map scompone i dati e quindi il problema principale in sotto problemi relativamente ai nuovi valori generati. Successivamente il processo reduce riunifica tutti i dati generati dai processi map e calcola il risultato finale oggetto dell'analisi. MapReduce aggiunge ai database schemaless, progettati e ottimizzati per gestire dati non strutturati o semi-strutturati, la possibilità di filtrare, organizzare e reportizzare i dati. Con questa tecnologia, infatti, è possibile creare una vista strutturata parallela rispetto al database intrinsecamente destrutturato, similmente a quanto accade nei database relazionali con l'uso delle viste. Bisogna notare tuttavia che le viste prodotte da MapReduce sono persistenti e vengono salvate nel filesystem diversamente dalle viste dei database relazionali che quasi sempre rappresentano una visione dei dati temporanea e non autoconsistente.

4. Language Specific API. Alcune implementazioni non adottano tecnologie standard e hanno implementano connettori specifici per l'interfacciamento con l'esterno o con software di terze parti.

Document Management System

Il document management system (DMS) è un sistema software, composto in generale da uno o più applicativi, usato per archiviare e gestire documenti elettronici di varia natura, quali : scansioni di documenti cartacei, immagini, musica, video e più in generale qualsiasi elemento che può essere rappresentato e digitalizzato sotto forma di file. Nato nel 1980 quando alcuni vendor svilupparono alcuni sistemi per gestire la memorizzazione di documenti, fornisce tutte quelle funzionalità fondamentali per gestire l'archiviazione, la manipolazione, la pubblicazione e la ricerca dei documenti. Spesso il termine document management system viene usato come sinonimo di Content Management System (CMS) anche se quest'ultimo abbraccia una classe di soluzioni più ampia che comprendono : Web Content Management System (WCMS) , Enterprice Content Management System, Mobile Content Management System, Component content management system, Media content management system e Learning Content Management System (LMS). Il DMS può essere visto come un componente di un Enterprice Content Management System ed è spesso relazionato a soluzioni di Digital Asset Management, Document Imaging, Workflow System e Record Management System.
Un document management system di solito fornisce le seguenti funzionalità :

1. Archiviazione. L'archiviazione permette di conservare un documento all'interno del DMS. Nei DMS tipicamente l'archiviazione dei dati binari avviene su filesystem o all'interno del database. In questo contesto risulta importante inoltre decidere il tempo di validità e permanenza di un documento all'interno del sistema e il supporto a funzionalità di data destruction e data migration dei documenti da un repository ad un altro.

2. Classificazione dei contenuti. I documenti caricati nel repository vengono sempre archiviati secondo una determinata tassonomia che consente di classificare i dati in base a diversi fattori. In generale, la classificazione gerarchica dei contenuti, cosi come avviene per il filesystem del sistema operativo, permette di tenere ordinato il repository e di conservare in cartelle contenuti logicamente correlati tra loro. Alcuni DMS, oltre al concetto di tassonomia classico, in cui ogni elemento è presente in una sola cartella o contenitore padre, introducono il concetto di faceted classification permettono la classificazione multipla di documenti. In questo modo ogni contenuto può essere logicamente presente in più cartelle.

3. Custom Type. Viene quasi sempre data la possibilità di creare all'interno del repository differenti classi o tipologie di documenti(es. fattura, ddt, ordine, contratto, ecc. ). Ogni tipo di documento(custom type) può essere creato dinamicamente durante l'esecuzione del programma dagli utenti accreditati ed è composto da matadati che lo arricchiscono e completano con informazioni supplementari.

4. Supporto ai Metadati. Quasi tutti i documenti conservati in un DMS hanno dei metadati associati. I metadati rappresentato delle informazioni supplementari oltre al contenuto binario vero e proprio che rappresenta quindi il documento. Queste informazioni supplementari sono ad esempio la data di inserimento del documento nel gestore documentale, il numero univoco di una fattura, il nominativo del destinatario di un contratto o l'intestatario e la data di scadenza di una offerta. In generale un DMS deve permettere l'inserimento manuale dei metadati da parte dell'utente finale oppure può prevedere un processo di estrazione automatico degli stessi direttamente dal contenuto del documento. E' questo il caso che può essere applicato in documenti archiviati nel DMS che sono rappresentati in formato testuale intellegibile o per cui esiste una particolare algoritmo di estrazione delle informazioni. Molti DMS, inoltre, consentono l'inserimento di metadati a runtime ad opera degli utenti finali o utenti con privilegi di amministrazione. Quest'ultima funzionalità permette di modificare i metadati e quindi la struttura del documento senza che venga fermato l'applicativo, senza che sia necessario l'intervento di programmatori, DBA o personale con skill particolari. Alcuni DMS, inoltre, tra cui sicuramente coloro che rispettano lo standard JSR 170 e JSR 283, offrono funzionalità proprie della programmazione orientata agli aspetti permettendo l'aggiunta dinamica di metadati a particolari istanze di documento senza che queste modifiche vengano propagate a tutti i documenti che appartengono allo stesso tipo.

5. Versioning dei contenuti. Il versioning è il processo di conservazione delle varie versioni dei documenti archiviati nel gestore documentale. In questo modo un utente del sistema può recuperare versioni precedenti di un determinato documento e confrontarlo con quelli più recenti.

6. Indexing. Dai documenti archiviati nel repository vengono estratte le parole dal testo e costruiti degli indici che permettono la ricerca di documenti in modalità full-text. E' infatti impiegato in tutti i contesti in cui è necessario avere performance elevate con bassi tempi di risposta in fase di ricerca.

7. Ricerca dei dati. Si tratta di una funzionalità presente in tutti i DMS che permette di cercare documenti all'interno del repository. La ricerca può essere semplice se ad esempio si recupera un documento in base ad un identificativo univoco che lo contraddistingue oppure più complessa se si utilizzano filtri aggiuntivi. E' questo il caso in cui la ricerca di un documento avviene specificando termini presenti nel documento stesso oppure nei metadati ad esso collegati. Generalmente il DMS risponde alle richieste ritornando una lista di documenti che soddisfano i termini di ricerca. Nella maggior parte dei DMS viene inoltre supportata la modalità di ricerca full-text, possibile grazie al processo di indicizzazione a cui viene sottoposto ogni documento archiviato nel gestore documentale.

8. Relazioni tra documenti (Peer association). Spesso esistono delle particolari relazioni di associazione tra documenti in quanto due o più documenti sono legati logicamente tra loro. Molti DMS supportano questa funzionalità che viene chiamata peer association (associazione tra pari) per distinguerla dalla parent-child association (associazione padre-figlio) con cui viene definita la classificazione di documenti in una struttura a cartelle.

9. Sicurezza. La gestione della sicurezza è un argomento importante nel document management anche se i requisiti di protezione possono variare da caso in caso in base alla tipologia di documenti gestiti e all'importanza delle informazioni in essi contenuta. In generale alcuni DMS hanno dei moduli applicativi che permettono agli amministratori di regolare l'accesso ai documenti soltanto a determinati utenti o gruppi di utenti.

10. Integrazione con altri software. Molti DMS si integrano direttamente con software di terze parti, quali strumenti di office automation, client mail e software di collaborazione, che permettono agli utenti di recuperare direttamente i documenti dal gestore documentale, apportare loro delle modifiche e salvare i cambiamenti aggiornano il repository. Integrazione avviene inoltre supportando protocolli quali : LDAP, WebDAV, CIFS, CMIS, SOAP, REST, ecc.

11. Capture. Le funzionalità di capture tipicamente supportate dai DMS di grande dimensioni permettono l'interfacciamento con scanner o stampanti multifunzione. Funzionalità di Optical Character recognition (OCR), spesso, sono spesso usate attraverso software standalone o hardware dedicato per convertire immagini in testo intellegibile. Alcuni software inoltre sfruttano l'OCR per estrarre informazioni dal documento che vengono poi utilizzate per effettuare ricerche full-text o per popolare direttamente i valori dei metadati. Alcune volte inoltre è possibile usare tecniche di Optical mark recognition (OMR) per estrarre informazioni su segni e scelte effettuate dagli utenti nella compilazione ad esempio di test e questionari a risposta multipla.

12. Distribuzione dei contenuti. Un documento che deve essere distribuito deve essere realizzato secondo un formato che non può essere alterato facilmente. In generale la copia originale modificabile del documento viene archiviata nel gestore documentale mentre vengono distribuite copie dell'originale in formato sola lettura.

13. Workflow. Alcuni DMS hanno dei moduli applicativi che consentono una gestione integrata dei workflow.

14. Pubblicazione dei dati. La pubblicazione di un documento è un processo complesso che può richiedere un fase di validazione o approvazione anche lunga. In determinati contesti in cui il DMS è integrato con software di web content management system (WCMS) la pubblicazione di contenuti può essere resa più semplice e veloce in quanto l'approvazione di un documento porta automaticamente lo stesso ad essere pubblicato nel portale internet o intranet aziendale.