Spark Filati Architettura

Question

avevo una domanda per quanto riguarda questa immagine in un tutorial che stavo seguendo. Quindi, basandosi su questa immagine in un'architettura basata su filato, l'esecuzione di un'applicazione spark assomiglia a questa:

Prima si dispone di un driver in esecuzione su un nodo client o su un nodo dati. In questo driver (simile a un driver in java?) Consiste nel codice (scritto in java, python, scala, ecc.) Che invii al contesto Spark. Quindi quel contesto spark rappresenta la connessione a HDFS e inoltra la richiesta al gestore risorse nell'ecosistema Hadoop. Quindi il gestore risorse comunica con il nodo Nome per determinare quali nodi di dati nel cluster contengono le informazioni richieste dal nodo client. Il contesto spark mette anche un executor sul nodo worker che eseguirà le attività. Quindi il gestore nodi avvierà l'esecutore che eseguirà le attività assegnate dallo Spark Context e restituirà i dati richiesti dal client da HDFS al driver.

L'interpretazione sopra è corretta?

Inoltre, un driver invia tre esecutori a ciascun nodo di dati per recuperare i dati dall'HDFS, poiché i dati in HDFS vengono replicati 3 volte su vari nodi di dati?

Answer 1

La tua interpretazione è vicina alla realtà ma sembra che tu sia un po 'confuso su alcuni punti.

Vediamo se posso renderlo più chiaro a voi.

Supponiamo di avere l'esempio di conteggio delle parole in Scala.

object WordCount { 
    def main(args: Array[String]) { 
     val inputFile = args(0) 
     val outputFile = args(1) 
     val conf = new SparkConf().setAppName("wordCount") 

     val sc = new SparkContext(conf) 

     val input = sc.textFile(inputFile) 

     val words = input.flatMap(line => line.split(" ")) 

     val counts = words.map(word => (word, 1)).reduceByKey{case (x, y) => x + y} 

     counts.saveAsTextFile(outputFile) 
    } 
} 

In ogni lavoro scintilla si dispone di una fase di inizializzazione in cui si crea un oggetto SparkContext fornendo alcune configurazione come la nomeapp e il maestro, poi si legge un fileInput, si elaborano e si salva il risultato della vostra trasformazione su disco. Tutto questo codice è in esecuzione nel Driver tranne per le funzioni anonime che rendono l'elaborazione effettiva (le funzioni passate a .flatMap, .map e reduceByKey) e le funzioni I/O textFile e saveAsTextFile che sono in esecuzione in remoto sul cluster.

Qui il DRIVER è il nome assegnato a quella parte del programma in esecuzione nello stesso nodo in cui si invia il codice con spark-submit (nella foto si chiama Nodo client). È possibile inviare il codice da qualsiasi computer (ClientNode, WorderNode o anche MasterNode) a condizione che si abbia accesso diretto e accesso di rete al proprio cluster YARN. Per semplicità supporrò che il nodo Client sia il tuo laptop e che il cluster Yarn sia fatto di macchine remote.

Per semplicità tratterò da questa immagine Zookeeper poiché viene utilizzata per fornire l'alta disponibilità a HDFS e non è coinvolta nell'esecuzione di un'applicazione spark. Devo menzionare che Yarn Resource Manager e HDFS Namenode sono ruoli in Yarn e HDFS (in realtà sono processi in esecuzione all'interno di una JVM) e potrebbero vivere sullo stesso nodo master o su macchine separate. Anche i gestori del nodo filato e i nodi dati sono solo ruoli, ma in genere vivono sulla stessa macchina per fornire la località dei dati (elaborazione vicina alla posizione in cui i dati sono archiviati).

Quando si invia l'applicazione, contattare innanzitutto il gestore delle risorse che insieme al NameNode tenta di trovare i nodi Worker disponibili su cui eseguire le attività spark. Per sfruttare il principio della localizzazione dei dati, il Resource Manager preferirà i nodi worker che memorizzano sullo stesso computer blocchi HDFS (una qualsiasi delle 3 repliche per ogni blocco) per il file che si deve elaborare. Se non sono disponibili nodi di lavoro con quei blocchi, utilizzerà qualsiasi altro nodo di lavoro.In questo caso, poiché i dati non saranno disponibili localmente, i blocchi HDFS devono essere spostati sulla rete da uno qualsiasi dei nodi Data al gestore nodi che esegue l'attività spark. Questo processo è fatto per ogni blocco che ha creato il tuo file, quindi alcuni blocchi potrebbero essere trovati localmente, alcuni devono essere spostati.

Quando ResourceManager trova un nodo di lavoro disponibile, contatta il NodeManager su quel nodo e chiede di creare un Jarn Container (JVM) in cui eseguire un programma di esecuzione scintilla. In altre modalità cluster (Mesos o Standalone) non avrai un contenitore di filati ma il concetto di spark executor è lo stesso. Uno spark executor è in esecuzione come JVM e può eseguire più attività.

Il driver in esecuzione sul nodo client e le attività in esecuzione su scintilla esecutori continuano a comunicare per poter eseguire il lavoro. Se il driver è in esecuzione sul laptop e il laptop si blocca, perderai la connessione alle attività e il tuo lavoro avrà esito negativo. Questo è il motivo per cui quando la scintilla è in esecuzione in un cluster di filati, è possibile specificare se si desidera eseguire il driver sul laptop "--deploy-mode = client" o sul cluster di filati come un altro contenitore di filati "--deploy-mode = cluster ". Per maggiori dettagli guarda spark-submit