Spark: elaborazione di più argomenti kafka in parallelo

Question

Sto usando spark 1.5.2. Ho bisogno di eseguire il lavoro spark in streaming con kafka come sorgente di streaming. Ho bisogno di leggere da più argomenti all'interno di kafka e elaborare ogni argomento in modo diverso.

1. È una buona idea farlo nello stesso lavoro? In tal caso, dovrei creare un singolo stream con più partizioni o stream diversi per ogni argomento?
2. Sto usando il vapore diretto kafka. Per quanto ne so, spark lancia ricevitori a lunga durata per ogni partizione. Ho un cluster relativamente piccolo, 6 nodi con 4 core ciascuno. Se avessi molti argomenti e partizioni in ogni argomento, l'efficienza sarebbe influenzata dal fatto che la maggior parte degli esecutori è occupata con ricevitori a lunga esecuzione? Si prega di correggere se la mia comprensione è sbagliato qui

Answer 1

ho fatto le seguenti osservazioni, nel caso in cui il suo utile per qualcuno:

1. In Kafka flusso diretto, i ricevitori non gestiscono attività in esecuzione come lunghi. All'inizio di ogni batch in assoluto, prima i dati vengono letti da kafka negli executors. Una volta letto, la parte di elaborazione prende il sopravvento.
2. Se creiamo un singolo flusso con più argomenti, gli argomenti vengono letti uno dopo l'altro. Inoltre, il filtraggio del dstream per l'applicazione di una logica di elaborazione diversa aggiungerebbe un ulteriore passaggio al lavoro

3. La creazione di più flussi potrebbe essere di aiuto in due modi: 1. Non è necessario applicare l'operazione di filtro per elaborare diversi argomenti in modo diverso. 2. È possibile leggere più flussi in parallelo (anziché uno per uno nel caso di un singolo flusso). Per fare ciò, esiste un parametro di configurazione non documentato spark.streaming.concurrentJobs*. Così, ho deciso di creare più flussi.

   sparkConf.set("spark.streaming.concurrentJobs", "4"); 
   

Answer 2

Penso che la soluzione giusta dipende dal vostro caso d'uso.

Se la logica di elaborazione è la stessa per i dati di tutti gli argomenti, quindi senza dubbio, questo è un approccio migliore.

Se la logica di elaborazione è diversa, credo che si ottiene un singolo RDD da tutti gli argomenti e si deve creare un pairedrdd per ogni logica di elaborazione e gestirlo separatamente. Il problema è che questo crea una sorta di raggruppamento per l'elaborazione e la velocità di elaborazione complessiva sarà determinata dall'argomento che richiede il tempo più lungo per l'elaborazione. Quindi gli argomenti con meno dati devono attendere che i dati di tutti gli argomenti vengano elaborati. Un vantaggio è che se si tratta di un dato di tipo timeseries, l'elaborazione procede insieme e ciò potrebbe essere una buona cosa.

Un altro vantaggio dell'esecuzione di lavori indipendenti è che si ottiene un controllo migliore e si può regolare la condivisione delle risorse. Ad esempio: i lavori che elaborano argomenti con un throughput elevato possono essere allocati a una CPU/memoria più alta.