Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Basi Di Dati
Sistemi per la gestione di Big Data
Anno Accademico 2013/2014
Candidato:
Arcangelo Di Palo
matr. N46/000534
Indice
Indice..................................................................................................................................................III
Capitolo 1: Introduzione.........................................................................................................................
1.1 Definizione...................................................................................................................................
1.2 BigData Software.........................................................................................................................
1.2.1 Tecnologie.............................................................................................................................
1.2.1.1 Analytic RDBMS...........................................................................................................
1.2.1.2 noSQL Systems..............................................................................................................
1.3 Usi dei BigData............................................................................................................................
1.4 Situazione Italiana........................................................................................................................
Capitolo 2: SAP HANA
2.1 Architettura...................................................................................................................................
2.1.1 Scalabilità..............................................................................................................................
2.2 Software........................................................................................................................................
2.2.1 Oltre SQL..............................................................................................................................
2.3 Come Lavora HANA....................................................................................................................
2.4 Costi..............................................................................................................................................
Capitolo 3: MapReduce
3.1 Funzioni Map e Reduce................................................................................................................
3.2 Implementazione..........................................................................................................................
3.2.1 Gestione dei fallimenti..........................................................................................................
3.2.2 Parallelizzazione dei Calcoli.................................................................................................
3.2.3 Distribuzione del Carico........................................................................................................
Capitolo 4: BigTable
4.1 Introduzione..................................................................................................................................
4.2 Caratteristiche Principali..............................................................................................................
4.2.1 DataModel.............................................................................................................................
4.2.2 Formato dei File....................................................................................................................
4.2.3 Servizio Distribuito...............................................................................................................
4.3 Applicazioni Reali........................................................................................................................
4.3.1 Google Analytics...................................................................................................................
4.3.2 Google Earth..........................................................................................................................
4.3.3 Ricerca personalizzata...........................................................................................................
Bibliografia.............................................................................................................................................
Capitolo 1: Introduzione
Big Data è un termine per definire una collezione di dati così ampia e complessa da essere
difficilmente processabile con database o applicazioni tradizionali e dalla maggior parte
dei RDBMS, richiedono invece calcoli paralleli di software che girano su decine, centinaia
o migliaia di sever.
Lo sviluppo della tecnologia ha portato un incremento delle risorse di gestione intensiva di
dati: ci sono 4.6 miliardi di cellulari in tutto il mondo e circa 2 miliardi di persone che
possono accedere ad internet.
La capacità effettiva mondiale di scambiare informazioni attraverso le reti di
telecomunicazione è quasi raddoppiata ogni 40 mesi dal 1989:
• 281 PB nel 1986
• 471 PB nel 1993
• 2.2 EB nel 200
• 65 EB nel 2007
• 2,5 EB al giorno nel 2012
e si prevede un ulteriore aumento del traffico causato dal massiccio uso di internet che nel
2014 porterà alla cifra di 667 EB annui.
E’ stimato che un terzo delle informazioni memorizzate globalmente è in forma di
immagine o testi alfanumerici, che sono i formati più usati per molti dei Big Data
application.
D’altra parte questo dimostra il potenziale dei dati inutilizzati come video e audio.
1.1 Definizione
La definizione di Big Data non è stata ancora sufficientemente articolata nonostante la
notorietà di questi ultimi in quanto non si possono racchiudere in un tipo specifico di dato
ma hanno forme e dimensioni diverse, vengono infatti denominati dati multi-strutturati.
4
Possiamo cominciare generalizzando dicendo che sono dati la cui dimensione è superiore
all’abilità dei comuni software (in generale Basi di Dati Relazionali) di catturare, gestire e
processare i dati in tollerabili tempi di attesa. La prima definizione data è però abbastanza
variabile anche perchè i software diventano sempre più potenti e le moli di dati sempre più
esigue per le generazini tecnologiche successive.
Dal punto di vista delle dimensioni possiamo definire un Big Data come un set di dati di
dimensioni variabili dalle poche dozzine di terabytes a molti petabytes.
Una definizione più completa potrebbe essere: “i Big Data sono un grande volume non
strutturato di dati che non possono essere gestiti da database come DBMS, RDBMS o
ORDBMS”.
La descrizione più diffusa di Big Data si riferisce ad un modello 3Vs, ovvero si
descrivono i Big Data come insiemi di dati che necessitano di: Volume, Velocità, Varietà.
- Volume: si riferisce alle dimensioni del set di dati da memorizzare e analizzare
- Velocità: capacità di effettuare analisi dei dati in tempo reale o quasi, o comunque in
tempi accettabili
- Varietà: fa riferimento alle varie tipologie di dati provenienti da fonti diverse:
strutturate e non (testi, conversazioni via mail o chat). Dispositivi di ogni tipo generano
continuamente dati (pagine web, file di weblog, forum, social-media, audio, video, e-mail,
documenti, siestemi di sensori) e la maggior parte di questi dati sono di tipo “semistrutturato” mentre le basi di dati classiche, ad esempio relazionali, lavorano con schemi
ben definiti e formati. Quindi la varietà di dati da raccogliere rappresenta un cambiamento
fondamentale per la memorizzazione e l’analisi.
Alcune organizzazioni aggiungono una quarta V per Veridicità
- Veridicità: qualità dei dati intesa come valore informativo che si riesce ad estrarre (se
ho tanti dati e a final non si capisce che significano è inutile) tale parametro è quindi
fondamentale affinchè i dati possano davvero alimentare nuove conoscenze.
5
1.2 Big Data Software
I Big Data hanno aumentato la domanda di specialisti nella gestione delle informazioni e
aziende come Oracle, IBM, Microsoft, SAP, HP e Dell spendono miliardi in software
specializzati unicamente nella gestione e nell’analisi dei dati.
Nel 2010 tale settore valeva più di 100 miliardi di dollari ed è cresciuto quasi del 10%
annuo: circa il doppio di tutto il mercato software complessivo.
Nonostante tale crescita, ad oggi sono poche le aziende che davvero hanno necessità di
gestire tali moli di dati, così come ancora pochi sono i software, e più in generale i sistemi,
che possono processarli. Di seguito vediamo i principali programmi:
• SAP HANA
• Apache Hadoop
• Google MapReduce
• Oracle Exalytics
Ma non solo aziende rivolte all’informatica si occupano di tali ricerche, ad esempio un
programma della DARPA, l’agenzia del dipartimento della difesa statunitense incaricato
di ricerca avanzata, si occupa di Topological Data Analysis, una nuova area di studi
orientata a creare applicazione in aree come Data Mining, ovvero estrarre il sapere da
grandi quantità di dati e nel 2008 la tecnologia è divenuta pubblica con il lancio della
compagnia chiamata Ayasdi.
1.2.1 Tecnologie
I Big Data richiedono tecnologie d’eccezione per processare efficacemente grandi quantità
di dati in tempi tollerabili. Le componenti generiche sono:
• Analytic RDBMS: i normali database relazionali ottimizzati per compiti analitici
• noSQL systems: ovvero sistemi non relazionali per l’elaborazione di dati multistrutturati
6
1.2.1.1 Analytic RDBMS
Sono soluzioni integrate per gestire dati e generare analisi con un miglior rapporto
prezzo/performance, gestione e amministratione rispetto a quanto offerto da RDBMS
generalisti. L’ottimizzazione delle prestazioni è garantita dall’utilizzo massivo di
elaborazione parallela, superiore qualità della struttura dei dati e tecniche di compressione.
Abbiamo inoltre due suddivisioni:
• Packaged hardware and softwre appliances: è un sistema integrato costruito da zero
per fornire un buon rapporto prezzo/prestazioni per carichi di lavoro analitici.
• Software Only: è un insieme di compotenti software per la gestione di carichi di
lavoro analitici. Fanno spesso uso di sottostanti software open source e sono
progettati per la distribuzione di hardware a basso costo. Il compromesso per la
portabilità hardware è l’incapacità del prodotto di sfruttare al massimo un hardware
specifico.
Lo sviluppo di prodotti Adbms da parte di piccole aziende innovative ha fatto sì che le
aziende tradizionali si impegnassero nel migliorare la capacità di elaborazione analitica
delle loro offerte DBMS. Ciò ha portato a miglioramenti e nuove funzionalità nei prodotti
Rdbms esistenti così come a una politica di acquisizioni. EMC, per esempio, ha acquisito
Greenplum, HP Vertica, IBM Netezza, Microsoft Datallegro, Teradata Aster Data.
1.2.1.2 noSQL Systems
Non esiste un singolo modello di database in grado di soddisfare tutte le esigenze. Ecco
perché molti clienti hanno sviluppato proprie soluzioni non relazionali. Web company
come Google e Yahoo sono esempi di organizzazioni che hanno costruito soluzioni
personalizzate e alcune di queste sono state offerte in public domain in modo da poter
essere disponibili in modalità open software. Vedremo nello specifico HANA della SAP
nel capitolo 2 e MapReduce di Google nel capitolo 3.
7
1.3 Usi dei Big Data
Ovviamente lo scopo principale non è memorizzare i dati ma analizzarli e ricavare
informazioni utili.Vediamo alcuni dei campi in cui sono effettivamente usati i BD:
• Scienza e Ricerca
• Astronomia: il telescopio Sloan Digital Sky Survey (attivo dal 2000) ha
immagazzinato più dati nella sua prima settimana di lavoro di tutta la
collezione di dati nella storia dell’astronomia. Al giorno d’oggi ha
ammassato 140 Terabytes di dati (200 GB a notte) e il suo successore (sarà
attivo dal 2016) il Large Synoptic Survey Telescope acquisirà 140 TB ogni
5 giorni
• Biologia: la decodifica del genoma umano originariamente impiegava 10
anni di elaborazione, ora può essere realizzata in meno di una settimana
• Meteorologia: l’NCCS, il centro di controllo meteorologico della NASA,
immagazzina 32 PB di osservazioni climatiche e simulazioni sul proprio
cluster DIscover.
• Fisica: il Large Hadron Collider ha 150 milioni di sensori che catturano dati
40 milioni di volte al secondo. Considerando che ogni secondo avvengono
600 milioni di collisioni e che solo lo 0,001% dei sensori vengono attivati
lo stream di dati ammonta a 25 PB annui. Se tutti i sensori registrassero dei
dati tale insieme sarebbe troppo elevato da processare, potrebbe eccedere i
150 milioni di PB annui.
• Governo:
• Il Governo Federale degli Stati Uniti ha sei dei dieci supercomputer più
potenti del mondo
• la United States National Security Agency sta costruendo lo Utah Data
Center. Quando sarà finito la NSA sarà in grado di gestire un grande
quantitativo di informazioni ricevute da internet. Le dimensioni effettive
sono sconosciute ma recenti voci di corriodio parlano dell’ordine degli
Exabytes.
8
• Settore privato
• eBay.com: usa due data warehouses di 7,5 PT e 40 PT oltre ad un cluster
Hadoop per la ricerca e i sistemi di raccomandazione al consumatore.
• Amazon.com: processa milioni di operazioni ogni giorno oltre a mezzo
milione di richieste provenienti da venditori di terze parti. Amazon possiede
i tre più grandi Linux-based database del mondo (7.8, 18.5 e 24.7 TB)
• Facebook: tratta 50 miliardi di foto dai suoi utenti, per non parlare dei dati
individuali.
• Windermere Real Estate: utilizza segnali GPS anonimi vicini da 100
milioni di giudatori per aiutare i nuovi acquirenti di case a determinare i
tempi tipici di giuda per arrivare a lavoro durante le varie ore del giorno
• UPS: tiene traccia di 16,3 milioni di pacchi al giorno per 8,8 milioni di
clienti con una media di 39,5 milioni di richieste di tracciamento al giorno.
Vanno anche considerati i sensori nei 46000 veicoli (velocità, direzione,
soste) che rendono possibile realizzare una mappa on-line e eventualmente
la riconfigurazione del percorso in tempo reale . La compagnia memorizza
pià di 16 PB di dati.
1.4 Situazione Italiana
In Italia è quasi impossibile trovare aziende che necessitano di immagazzinare dimensioni
enormi di dati (la differenza tra Big Data e Data Mining è proprio dell’ordine di grandezza
di gran lunga superiore dei BD) e anche nel mondo sono poche le aziende che necessitano
di tali dimensioni.
Vediamo alcuni esempi italiani:
• Twitter: considerando i casi in cui è stato più usato erano attivi 3,5 milioni di
italiani (campagna elettorale) e durante il Festival di Sanremo si sono vrificati 150
mila tweet durante la sola finale; un volume che può essere racchiuso in 77MB,
senza compressioni, caricato su strumenti personali (Excel), e analizzato per
correlazione senza ricorrere ai big data.
9
• Banche: in Italia ci sono 30 milioni di conti correnti bancari e 8 milioni di conti
correnti postali. Considerando 20 operazioni al mese otteniamo 600 operazioni
totali mensili. In un anno potremmo valutarne 7 miliardi. E’ un numero elevato ma
gestibile tranquillamete dalle basi di dati comuni e server aziendali. Il volume
complessivo è di alcuni TB
D’altronde le società che impiegano stumenti che possono inquadrarsi come Big Data
sono poche: Facebook,Twitter, Amazon, Microsoft, Google.
In Italia, spesso, l’etichetta “Big Data” viene associata ad operazioni più tradizionali ma
comunque altrettanto efficaci quali Business Intelligence e Data Mining.
Nei fatti, molte delle tecniche di data mining sono oggi associate a volumi di dati sempre
maggiori, magari ottenuti da struenti di big data, anche se a oggi le analisi sono effettuate
in momenti e tecnologie differenti.
10
Capitolo 2: SAP HANA
SAP (“Systeme, Anwendungen, Produkte in der datenverarbeitung” ovvero Sistemi,
Applicazioni e Prodotti nell’elaborazione dati) è una multinazionale tedesca per la
produzione di software fondata nel 1972.
HANA è l’acronimo per “High-Performance ANalytic Appliance”, è uno strumento
computazionale creato per supportare analisi real-time e pocessi transazionali, creato
partendo da tecnologie sviluppate o acquisite (la maggior parte sono tecnologie inmemory).
Nel 2008 un team della SAP, in collaborazione con Hasso Plattner Institute (Istituto
universitario fondato da Hasso Plattner, co-fondatore di SAP) e la Stanford university,
mostrò un’architettura per l’analisi e l’aggregazione di dati in real-time denominata
“Hasso’s New Architecture”. Prima che fosse introdotto il termine HANA ci si riferiva a
tale prodotto con il termine “Nuovo Datbase”
Nel 2010 fu ufficialmente annunciato SAP HANA 1.0, un’applicazione in-memory per
business application e business intelligence che permettesse risposte real-time.
Aggiornamenti successivi hanno migliorato il supporto alle aziende con SAP NetWwaver
Business Warehouse (2011) e promosso l’aspetto del cloud computing con HANA One
distribuito sul sistema Amazon Web Services ad una tariffa oraria.
Le imprese raccolgono grandi quantità di dati strutturati tramite vari sistemi. La maggior
parte lotta per fare uso dei dati spendendo ingenti somme per archiviarli e proteggerli. Una
possibilità di fare uso di questi dati è quella di estrarre, trasformare e caricare sottoinsiemi
in un data warehouse aziendale tradizionale per l'analisi. Questo processo richiede tempo e
richiede importanti investimenti in hardware proprietario correlato. Il risultato è spesso un
costoso, gonfio External Data Warehouse che fornisce poco più che vedute retrospettive di
dati aziendali.
11
SAP HANA offre alle aziende un nuovo approccio per sfruttare il valore di tutti i dati
aziendali, dove per “tutti” si intende dati strutturati e non strutturati. Come accennato in
precedenza, HANA gira su hardware commodity poco costoso da uno qualsiasi dei diversi
partner SAP, Le sue capacità di replica dei dati e integrazione accelerano notevolmente il
processo di caricamento dei dati nel database. Utilizzando, inoltre, l'archiviazione in
memoria, le applicazioni HANA possono accedere ai dati in tempo quasi reale, cioè gli
utenti finali possono ottenere una visione importante dei dati mentre c'è ancora tempo per
agire. HANA può anche eseguire analisi predittiva per aiutare le organizzazioni a
pianificare futuri sviluppi del mercato.
Le imprese sono sempre più esigenti in quanto capacità di elaborazione transazionali e
analisi in real-time dalle applicazioni. HANA mette SAP in una buona posizione per
fornire tale funzionalità per il suo cliente-base delle imprese tradizionali. Ma il punto
debole della politica SAP è che deve bilanciare l'innovazione con il supporto continuo per
le sue legacy e altre applicazioni aziendali che formano la spina dorsale di molti ambienti
IT enterprise. Quindi, se da un lato si cerca continuamente di migliorare le tecnologie per
un’analisi sempre più veloce e precisa dei dati dall’altro l’evoluzione è frenata da vecchi
sistemi vitali per un’azienda.
2.1 Architettura
HANA è fondamentalmente un DBMS costruito su un hardware moderno (soprattutto
grandi quantità di memoria principale, cpu multi-core, storage ssd) classificato come: inmemory, column-oriented, relational. E’ compatibile con le proprietà ACID e supporta
standard come SQL, espressioni multidimensionali e strutture noSQL.
Analizziamo nel dettaglio le caratteristiche di HANA:
In-memory (IMDB): si intende un DBMS che gestisce i dati nella memoria
centrale, in contrasto con i DBMS comuni che gestiscono i dati su memoria di
massa (principalmente dischi rigidi). L’ovvie conseguenza della gestione in
memoria centrale è che i processi sono di gran lunga più veloci ma possono gestire
12
moli di dati inferiori, il che porta a dover mantenere informazioni su un disco fisso
in caso di perdita di dati (si usano file di Log e Checkpoint)
Column-oriented: definiamo così un DBMS che memorizza i dati in tabelle
sottoforma di colonne anzichè righe (la maggior parte dei DBMS sono orientati
alle righe). Ciò porta vantaggi nelle data warehouse e altri sistemi ah hoc in cui gli
aggregati sono calcolati su un grande numero di dati simili tra loro.
Relational database management system: sono i RDBMS basati sul sistema
relazionale.
Il cuore di HANA è il SAP In-Memory Database 1.0, un MPP (Massive ParallelProcessing) data sotre che fonde tecniche di memorizzazione row-based, column-based e
object-based. Monta il sistema operativo SUSE Linux Enterprise Server 11 SP1.
Di seguito è riporata un’immagine dell’architettura di SAP HANA. Descriveremo i singoli
componenti per una visione più dettagliata.
13
• Connection e Session Management: la componente Connection e Session
Management crea e gestisce le sessioni e connesisoni per i clienti di database. Una
volta che una sessione è stata stabilita, il cliente di database pososno utilizzare
SQL, script SQL (o altri linquaggi specifici del dominio come FOX, linguaggio
proprietario di SAP per applicazioni di pianificazione), per comunicare con il
database HANA
• Transaction Manager: per quanto riguarda le proprietà ACID il Transaction
Manager coordina le transazioni di database, controlla l’isolamento transazionale, e
tiene traccia di transaizoni in corso e concluse. Per il controllo della concorrenza, il
database SAP HANA implementa il classico MVCC
• Calculation Engine: script SQL e linguaggi specifici di dominio sono tradotti dai
loro compilatori specifici in una rappresentazione interna ciamata “modello di
calcolo”. L’esecuzione di questi modelli di calolo è effettuata da il Motore di
Calcolo. L’uso di modelli di calcolo facilita la combinaizione di dati memorizzati
in differenti In-Memory Storage Engines, nonchè la semplice implementazioni di
specifiche applicazioni nel database engine.
• Optimize and Plan Generator: Le richieste del cliente vengono analizzate e
ottimizzate in tale livello. Sulla base del piano di esecuzione ottimizzato, il motore
di esecuzione richiama i diversi Motori di Elaborazione In-Memory e i percorsi dei
risultati
intermedi
tra
fasi
di
esecuzioni
consecutive.
Una ottimizzazione, per esempio, potrebbe essere la traduzione di strutture non
riconosciute (vedi la parte del Calculation Engine) in strutture note per i linguaggi
usati da HANA.
14
• Authorization Manager: l’Authorization Manager viene richiamato da altri
componenti del database HANA per verificare se un utente ha i privilegi necessari
per eseguire le operazioni richieste. Un privilegio concede il diritto di eseguire
un’operazione specifica (ad esempio, creare, aggiornare, selezionare, o eseguire). Il
database supporta anche i privilegi di analisi che rappresentano filtri o limitaizoni
per le query analitiche e controllare l’accesso ai valori con una certa combinazione
di atributi dimensionali. Gli utenti sono o autenticati dal database stesso, o
l’autenticazione è delegata a un providere di autenticazione esterno, come ad
esempio una directory LDAP
• Metadata Manager: i Metadati sono utilizzati nel database HANA come
definizione di tabella, views, indici e le definizioni di funzioni script SQL. Tali
metadati sono gestiti dal Metadata Manager. Possono essere di tipi diversi e sono
memorizzati in un catalogo comune per tutti i motori di storage sottostanti.
• In-Memory Storage Engine: il centro della figura 2 mostra i tre In-Memory Storage
Engine di HANA, vale a dire, il Relational Engine, il Graph Engine, e il Text
Engine.
• Relational Engine: il Relational Engine supporta sia la rappresentazione
fisica orientata alle righe che alle colonne. Un amministratore di sistema
specifica a tempo di definizione se una nuova tabella deve essere
memorizzata in un formato orientato alle righe o alle colonne. Le tabelle
orientate alle righe e alle colonne possono essere facilmente combinate in
un unico SQL, e, successivametne spostate da una rappresentazione
all’altra. Come regola, l’utente e i dati delle applicazioni sono memorizzati
in un formato orientato alle colonne per beneficiare dell’alto tasso di
compressione e per l’accesso altamente ottimizzato per query di selezione e
aggregazione. Metadati e dati con pochissimi accessi vengono memorizzati
in formato orientato alle righe.
• Graph Engine: il Graph Engine supporta la rappresentazione ed
elaboraizone efficiente di grafi con un sistema flessibile. Una nuova
15
struttura di archiviazione dedicata e un insieme di operazioni di base
ottimizzate vengono introdotte per consentire le operazioni con i grafi in
modo
efficiente
tramite
il
dominio
WIPE
di
interrogazione
e
manipolaizone. Il Motore dei Grafi è posizionato per supportare in maniera
ottimale le applicazioni di pianificazione delle risorse, con un gran numero
di singole funzioni e complesse mash-up interdipendenti. Il tipo flessibile di
sistema
supporta
inoltre
l’esecuzione
efficiente
di
processi
di
trasformazione, come pulizia dei dati in scenari data-warehouse, regolare i
tipi delle singole voci dei dati, e consente l’integrazione ad hoc di dati
provenienti da fonti diverse.
• Text Engine: il Text Engine offre l’indicizzazione di testo e funzionalità di
ricerca, come la ricerca di esatte parole e frasi, ricerca fuzzy (che tollera
errori di battitura), e la ricerca linguistica (che trova variazioni di parole
basandosi sulle regole linguistiche). In aggiunta, i risultati della reicerca
possono essere classificati e la capacità di ricerca può essere estesa
attraverso più tabelle. Questa funzionalità è disponibile per le applicaizoni
tramite estensioni SQL specifiche. Per l’analisi del testo, viene utilizzato un
Preprocessor Server che sfrutta la SAP’s Text Analysis Library.
• Persistence Layer: il Persistency Layer, illustrato nella parte inferiore della Figura
2, è responsabile della durabilità (durability) e atomicità delle transazioni. gestisce
volummi di dati e di log sul disco e fornisce interfacce per la scrittura e la lettura
dei
dati
che
sono
influenzati
da
tutti
i
mototi
di
storage.
Il Persistency Layer assicura che il database venga ripristinato al più recente stato
affidabile dopo un riavvio e che le operazioni siano eseguite completamente o
completamente annullate. Per raggiungere questo obiettivo in modo efficiente,
utilizza una combinazione di write-ahead logs, shadow paging e punti di
salvataggio.
2.1.1 Scalabilità
16
Per consentire la scalabilità in termini di volumi di dati e numero di richieste di
applicazioni, il SAP HANA database supporta scale-up e scale-out.
Scale-up: tutti gli algoritmi e le strutture dati sono progettati per lavorare su grandi
architetture multi-core.
Scale-out: il database è progettato per funzionare su un cluster di macchine singole che
consentono la distribuione dei dati e di elaborazione di query su più nodi.
2.2 Software
SAP ha sviluppato varie applicazioni analitiche specificamente per sfruttare le funzionalità
in tempo reale offerta da HANA, tra cui SAP Smart Meter Analytics e SAP CO-PA
Accelerator. Sono in fase di sviluppo altri software concentrati su analisi relative alla
vendita al dettaglio, applicazioni finanziarie, delle telecomunicazioni e altri settori quali la
gestione del capitale umano.
HANA comprende anche una componente di programmazione che consente al reparto IT
di un'azienda di creare ed eseguire programmi applicativi personalizzati nei livelli
superiori di HANA.
Poichè HANA può essere eseguito in parallelo ad una applicazione SAP ERP (sono
sistemi gestionali della SAP), gli analisti possono accedere ai dati operativi e transazionali
in tempo reale e non dover aspettare per un rapporto giornaliero o settimanale per
l'esecuzione.
La piattaforma fornisce librerie avanzate per predittività, pianificazione, elaborazione testi,
spaziale e business analytics. Il tutto è integrato sulla stessa architettura in modo da
semplificare ulteriormente lo sviluppo di applicazioni e di elaborazione tra fonti Big Data
e strutturate.
Le analisi possibili sono molteplici, ad esempio è possibile sottoporre una query e HANA
analizzerà contemporaneamente dati strutturati e non strutturati, transazionali e analitici
17
proveniente dalle più svariate fonti per offrire un responso in real time.
Oltre ad analisi passate, che sorvolando sulle dimenisoni sono possibili attraverso un
qualunque classico database, è possibile ricevere analisi predittive, spaziali e testuali
grazie ad una suite di Librerie appositametne studiate dall’azienda. Consideriamole in
dettaglio:
L'analisi predittiva offre nuove tendenze e nuovi modelli di cui non si era a conoscenza.
L'analisi spaziale consente di ricavare informazioni territoriali per facilitare processi
decisionali (es. rilevazioni gps). L'analisi testuale consente di sfruttare i dati non strutturati
memorizzati sottoforma di linguaggio naturale (es. mail ufficiali) ed estrarre entità utili
all'elaboraizone.
2.2.1 Oltre SQL
La grande differenza di HANA rispetto agli storage classici è la capacità di sfruttare le
conoscenze di oggetti di business complessi e di effettuare specifiche logiche di business,
tipiche della SAP, nel cuore del sistema, quindi andare oltre lo standard di descrizione del
linguaggio SQL.
Più in particolare, le caratteristiche “Beyond SQL” della SAP HANA si manifestano in
diversi modi:
Su piccola scala: estensioni specifiche di SQL consentono l’esposizione delle
capcacità dei motori di elaborazione delle query specifiche. Per esempio,
un’etensione nalla proposizione WHERE consente l’espressione di query di recerca
sfocata con il Text Engine. Un concetto esplicito supporta la programmazione di
processi e analisi “What if?”. Inoltre, SQL Sript fornisce un linguggio di
programmazione flessibile in cui coesistono espressioni imperative e funzionali. La
parte imperativa consente di descrivere facilmente i dati e la logica di controllo del
flusso (tramite DDL, DML, e SQL). Le espressioni funzionali, d’altra parte, sono
usate per esprimere logiche dichiarative per l’esecuzione efficace dei calcoli dataintensive. Inoltre è possibile eseguire tali espressioni in operazioni parallele.
18
Su grande scala: linguaggi specifici di dominio possono essere supportati da
specifici compilatori. Ad esempio MDX saranno nativamente tradotte in strutture
di query interne risolvendo il più possibile complesse espressioni dimensionali
durante lo step di compilazione consultando le strutture di oggetti business
memorizzati nel catalogo metadati. A differenza di una classica BI non è
necessario un OLAP supplementare per generare istruzioni SQL complesse. inoltre
il database SAP HANA può sfruttare direttametne la conoscenza dei modelli
OLAP che possiedono molta più semantica rispetto a strutture relazionali piane.
Oltre agli operatori sutudiati appositamente, HANA incorpora anche una Business
Function Library (BFL) che offre applicazioni specifiche per il codice SAP. Tutti i moduli
delle logiche di business sono integrati nel kernel del database con il massimo grado di
parallelismo.
Per riassumere, SAP HANA fornisce un interfaccia SQL classica includendo tutte le
proprietà transazionali richieste da un classico DBMS. In aggiunta si posiziona come un
sistema “Beyond SQL” fornendo un ecosistema di linguaggi specifici, con particolare
sostegno interno a livello di singoli operatori. Inoltre, il concetto di BFL, ovvero fornire
una serie di complesse funzioni per il business all’interno del Kernel (quindi
standardizzate e ottimizzate) crea chiari benrefici per SAP e applicazioni specifiche dei
clienti.
2.3 Come lavora HANA
SAP HANA è stato progettato per replicare e ingerire rapidamente dati strutturati
provenienti da database relazionali SAP e non-SAP, applicazioni e altri sistemi. Uno di tre
stili di replica dei dati (trigger-based, ETL-based o log-based) è usato a seconda del
sistema origine e caso d’uso desiderato. I dati replicati vengono quindi memorizzati nella
RAM anzichè caricati sul disco che è la forma tradizionale di memorizzazione dei dati.
Poichè i dati vengono archiviati in memoria è possibile accedervi in tempo quasi reale
19
dalle applicazioni analitiche e transazionali che si trovano nella parte superiore diHANA.
2.4 Costi
SAP non ha rilasciato pubblicamente informazioni sui prezzi specifici riguardanti HANA,
ma le prime stime indicano che i clienti possono inizialmente avere HANA installato e
funzionante per meno di $ 300.000, inclusi hardware, software e servizi. A seconda della
scala, livelli di prezzo possono raggiungere fino a $ 2 milioni o più.
HANA non è in grado di immagazzinare petabyte di dati. Tuttavia, grazie alle sue capacità
di compressione avanzate, le distribuzioni HANA sono in grado di memorizzare decine di
terabyte di dati o più, che è considerato un gran volume di dati nella maggior parte degli
ambienti dei clienti SAP in corso.
20
Capitolo 3: MapReduce/BigTable
Google è la nota azienda statunitense di servizi online, nata sulle solide basi del motore di
ricerca omonimo. Nel tempo ha creato diversi servizi come Gmail, Google Maps e tanti
altri, negli ultimi anni è attiva nel campo dei Sistemi Operativi grazie ad Android,
orientato principalmente ai cellulari.
Negli ultimi cinque anni, gli autori e tanti altri di Google hanno implementato centinaia di
elaborazioni special-purpose che elaborano grandi quantità di dati grezzi, quali documenti
scansionati, richieste di web log ecc. capaci di ricavare dati derivati, come, varie
rappresentazioni della struttura grafica dei documenti web, l’insieme delle query più
frequenti in un dato giorno ecc. La maggior parte di questi calcoli sono concettualmente
semplici. Tuttavia, i dati in ingresso sono di solito di grandi dimensioni e i calcoli devono
essere distribuiti su centinaia o migliaia di macchine in modo da finire in un ragionevole
lasso di tempo. I problemi di parallelizzazione dei calcoli, della distribuzione dei dati e
della gestione dei fallimenti rischiano di oscurare il semplice compito originale a causa
delle grandi quantità di codice complesso da utilizzare per affrontare questi problemi.
Come reazione a questa complessità abbiamo progettato una nuova astrazione che ci
permette di esprimere i semplici calcoli che cercavamo di eseguire nascondendo i dettagli
della parallelizzazione, gestione dei fallimenti, distribuzione dei dati e bilanciamento del
carico in una libreria.
La nostra astrazione si ispira alle primitive Map e Reduce presenti in Lisp e molti altri
linguaggi funzionali. Ci siamo accorti che la maggior parte dei nostri calcoli coinvolgeva
un’operazione Map per ogni “record” logico in ingresso, al fine di calcolare un set di
coppie chiave/valore intermedio, e quindi l’applicazione di una Reduce su tutti i valori che
condividevano la stessa chiave, in modo da combinare i dati derivati in manieara
appropriata
21
MapReduce è un modello di programmazione e attuazzione associato all’elaborazione e
alla generazione di grandi insiemi di dati. Gli utenti specificano due funzioni:
Map() che elabora una coppia chiave/valore per generare un insieme intermedio di
coppie chiave/valore
Reduce() che unisce tutti i valori intermedi associati alla stessa chiave.
Molti compiti reali sono esprimibili con tale modello, come di seguito sarà dimostrato.
I programmi scritti con stile funzionale sono automaticamente parallelizzati ed eseguiti
su un Large Cluster di macchine commodity.
Il sistema in fase di run-time si prende cura dei dettagli del partizionamento dei dati di
input, della pianificazione dell’esecuzione del programma attraverso una serie di
macchine, e la gestione necessaria della comunicazione tra le macchine.
Tale approccio consente ai programmatori senza alcuna esperienza con i sistemi paralleli e
distribuiti di utilizzare facilmente le risorse di un Large Distributed System.
MapReduce, girando su tante macchine commodity, è altamente scalabile: una tipica
computazione di MapReduce elabora molti terabyte di dati su migliaia di macchine.
I Programmatori trovano il sistema di semplice utilizzo: centinaia di programmi
MapReduce sono stati implementati e più di un migliaio di job MapReduce vengono
eseguiti sui cluster Google ogni giorno.
3.1 Funzioni Map e Reduce
Il processo prende in ingresso una coppia chiave/valore e produce un insieme di coppie
chiave/valore in uscita. L’utente della libreria MapReduce esprime il calcolo con due
funzioni: Map e Reduce.
•
Map: scritta dall’utente, prende una coppia di ingressi e produce un insieme di M
coppie intermedie chiave/valore
•
Reduce: scritta dall’utente, il processo MapReduce considera tutti gli M valori
intermedi associati alla stessa chiave intermedia e li invia alla funzione Reduce.
Tale funzione accetta una chiave intermedia e un set di valori per tale chiave, fonde
22
insieme questi valori per formarne il più piccolo insieme possibile.
A esempio Si consideri il problema di contare il numero di occorrenze di ogni parola in
una grande collezione di documenti. L’utente dovrebbe scrivere un codice simile al
seguente pseudo-codice per le funzioni Map e Reduce:
•
La funzione Map riceve in ingresso una coppia (chiave, contenuto) con cui
intendiamo per “chiave” il nome univoco di un documento e per “contenuto” il
testo stesso del documento. La funzione, per ogni parola del documento, genera in
uscita una coppia (parola, 1) (vista come un insieme chiave/valore intermedio)
ovvero indica che ha trovato una occorrenza di quella parola.
map(String chiave, String contenuto)
for ogni parola i in contenuto
CreaIntermedio(i, “1”);
esempio pratico: se avessi un contenuto del genere: Antoio è il cugino di Antonio,
la map genererebbe tale schema, ovvero gli M valori intermedi (parola, 1):
•
Antonio
1
è
1
il
1
cugino
1
di
1
Antonio
1
La Reduce riceve in ingresso i precedenti valori intermedi, quindi la coppia (parola, 1),
raggruppa tutte le coppie che presentano la stessa parola (usata quindi come chiave) e
somma i valori di tutte le coppie, generando una sola coppia in uscita, contenente la parola e
la somma di tutte le occorrenze. Quindi somma tutti i conteggi emessi per una data parola.
Nel codice sottostante “chiave” identifica la parola della precedente funzione e “valore” è il
23
precedente contatore delle occorrenze della parola:
reduce(String chiave, Iterator valore)
for ogni j in valore
risultato+=AnalizzaInt(j);
Crea(ComeStringa(result);
Considerando i valori pratici dell’esempio precedente avremo come risultato tale lista:
Antonio 2
cugino 1
di 1
è1
il 1
Considerando uno schema input -> output:
map (k1, v1) -> list (k2, v2)
reduce (k2, list(v2)) -> list (v2)
Il codice sopra sottolinea che le chiavi e i valori di input sono tratti in un diverso dominio
rispetto alle chiavi e ai valori di output. Inoltre chiavi e valori intermedi sono dello stesso
dominio, come le chiavi e i valori di uscita.
3.2 Implementazione
Sono possibili molte diverse implementazioni dell’interfaccia di MapReduce. La scelta
giusta dipende dall’ambiente in cui dovrà operare. Per esempio un’implementazione può
essere adatta per una piccola macchina a memoria condivisa, un’altra per un grande multiprocessore NUMA (architettura di memoria per i sistemi multiprocessore) e un’altra
ancora per collezioni ancora più grandi di macchine collegate in rete.
24
Questa sezione descrive l’implementazione mirata all’ambiente di calcolo in largo uso a
Google: grandi cluster di pc commodity collegati insieme tramite switch Ethernet.
In tale ambiente le macchine sono tipicamente processori dual-processor x86 con Linux,
con 2 o 4 GB di memoria per macchina. L’hardware di rete Commodity viene usato, in
genere, a 100 Mb/s o 1 Gb/s a livello macchina ma in media ha una larghezza di banda
complessiva molto inferiore. Un Cluster consiste di centinaia o migliaia di macchine e
quindi i guasti alle macchine sono comuni. Lo memoria di massa è fornita da dischi IDE
economici collegati direttamente alle singole macchine. Un file system distribuito
sviluppato in-house viene utilizzato per gestire i dati memorizzati su questi dischi. Il file
system utilizza la replicazione per fornire disponibilità e affidabilità a valle di un hardware
inaffidabile.
Gli utenti inviano i lavori ad un sistema di scheduling. Ogni job consiste di un insieme di
task e viene mappato dallo scheduler su una serie di macchine disponibili all’interno di un
cluster.
Consideriamo uno degli aspetti principali di tale framework: la tolleranza ai guasti.
3.2.1 Gestione dei fallimenti
Dal momento che la libreria MapReduce è progettata per aiutare processi con grandi
quantità di dati usando centianaia o migliaia di macchine, la libreria deve tollerare guasti
macchina in maniera soft.
Fallimento del Worker
Il Maestro “pinga” tutti Worker periodicamente. Se non riceve risposta da un worker in un
certo lasso di tempo designa il fallimento del worker. I task si possono dividere in
“completati” e “in corso”. I task map completati dal worker sono ripristinati al loro stato di
inattività iniziale (idle) e quindi diventano idonei per lo scheduling su altri worker. Allo
stesso modo, qualunque task map o reduce ancora in attività su un worker fallito sono
resettati al minimo e diventano idonei per la riprogrammazione (rescheduling).
Task map completati vengono nuovamente eseguiti su un worker fallito perchè la loro
25
produzione è memorizzata sul disco locale della macchina fallita e quindi è inaccessibile. I
Task reduce completi non necessitano di essere eseguiti nuovamente in quanto il loro
output è memorizzato nel file system globale.
Quando una map viene eseguita prima da un worker A e poi eseguita da un worker B
(perchè A fallisce), tutti i lavoratori che eseguono la reduce vengono informati della
riesecuzione. Qualsiasi task reduce che non ha già letto i dati del worker A leggerà i dati
dal worker B.
Map Reduce è resistente ai guasti di worker su larga scala. Ad esempio, durante una
operazione MapReduce, una manutenzione di rete eseguita su un cluster ha causato la
caduta di gruppi di 80 macchine alla volta per diventare irraggiungibile per alcuni minuti.
Fallimento del Master
Il Master mantiene diverse strutture dati. Per ogni task map e reduce memorizza lo stato
(idle, in corso o completato) e l’identità della macchina worker. Il Master è il condotto
attraverso il quale i file intermedi sono propagati dai task map ai reduce. Pertanto, per ogni
task map completo il master memorizza le posizioni e le dimensioni delle regioni di file
intermedi R prodotte dal task mappa. Aggiornamenti di questa posizione e informazioni
sulle dimensioni vengono ricevute a task map completato. L’informazione è inviata ai
worker che hanno in corso attività reduce.
E’ facile far salvare al Master dei checkpoint periodici delle strutture dati sopra descritte.
Sei il task master muore una nuova copia può essere avviata dall’ultimo stato checkpoint.
Tuttavia, dato che c’è un solo master, il suo falilmento è improbabile, quindi
l’implementazione attuale prevede la terminazione immediata dell’operazione di
MapReduce. I clienti possono verificare questa condizione e ritentare l’operazione
MapReduce se lo desiderano.
3.2.2 Parallelizzazione dei Calcoli
Quando gli operatori map e reduce definiti dagli utenti sono funzioni deterministiche dei
loro valori di input l’implementazione distribuita di Google produce lo stesso risultato che
26
sarebba stato prodotto da una esecuzione non divisa (quindi non parallela ma sequenziale)
dell’intero programma.
Per questa proprietà facciamo affidamento su commit atomici di map e task di output per
le reduce. Ogni attività in corso scrive il suo output su file temporanei privati. Un task
reduce produce un unico file di questo tipo, mentre un task map produce R file di questo
tipo (ognuno sarà l’ingresso per un task reduce).
Una volta completata il task map, il worker invia un messaggio al master e include i nomi
dei file temporanei R nel messaggio. Se il master riceve un messaggio di completamento
di un task map già completato ingora il messaggio. In caso contrario, registra i nomi dei
file R in una struttura dati del master.
Al termine di un task reduce, il worker reduce rinomina atomicamente il suo file di output
temporaneo con il nome del file di output finale. Se la setessa operazione reduce viene
eseguita su più macchine, più chiamate di ridenominazione saranno eseguite per lo stesso
file di output finale. A tal proposito si evitano più ridenominazioni grazie all’operazione di
ridenominazione atomica fornita dal file system sottostante in modo tale che lo stato finale
del file system contenga solo i dati prodotti da una singola esecuzione del task reduce.
La stragrande maggiornanza degli operatori map e reduce sono deterministici e il fatto che
la semantica sia equivalente ad una esecuzione sequenziale rende molto semplice ai
programmatori poter ragionare sul comportamento dei propri programmi.
Quando la map e/o la reduce non sono deterministiche viene fornita una semantica più
debole. Consideriamo il caso di operatori non deterministici: sappiamo che i dati sono
replicati su più macchine, quindi è possibile avere più risultati di una map M1. Tali
risultati, essendo figli di un’esecuzione deterministica saranno uguali, quindi una reduce
R1 può lavorare indifferentemente su uno qualsiasi degli output:
M1 worker 1 -> R1 -> A
M1 worker 2 -> R2 -> A
M1 worker x -> Rx -> A
27
Consideriamo ora il caso di operatori non deterministici: il risultato di una map M2
potrebbe essere diverso dal risultato della stessa map M2 eseguita su una macchina
diversa. Ciò comprometterebbe il risultato delle funzioni R2 che andranno ad utilizzare
dati differenti.
M2 worker 1 -> R1 -> A
M2 worker 2 -> R2 -> B
M2 worker x -> R3 -> C
3.2.3 Distribuzione del carico
Le invocazioni della Map sono distribuite su più macchine per il partizionamento
automatico dei dati di input in un insieme di gruppi M. I frammenti in ingresso possono
essere trattati in parallelo da macchine diverse. Le invocazioni della Reduce sono
distribuite suddividendo lo spazio della chiave intermedia in R pezzi utilizzando una
funzione di partizionamento.
Il numero di partizioni R e la funzione di partizionamento sono specificati dall’utente.
28
La Figura 1 mostra il flusso generale di un’operazione MapReduce. Quando il programma
utente chiama la funzione MapReduce si invoca il seguente algoritmo:
La libreria MapReduce, nel programma utente, prima divide i file di input in M
pezzi (in generale dai 16 MB ai 64 MB per pezzo controllabili dall’utente tramite
un parametro opzionale, poi esegue molte copie del programma su un cluster di
macchine.
Una delle copie del programma è speciale, il Master. Il resto sono i Worker a cui
vengono assegnati i lavori dal master. Ci sono da assegnare M task Map ed R task
Reduce. Il Master sceglie i lavoratori inattivi e assegna a ciascuno un task Map e
un task Reduce.
Un worker a cui viene assegnata una Map legge il contenuto del corrispondente
frammento di input, analizza le coppie chiave/valore sui dati di input e applica la
Map dell’utente.
Periodicamente, le coppie bufferizzate vengono scritte in locale sul disco e
partizionate in R regioni dalla funzione di partizionamento. Le posizioni di queste
coppie bufferizzate sul disco locale sono passate al master che è responsabile
dell’inoltro di queste posizioni ai worker che eseguono la funzione reduce,
Quando a un reduce worker viene a conoscenza, tramite il master, di queste
posizioni, utilizza letture in remoto per leggere i dati memorizzati nel buffer dei
dischi locali dei map worker. Quando un reduce worker ha letto tutti i dati
intermedi, li ordina nelle chiavi intermedie in modo che tutte le occorrenze della
stessa chiave siano raggruppate insieme. E’ necessaria la Sort (o in generale
l’ordinamento) perchè in generale molte chiavi diverse mappano lo stesso task
reduce. Se la quantità di dati intermedi è troppo grande per entrare in memoria
viene usato un ordinamento esterno.
L’output della funzione Reduce viene aggiunto ad un file di output finale.
Quando tutte le attività di Map e Reduce sono state completate il Master sveglia il
29
programma utente. A questo punto la chiamata MapReduce nel programma utente
ritorna al codice utente.
Terminato con successo l’algoritmo MapReduce l’output dell’esecuzione MapReduce è
disponibile sui file di uscita R. In generale gli utenti non hanno bisogno di combinare
questi file di uscita R in un unico file, infatti spesso tali file sono passati come input per
un’altra chiamata MapReduce o usati da un’altra applicazione distribuita che è in grado di
gestire input diviso in più file o utilizza altri programmi per visualizzazioni diverse da
quella testuale.
4 BigTable
Abbiamo analizzato il framework MapReduce nella sezione precedente, ma sarebbe
impossibile paragonarlo ad un vero e proprio database in quanto “semplicemente” estende
le proprietà di un comune DMBS in modo tale da poter supportare caratteristiche
necessarie per processare i BigData. Vediamo quindi di seguito uno dei sistemi più noti
che sfruttano MapReduce proprio per “potenziarsi”.
4.1 Introduzione
BigTable è un sistema di storage e database distribuito per la gestione di dati strutturati, ad
altre prestazioni, che può adattarsi a insiemi di dati di enormi dimensioni. Progettato e
costruito da Google per conseguire risultati ottimali mediante strumenti già esistenti come
il Google File System, il framework MapReduce e altre tecnologie proprietarie.
Molti progetti Google sono memorizzati in BigTable, tra cui l’indicizzazione web, Google
Earth, Google Finance. Questa applicazioni pongono esigente molto diverse, sia in termini
di dimenisoni dei dati (da url di pagine web a imamgini satellitari) e requisiti di latenza
(dai servizi a memorizzazione persistente a servizi in tempo reale). Nonostate queste
diverse esigenze BigTable ha fornito con successo una soluzione flessibile ed alte
prestazioni per tutti questi prodotti Google.
30
4.2 Caratteristiche principali
BigTable è un DBMS nel seso che condivide con tali tipologie di software molte strategie
di implementazione: parallelizzazione del calcolo, in-memory, elevata scalabilità, alte
prestazioni. Si differenzia da tali sistemi per la sua interfaccia: non supporta un modello
full-relational ma fornisce un modello di dati semplice, che dimostra un approccio
dinamico al formato e consente di ragionare sulla loro località nella memoria sottostante;
condivide con le moderne generazioni di DBMS la possibilità di immettere dati non
interpretati sottoforma di stringhe, spesso infatti si utilizza tale tipologia di dati per
introdurre dati semi-strutturati e strutturati. E’ inoltre possibile scegliere se lavorare inmemory o su disco.
4.2.1 Data Model
BigTable basa le proprie operazioni sulla Map. Tale funzione è indicizzata da una chiave
riga, una chiave colonna e un timestamp. Ogni valore nella Map è una matrice di byte:
Figura 1
Consideriamo la Figura 1, è un esempio di una tabella che memorizza pagine web. Il nome
della riga è un URL invertito. la prima column family “contents” memorizza il contenuto
della pagina, le successive column family “anchor” contengono il testo dei link che fanno
riferimento alla pagina. Ad esempio, l’home page della CNN fa riferimento sia allo Sport
che alla home page MY-look, quindi la riga contiene colonne di ancoraggio: cnnsi.com e
my.look.ca. Ogni cella di ancoraggio ha una versione. La colonna dei contenuti ha tre
versioni, dipendenti dal timestamp, t3, t5, t6.
31
Quindi gli URL vengono utilizzati come riga chiave, i vari aspetti della pagina web sono
memorizzati come colonne e il contenuto della pagina web è memorizzato nella colonna
“contents”.
4.2.2 Formato dei File
Il formato del file di Google SSTable viene utilizzato internamente per memorizzare i dati
BigTable. Un SSTable offre un persistente, rdered mappa immutabile da chiavi di valori,
in cui entrambe le chiavi ed i valori sono stringhe di byte arbitrarie. Le operazioni sono
previste per cercare il valore associato a una chiave specificata, e per scorrere tutte le
coppie chiave / valore in un intervallo chiave specificata. Internamente, ogni SSTable
contiene una sequenza di blocchi (tipicamente ogni blocco è 64 KB, ma questo è
configurabile). Un indice di blocco (memorizzati alla fine del SSTable) viene utilizzata per
individuare blocchi; l'indice viene caricato in memoria quando il SSTable è aperto. Una
ricerca può essere eseguita con un singolo disco cerchiamo: dobbiamo prima trovare il
blocco appropriato eseguendo una ricerca binaria nell'indice in memoria, e quindi la
lettura del blocco appropriato dal disco. Facoltativamente, un SSTable può essere
completamente mappato in memoria, che ci permette di effettuare ricerche e scansioni
senza toccare disco
4.2.3 Servizio Distribuito
Un cluster Bigtable opera tipicamente in un pool condiviso di macchine che eseguono una
varietà di altre applicazioni distribuite, e i processi Bigtable spesso condividono le stesse
macchine con processi di altre applicazioni. Bigtable pende su un sistema cluster di
gestione per i processi di pianificazione, gestione delle risorse su macchine condivise,
fallimenti hardware, e il monitoraggio dello stato della macchina.
Bigtable si basa su un servizio di blocco distribuito altamente disponibile e persistente
chiamato Chubby. Un servizio Chubby si compone di cinque repliche attive, uno delle
quali viene eletto ad essere il Master e servire attivamente le requests. Il servizio è
32
efficiente quando la maggioranza delle repliche sono in esecuzione e in grado di
comunicare tra loro.
Bigtable utilizza Chubby per una varietà di compiti: per garantire che vi sia al massimo un
master attivo in qualsiasi momento; per memorizzare il percorso bootstrap dei dati
BigTable; per scoprire i server e finalizzare le morti dei server; per memorizzare le
informazioni sullo schema Bigtable (le informazioni famiglia di colonne per ogni tabella);
e per memorizzare elenchi di controllo di accesso. Se Chubby diventa non disponibile per
un periodo di tempo prolungato, Bigtable non è più disponibile.
4.3 Applicazioni Reali
Ad agosto 2006, ci sono 388 non-test cluster BigTable in esecuzione in vari cluster di
macchine di Google, con un totale di circa 24.500 server tablet.
Molti di questi gruppi sono utilizzati per scopi di sviluppo e quindi sono in idle per periodi
significativi. Un gruppo di 14 cluster occupati con 8.069 server ha visto un volume
complessivo di oltre 1,2 milioni di richieste al secondo.
Alcune Tabelle sono assegnate ai clienti del database ma la maggior parte sono utilizzate
internamente all’azienda, vediamo alcuni prodotti che utilizzano BigTable
4.3.1 Google Analytics
Google Analytics (analytics.google.com) è un servizio che aiuta i webmaster ad analizzare
i modelli di traffico sui loro siti web. Esso fornisce statistiche aggregate, come ad esempio
il numero di visitatori al giorno e quali sono state viste in quel giorno, nonché le relazioni
del sito di monitoraggio, come ad esempio la percentuale di utenti che ha fatto un acquisto,
dopo che in precedenza hanno visto una pagina specifica. Per attivare il servizio, i
webmaster incorporano un piccolo programma JavaScript nelle loro pagine web. Questo
programma viene richiamato ogni volta che si visita una pagina e registra varie
informazioni relative alla richiesta di Google Analytics, come ad esempio un identificativo
33
utente e le informazioni sulla pagina per essere recuperata. Google Analytics riassume i
dati e li rende disponibili per i webmaster.
Vediamo brevemente due delle tabelle utilizzate da Google Analytics. La tabella “click
grezzo” (200 TB) mantiene una riga per ogni sessione dell’utente finale. Il nome della riga
è una tupla contenente il nome del sito e l'ora in cui la sessione è stata creata. Questo
schema garantisce che le sessioni che visitano lo stesso sito web siano contigue, e che
siano ordinate cronologicamente. La compressione di tale tabella è il 14% del suo spazio
originale.
La tabella riassuntiva (20 TB) contiene vari riassunti per ogni sito web. Questa tabella è
generata dalla tabella click grezzo e richiede periodici lavori tramite MapReduce. Ogni
lavoro MapReduce estrae i dati di sessione recenti dalla tabella click grezzo. Il rendimento
del sistema complessivo è limitato dalla velocità delle interconnessioni. Questa tabella
comprime al 29% la sua dimensione originale.
4.3.2 Google Earth
Google gestisce un insieme di servizi che forniscono agli utenti l'accesso alle immagini ad
alta risoluzione satellitare della superficie del mondo, sia attraverso l'interfaccia webbased di Google Maps (maps.google.com) e tramite Google Earth (earth.google.com)
client personalizzato software. Questo sistema utilizza una tabella di dati pre-elaborati, e
un diverso insieme di tabelle per servire i client. La pipeline di pre-elaborazione utilizza
una tabella per memorizzare le immagini in righe. Durante la pre-elaborazione,
l'immaginario è pulito e consolidato in dati finali. Questa tabella contiene circa 70 terabyte
di dati e, pertanto, viene servita dal disco. Tali immaggini sono già compresse in modo
efficiente quindi è disattivata la compressione BigTable. Ogni riga della tabella delle
immagini corrisponde ad un singolo segmento geografico. Le righe sono chiamate a
garantire che i segmenti geografici adiacenti siano conservati vicino a vicenda. La tabella
contiene una famiglia colonna per tenere traccia delle fonti di dati per ogni segmento.
Questa famiglia colonna ha un gran numero di colonne: essenzialmente una per ogni
immagine. Dal momento che ogni segmento viene costruito solo da poche immagini,
34
questa famiglia Colonna è molto piccola. La pipeline di pre-elaborazione si basa
pesantemente su MapReduce per trasformare i dati. I processi di sistema complessivo sono
di oltre 1 MB / sec di dati al server durante alcuni di questi posti di lavoro MapReduce. Il
sistema usa una tabella di dati indicizzati e memorizzati nel Google File System. Questa
tabella è relativamente piccola (500 GB), ma deve servire decine di migliaia di query al
secondo per datacenter con bassa latenza. Come risultato, questa tabella è presente su
centinaia di server tablet e contiene famiglie di colonna In-Memory.
4.3.3 Ricerca Personalizzata
Ricerca personalizzata (www.google.com / psearch) è un servizio che registra le query
degli utenti e click attraverso una varietà di proprietà di Google come la ricerca web,
immagini e notizie. Gli utenti possono navigare le loro cronologie e rivedere le loro
vecchie query e click, e possono chiedere dei risultati di ricerca personalizzati in base ai
loro modelli di utilizzo di Google. Ricerca personalizzata memorizza i dati di ciascun
utente in BigTable. Ogni utente dispone di un UserId unico e tale UserId viene assegnao
ad una riga. Tutte le azioni dell'utente vengono memorizzati in una tabella. Una famiglia
colonna separata è riservata per ciascun tipo di azione (per esempio, vi è una famiglia di
colonne che memorizza tutte le query web). Ogni elemento di dati utilizza come
timestamp l'ora in cui si è verificata la corrispondente azione dell'utente. Ricerca
personalizzata genera i profili utente utilizzando un MapReduce su Bigtable. Questi profili
utente vengono utilizzati per personalizzare i risultati di ricerca in tempo reale. I dati
Ricerca personalizzata sono replicati attraverso diversi cluster BigTable per aumentare la
disponibilità e per ridurre la latenza a causa della distanza da parte dei clienti. La
progettazione del sistema di ricerca di storage personalizzata consente ad altri programmi
di aggiungere nuove informazioni per ogni utente nelle proprie colonne, e il sistema viene
ora utilizzato da molte altre proprietà di Google che hanno bisogno di memorizzare per
ogni utente le opzioni e le impostazioni di configurazione.
35
Bibliografia
[1]
Marco Russo, “Che cosa pensereste se vi dicessero che in Italia i BigData non
esistono?”, Maggio 2013
[2]
Colin White, “What is BigData and why do we need it?”, Gennaio 2012
[3]
Jeff Kelly, “Primer on SAP HANA”, Luglio 2013
[4]
saphana.com, http://www.saphana.com/community/about-hana, Giugno 2014
[5]
Franz Farber, Sang Kyun Cha, Jurgen Primsch, Christof Bornhovd, Stefan Sigg,
Wolfgang Lehner, “Paper - SAP HANA Database – Data Management for Modern
Business Applications”, Dicembre 2011
[6]
Jeffrey Dean and Sanjay Ghemawat, “Paper – MapReduce: Simplified Data
Processing on Large Clusters”, 2004
[7]
Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach
Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber, “Paper – BigTable: A
Distributed Storage System for Structured Data”, 2006
36
