Distributed Data Stream Processing

Transcript

1 Distributed Data Stream Processing Sistemi Distribuiti e Cloud Computing A.A. 2015/16 Matteo Nardelli Matteo Nardelli

2 Big Data IBM (2014) [1] : ogni giorno vengono creati circa 2,5 trilioni (10 18 ) di byte di dati ed il 90% dei dati è stato creato solo negli ultimi due anni. SOURCE: (2014) 2

3 Big Data Ogni anno prodotti circa 1200 EXABYTE (10^18, 2^60) di dati SOURCE: (2011, Stanford Univ.) Matteo Nardelli 3

4 Big Data Big Data indica collettivamente un insiemi di dati caratterizzati da (3+1 V): Volumi (terabyte, petabyte); Variabilità (di rappresentazione: strutturati e non strutturati); Velocità: dati in movimento, velocità di generazione e di analisi: utilità dell informazione estraibile degrada rapidamente con il passare del tempo; Veracity (veridicità): l integrità e l affidabilità dei dati: potervi fare affidamento per le operazioni di decision making. Approcci per la loro analisi: MapReduce: store and process; Data Stream Processing: elaborazione veloce dei dati senza memorizzarli. Matteo Nardelli 4

5 Motivazione number of four-byte integer values read per second from a 1-billion-long (4 GB) array on disk or in memory; random disk reads are for 10,000 indices chosen at random between one and 1 billion Adam Jacobs The Pathologies of Big Data. Queue 7, 6, Pages 10 (July 2009), 10 pages. Matteo Nardelli 5

6 Interesse Estrarre tempestivamente informazioni di interesse (di valore) da un insieme dati con le caratteristiche dei Big Data Produzione energetica: analisi consumi e produzione rinnovabili per allocazione più efficiente; Finanziario: evoluzione/previsione in tempo reale di quote azionarie; Medicina: telemedicina, studiare e prevedere la diffusione epidemica (Google Flu); Sicurezza: uso improprio di reti/sist. pagamento; behavioural pattern recognition; Servizi urbani: dispositivi per info traffico; ottimizzazione trasporti in risposta ad eventi; e.g., statistiche per taxi: tratte più frequenti, aree più redditizie (DEBS 2015 [2] ). Matteo Nardelli 6

7 Evoluzione delle Soluzioni Soluzioni derivanti da domini/contesti diversi Risultato: termini e soluzioni sovrapponibili (torre di babele) Una non-soluzione sono i DBMS impossibile memorizzazione tutti i dati processarli solo su richiesta DSMS (data stream management system): evoluzione dei DBMS Prevede: processamento continuo delle query (continuous query - CQ) query con sintassi SQL-like su flussi di dati transienti, non memorizzati Matteo Nardelli 7

8 Evoluzione delle Soluzioni DSP (data stream processing): è il modello che deriva dalla generalizzazione del DSMS (dati non persistenti, continuous query) «processamento di stream provenienti da sorgenti differenti, per produrre nuovi stream in uscita» (Cugola, Margara [3] ) CEP (complex event processing): si sviluppa in parallelo al DSMS, come evoluzione del publish-subscribe; processamento di notifiche di eventi (n.b.: non dati generici) provenienti da sorgenti diverse per identificare pattern di eventi (o eventi complessi) di interesse (in publish-subscribe ogni evento è separato dagli altri) MapReduce: paradigma per la computazione affidabile, scalabile e distribuita dati memorizzazione su file system distribuito (i.e., GFS, HDFS) paradigma «map» e «reduce» per lavorare su sottoinsiemi di dati Matteo Nardelli 8

9 DSP: Differenze con CEP Tipo di dato: CEP: notifiche di eventi DSP: (teoricamente) qualsiasi Tempo associato al dato ed ordinamento dei dati: CEP: molto importanti/essenziali DSP: non necessariamente considerati Tipologia di linguaggi per definire applicazioni: CEP: pattern-based language per specificare le firing condition e le azioni da intraprendere («if this then that»). DSP: (opzionale) regole di trasformazione (filtraggio, join, aggregazioni) per processare gli stream in ingresso e produrre stream in uscita. Matteo Nardelli 9

