Utilizzo di dati Apache Spark

1

e scusa se la domanda sembra un po 'ingenua.

Attualmente sto leggendo tutorial su Kafka & Spark e c'è qualcosa che non riesco a capire: come sfruttare / esporre i dati ricevuti da Spark.

Ecco cosa sto cercando di capire:

Un sacco di eventi < = > Kafka broker < = > Ricevitore Spark < = > Mappa / Riduci / Trasforma / Aggrega / MLearning < = > Conservazione ?? < = > accesso da parte degli utenti finali ??

Capisco la parte sinistra del flusso di lavoro, hai un flusso di eventi, distribuito da un broker, quindi consumato dai ricevitori Spark.

Ho letto molte caratteristiche di Spark, che è in grado di trasformare gli RDD in altri RDD (fondamentalmente), usando la memoria in-memory (che può anche essere persistente o memorizzata nella cache). Ma allora ??

Non ho in mente un caso d'uso specifico, ma immagino di voler: - mantenere un registro eventi del flusso di eventi "per la cronologia" - aggregare i dati (ad esempio un conteggio semplice) - applica alcuni esempi di apprendimento automatico (diciamo la regressione) - mantieni un valore dell'ultimo evento accaduto per un rapido accesso operativo

Nella mia mente, ciò coinvolge diversi sistemi di archiviazione dei dati, ad esempio Hadoop per i registri, Redis per l'ultimo evento, ecc.

Quindi vorrei che gli utenti fossero in grado di interrogare tutti i dati persistenti: - una semplice API REST per ottenere l'ultimo valore dell'evento - un sistema complicato simile a una query per recuperare il registro eventi - alcune API di reporting per ottenere la previsione dell'algoritmo ML

Come sarebbe stato realizzato tramite Spark? Spark è progettato per tale uso? Spark offre storage persistente per database? O dovrebbero essere diversi consumatori di Kafka dello stesso evento?

Grazie per l'aiuto, sono un po 'confuso.

    
posta Javier92 16.02.2017 - 20:30
fonte

1 risposta

2

I programmi Spark sono solo codice java, scala o python, in modo che possano scrivere dati in tutti gli stessi posti in cui un programma può scriverli. Infatti, la scintilla in realtà non fa nulla a meno che non si scriva il risultato finale da qualche parte con un'operazione di output.

Se il risultato finale di un lavoro spark è piccolo, può essere scritto su un database relazionale o su un servizio Web o qualcosa del genere recuperandolo dagli executors al driver (rdd.collect) e quindi scrivendolo da lì.

Se il risultato finale del lavoro spark è grande, può essere scritto in un negozio distribuito, come HDFS, HBase o Cassandra direttamente dagli esecutori. Se ti guardi in giro puoi trovare esempi di codice per fare ciò che si adatta bene a tutti gli esecutori di scintilla.

Ci sono anche modi per avere un lavoro spark come fonte di dati. Ad esempio, l'hive può essere configurato in modo che esegua le sue query utilizzando un processo spark che si avvia automaticamente e raccoglie i risultati della query sul processo hive. Allo stesso modo, R può lanciare un lavoro spark e usarlo per prelevare ed elaborare i dati prima di riprenderli nel processo R.

Entrambi i processi di flusso e batch eseguono la stessa operazione: leggono un'origine dati in batch sugli esecutori, dove vengono trasformati in base alle operazioni RDD definite, fino a quando ciascun batch raggiunge un'operazione di output o di raccolta quando lascia l'esecutore . La differenza è che un processo batch viene letto da un'origine dati finita e un lavoro in streaming legge da un'origine dati infinita.

Un esempio concreto: il sistema che sto costruendo. Legge i dati del sensore da un flusso kafka (dove viene inviato da vari endpoint del servizio Web) e quindi esegue queste operazioni: (A) normalizza la rappresentazione dei dati del sensore, (B) la aggrega su livelli più elevati, (C) scrive aggregata dati del sensore su un flusso di eventi live in kafka per il monitoraggio in tempo reale e (D) scrivere dati normalizzati e aggregati su hbase per l'interrogazione successiva.

    
risposta data 17.02.2017 - 10:23
fonte

Leggi altre domande sui tag