Configurazione topologia Storm

Question

Come si fornisce una configurazione personalizzata a una topologia tempesta? Ad esempio, se ho una topologia che ho creato che si connette a un cluster MySQL e voglio essere in grado di cambiare su quali server ho bisogno di connettermi senza ricompilare, come farei? La mia preferenza sarebbe quella di utilizzare un file di configurazione, ma la mia preoccupazione è che il file stesso non è distribuito nel cluster, quindi non verrà eseguito (a meno che la mia comprensione di come funziona un cluster è difettosa). L'unico modo che ho visto finora per passare le opzioni di configurazione in una topologia di tempesta in fase di esecuzione è tramite un parametro della riga di comando, ma questo è disordinato quando si ottiene un buon numero di parametri.

Un pensiero è stato quello di sfruttare uno script di shell per leggere il file in una variabile e passare il contenuto di tale variabile come stringa alla topologia, ma mi piacerebbe qualcosa di un po 'più pulito, se possibile.

Qualcun altro ha riscontrato questo? Se sì, come lo hai risolto?

EDIT:

Sembra necessario fornire maggiori chiarimenti. Il mio scenario è che ho una topologia che voglio essere in grado di implementare in ambienti diversi senza dover ricompilarlo. Normalmente, creerei un file di configurazione che contiene cose come i parametri di connessione del database e sono passati. Mi piacerebbe sapere come fare qualcosa del genere in Storm.

Answer 1

Ciò che potrebbe effettivamente servire meglio è archiviare la configurazione in un archivio di valori di chiave mutabile (s3, redis, ecc.) E quindi inserirla per configurare una connessione di database che verrà utilizzata (presumo che tu sia già pianificando di limitare la frequenza con cui si parla al database in modo che l'overhead di ottenere questa configurazione non sia un grosso problema). Questo design consente di modificare la connessione al database al volo, senza la necessità di ridistribuire la topologia.

Answer 2

L'idea è che quando si crea la topologia, si creano istanze di spout e bulloni (tra le altre cose) e queste istanze vengono serializzate e distribuite nelle posizioni corrette nel cluster. Se si desidera configurare il comportamento di un beccuccio o di un bullone, lo si fa quando si crea la topologia prima di inviarlo e lo si fa impostando le variabili di istanza sul bullone o sullo spout che, a loro volta, determinano il comportamento configurabile desiderato.

Answer 3

È possibile specificare una configurazione (tramite un file yaml in genere) che si invia con la propria topologia. Come lo gestiamo noi stessi nel nostro progetto abbiamo file di configurazione separati per lo sviluppo e uno per la produzione, e al suo interno memorizziamo il nostro server, redis e db IPs e porte ecc. Quindi quando eseguiamo il comando per costruire il jar e inviare la topologia da utilizzare include il file di configurazione corretto in base all'ambiente di distribuzione. I bulloni e i beccucci leggono semplicemente la configurazione richiesta dalla mappa stormConf che viene passata a loro nel metodo prepare() del bullone.

Da http://storm.apache.org/documentation/Configuration.html:

Ogni configurazione ha un valore di default definito nel defaults.yaml nel codebase Storm. È possibile sovrascrivere queste configurazioni definendo un storm.yaml nel classpath di Nimbus e dei supervisori. Infine, è possibile definire una configurazione specifica per la topologia che si invia insieme alla propria topologia quando si utilizza StormSubmitter. Tuttavia, la configurazione specifica per la topologia può solo sovrascrivere le configurazioni con prefisso "TOPOLOGIA".

Tempesta 0,7.Da 0 a poi è possibile ignorare la configurazione su base per perpendone/per-spout.

Vedrete anche su http://nathanmarz.github.io/storm/doc/backtype/storm/StormSubmitter.html che submitJar e submitTopology viene passato una mappa chiamata conf.

Spero che questo ti permetta di iniziare.

Answer 4

io faccia lo stesso problema come u fatto, e qui è la mia soluzione ingannevole:

utilizzare un file java semplice come il file di configurazione, dicono topo_config.java, sembra che:

package com.xxx 
public class topo_config { 
    public static String zk_host = "192.168.10.60:2181"; 
    public static String kafka_topic = "my_log_topic"; 
    public static int worker_num = 2; 
    public static int log_spout_num = 4; 
    // ... 
} 

Questo file viene messo nella mia cartella di configurazione, e poi scrivere uno script, dire compile.sh che copiarlo il giusto pacchetto e fare le cose di compilazione, appare come:

cp config/topo_config.java src/main/java/com/xxx/ 
mvn package 

La configurazione può avvenire direttamente:

Config conf = new Config(); 
conf.setNumWorkers(topo_config.worker_num); 

Answer 5

Ho risolto questo problema fornendo semplicemente la configurazione in codice:

config.put(Config.TOPOLOGY_WORKER_CHILDOPTS, SOME_OPTS); 

ho cercato di fornire una specifica topologia storm.yaml ma non funziona. Correggimi se lo fai funzionare per usare un storm.yaml.

Aggiornamento:
Per chi vuole sapere che cosa è SOME_OPTS, questo è da Satish Duggana on the Storm mailing list:

Config.TOPOLOGY_WORKER_CHILDOPTS: Opzioni che possono ignorare WORKER_CHILDOPTS per una topologia . È possibile configurare le opzioni Java come la memoria, gc ecc

Nel tuo caso può essere

config.put(Config.TOPOLOGY_WORKER_CHILDOPTS, "-Xmx1g"); 

Answer 6

abbiamo visto lo stesso problema e risolto con l'aggiunta del sotto ogni topologia

config.put(Config.TOPOLOGY_WORKER_CHILDOPTS, "-Xmx4096m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:NewSize=128m -XX:CMSInitiatingOccupancyFraction=70 -XX:-CMSConcurrentMTEnabled -Djava.net.preferIPv4Stack=true"); 

Anche verificato utilizzando l'interfaccia utente Nimbus, viene mostrato come di seguito.

topology.worker.childopts -Xmx4096m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:NewSize=128m -XX:CMSInitiatingOccupancyFraction=70 -XX:-CMSConcurrentMTEnabled -Djava.net.preferIPv4Stack=true