10 DSP: Differenze con Hadoop (MapReduce) Diverse estensioni consentono di usare Hadoop: Per interrogare il dataset con un approccio SQL-like (Apache Hive) Per interrogare il dataset con linguaggio procedurale (Apache Pig) Produrre approssimazioni successive dei risultati e possibilità di fare CQ (MapReduce Online [4] ) Differenze sostanziali: Persistenza: Hadoop necessita della memorizzazione dei dati Batching: Anche negli approcci per il CQ (Hadoop Online) si lavora considerando piccoli batch successivi da analizzare; questo introduce un ritardo proporzionale alla dimensione del batch. Matteo Nardelli 10

11 Distributed Data Stream Processing Applicazione descritta tramite un grafo diretto aciclico, chiamato «topologia» nodi = operatori dell'applicazione; archi = stream scambiato tra gli operatori Matteo Nardelli 11

12 DSP: Applicazioni Principali caratteristiche delle applicazioni DSP: Sorgenti: distribuite emettono un flusso continuo (stream) di dati (e.g., tuple) Stream: non memorizzato, riversato su un insieme di operatori Operatori (o Processing Elements): distribuiti progettati per lavorare in parallelo svolgono delle funzioni ben precise (e.g., aggregazione, filtraggio, trasformazione) possono generare un nuovo stream in output stateful: memorizzano uno stato interno (influenza output); stateless: output dipende solo dall input interagiscono solo per mezzo degli stream Matteo Nardelli 12

13 DSP: Modelli di processamento Di recente, sono emersi due modelli di DSP: one-at-a-time: ogni tupla è inviata singolarmente microbatched: tuple raggruppate prima di essere invite (e.g., Apache Storm) (e.g., Apache Spark) I due approcci sono complementari, trade-off tra punti di forza e debolezze, ed adatti per applicazioni diverse SOURCE: N. Marz, J. Warren Big Data. Matteo Nardelli 13

14 DSP: Ottimizzazioni Generalmente le applicazioni DSP richiedono performance estreme, le diverse comunità hanno sviluppato diverse forme di ottimizzazioni [5] Operator reordering, redundancy elimination, data parallelism, load balancing, load shedding, Parallelismo: processamento dei dati, applicando diverse forme di parallelismo: Pipeline: istruzione complessa suddivisa in una sequenza di passi Task parallelism: eseguire in parallelo le operazioni indipendenti (eventualmente riutilizzando i dati in input) Data parallelism: eseguire in parallelo una stessa operazione su un sottoinsieme dei dati in ingresso Matteo Nardelli 14

15 Ottimizzazione: Data Parallelism Aumentare le istanze dell operatore ed ogni istanza processa una porzione dello stream operatori stateless: nessun problema operatore stateful: problemi di inconsistenza dello stato Operatori partitioned stateful: caso speciale di operatori stateful; lo stato interno dipende da dati separabili in partizioni (shard) indipendenti parallelizzabile finché i dati della stessa partizione sono contenuti nello stesso stream Ogni shard (partizione orizzontale dei dati) è indirizzata sempre alla stessa istanza dell operatore, identificata applicando una funzione hash-based su sottoinsieme di attributi dei dati (partition key) Matteo Nardelli 15

16 Ottimizzazione: Load Shedding Load shedding: sacrifica l accuratezza dei risultati se il sistema è sovraccarico Decisioni fondamentali: Come scartare: random, probabilistico, priority-based, tecniche avanzate Quando scartare il traffico: comportamento proattivo o reattivo Dove scartare il traffico: ridurre il carico vicino alla sorgente fa sprecare meno lavoro, ma penalizza un numero maggiore di applicazioni Quanto scartare: dipende dalla politica di shedding adottata (e.g., fino a soddisfacimento soglia, percentuale, numero di classi) Matteo Nardelli 16

17 Infrastruttura Dove sono le risorse computazionali? Cluster dedicato nodi omogenei, «vicini» ed in numero staticamente definito scelta tradizionale Cloud e Distributed Clouds allocazione dinamica migliore assorbimento delle fluttuazioni nell'arrivo dei dati nodi geograficamente distribuiti nuovo interesse per il DSP, ma anche nuove problematiche i.e., scala, attenzione per la latenza tra i nodi, SLA Soluzioni ibride insieme statico di nodi, estendibili con risorse on-demand nel cloud trade-off tra prestazioni, bilanciamento del carico e costi Matteo Nardelli 17

18 Il problema dello Scheduling Scheduler: componente dei sistemi di DSP che assegna gli operatori delle applicazioni da eseguire alle risorse computazionali a disposizione Componente critico, influenza fortemente le performance del sistema e delle applicazioni eseguite. Diverse soluzioni: Algoritmo centralizzato vs algoritmo distribuito Conoscenza intera rete, problemi di scalabilità Metriche da ottimizzare Latenza, utilizzo della rete, importanza degli operatori, risorse Capacità adattativa Capacità di ottimizzare il grafo applicativo generalmente con definizione applicazioni con linguaggi formali e.g., merging, splitting e riordinamento degli operatori, load shedding Matteo Nardelli 18

19 Lambda Architecture Combina (i vantaggi di) diverse soluzioni per analizzare i Big Data Risponde alla stessa «query» fornendo una prima risposta approssimata (tramite speed layer) che viene affinata nel tempo (batch + serving layer): Batch layer: memorizza i dati e calcola delle «batch view» (Hadoop) Serving layer: carica ed indicizza le «batch view» per consentirne l esplorazione in modalità read-only (Google Dremel, Apache Drill, Impala, SploutSQL, ) Speed layer: calcola le «real-time view» in modo incrementale (basse latenze); responsabile per i dati non ancora presenti nelle viste del serving layer (DSP: Storm, Spark, ) Quando le batch view sono disponibili nel serving layer, i risultati corrispondenti presenti nelle realtime view vengono scartati. Matteo Nardelli 19 IMG SOURCE:

20 Lambda Architecture Proprietà: Batch e Serving layer: fault-tolerance e scalabilità di MapReduce Complexity isolation: lo speed layer, che è più difficile da realizzare, può compromettere i risultati per una finestra temporale limitata Flessibilità: usare algoritmi esatti nel batch layer, ed alg. approssimati nello speed layer. I risultati approssimati vengono corretti da quelli esatti (eventual accuracy) Michael Stonebraker (ACM Turing Award 2014) I suoi lavori hanno avuto un ruolo centrale nei sistemi database relazionali odierni Conosciuto per: Ingres (ER), Postgres, Streambase, SciDB, VoltDB (ma non solo!) VoltDB: in-memory, NewSQL (scalable, ACID, RDBMS), real-time database si basa su una semplificazione dell architettura lambda Matteo Nardelli 20

21 Kappa Architecture Semplificazione della lambda architecture: la presenza del processamento batch e real-time richiede duplicazione del codice ed effort di coordinamento Kappa architecture: uno stream processor può lavorare sia in modalità streaming che batching Applicazione è chiamata workflow Composta da pipeline di task Ogni task può essere un operatore di tipo stream o un job MapReduce Il framework può trattare i task in modo diverso in base alla loro tipologia Trattare = ottimizzare, memorizzare, spostare i risultati intermedi Framework: Apache Flink, Google Cloud DataFlow, Apache Spark Matteo Nardelli 21

22 Framework per il DSP Amazon Kinesis Apache Storm Matteo Nardelli 22

23 Amazon Kinesis Elaborazione real-time di streaming data su larga scala; definisce: Stream: sequenza di record Record: {sequence, partition-key, blob}; blob max size 50Kb Shard: numero di nodi su cui suddividere lo stream; questi sono determinati in base al datarate in ingresso ed in uscita desiderati Come funziona? Producers: (sorgenti esterne) generano i record, li immettono con HTTP PUT Matteo Nardelli 23

24 Amazon Kinesis Consumers: le applicazioni (generalmente su EC2) che processano ogni record dello stream - è possibile avere diverse applicazioni che consumano in modo indipendente e concorrente - l output può essere: un altro Kinesis Stream, EC2, DynamoDB, S3, altro Vantaggi Kinesis gestisce automaticamente l infrastruttura, lo storage e la configurazione necessaria per il recupero e l elaborazione dei dati Infrastruttura: load balancing, coordinamento tra i servizi distribuiti, fault tolerance Storage: dati memorizzati (e replicati) in diverse Availability Zone della stessa regione per 24 ore, periodo in cui sono disponibili Limitazioni Numero massimo di shard (50 o 25 in base alle regioni) Matteo Nardelli 24

25 Apache Storm Framework distribuito, scalabile, fault-tolerant per il DSP Applicazione (o topologia): componenti spout: sorgente delle tuple bolt: componente che elabora le tuple; può generarne di nuove stream: sequenza non limitata di tuple (tupla: insieme di coppie chiave/valore) spout bolt Poiché un bolt può essere replicato è possibile indicare: fieldgrouping: i campi per il partizionamento dello stream shufflegrouping: non siamo interessati allo stato Matteo Nardelli 25

26 Apache Storm: architettura ZooKeeper (shared memory) scambio configurazione e sincronizzazione Nimbus (nodo master) Scheduling (distribuzione per l esecuzione) delle applicazioni (topologie) Monitoring applicazioni: riassegnamento in caso di fallimento Worker Node Supervisor avvia e termina i worker process in base alle indicazioni di Nimbus Worker Process esegue (parte del) codice della topologia WN Supervisor WP WP Nimbus ZooKeeper WN Supervisor WN Supervisor WP Matteo Nardelli 26

27 WordCount in Storm WordCounter (esempio in storm-starter [6] ): Avendo sorgenti che emettono continuamente frasi, vogliamo contare le occorrenze di ogni parola A cosa serve? In modo simile vengono individuati i trend su twitter [7] Matteo Nardelli 27

28 WordCount in Storm Topologia Classe Java standard: main TopologyBuilder tb = new TopologyBuilder(); tb.setspout("spout", new RandomSentenceSpout(), 5); tb.setbolt("split", new SplitSentence(), 8).shuffleGrouping("spout"); tb.setbolt("count", new WordCount(), 12).fieldsGrouping("split", new Fields("word")); StormSubmitter.submitTopology("word-count", new Config(), tb.createtopology()); Partizionamento Stream Parallelismo componenti API Storm Matteo Nardelli 28

29 WordCount in Storm RandomSentenceSpout (extends BaseRichSpout ) public void nexttuple() { Utils.sleep(100); collector.emit(new Values(getRandomSentence())); } public void declareoutputfields(outputfieldsdeclarer d) { d.declare(new Fields("sentence")); } API Storm Dichiarazione stream WordCount (extends BaseBasicBolt) public void execute(tuple tuple, BasicOutputCollector collector) { String word = tuple.getstringbyfield("word"); Integer count = updatewordcounthashmap(word); collector.emit(new Values(word, count)); } public void declareoutputfields(outputfieldsdeclarer d) { d.declare(new Fields("word", "count")); } Matteo Nardelli Nuova tupla in uscita 29

30 Riferimenti [1] IBM. What is big data? [2] DEBS 2015: Grand Challenge. [3] A. Margara and G. Cugola Processing flows of information: from data stream to complex event processing. In Proc. of the 5th ACM DEBS '11. ACM. [4] T.Condie, N.Conway, P.Alvaro et al MapReduce online. In Proc. of the 7th USENIX conference on NSDI'10. USENIX Association, Berkeley, CA, USA. [5] M. Hirzel, R. Soulé, S. Schneider, B. Gedik, and R. Grimm A catalog of stream processing optimizations. ACM Comput. Surv. 46, 4. [6] Nathan Marz - Storm Starter. [7] M.G. Noll. Real-time Treding Topics With a Distributed Rolling Count Algorithm in Storm: Amazon Kinesis. url: Apache Storm. url: N. Marz and J. Warren Big Data: Principles and Best Practices of Scalable Realtime Data Systems. Manning Publications Co. N. Tatbul, U. Çetintemel, S. Zdonik et al Load shedding in a data stream manager. In Proc of the 29th international conference VLDB '03. VLDB Endowment Kappa Architecture: kappa-architecture.com Apache Flink Architecture: Matteo Nardelli 30