2016-06-20 8 views
8

Mi rendo conto che con NiFi, come lo definisce il documento, "il miglioramento continuo si verifica nella produzione". Quindi questo non si presta a essere usato come uno strumento di sviluppo tradizionale. Comunque per il progetto a cui sto lavorando è stato deciso che questo è lo strumento che useremo, quindi preferirei non discuterne i meriti in quanto mi rendo conto che ci saranno alcuni problemi.Ciclo di vita dello sviluppo per Apache NiFi

Ad esempio, se applico le modifiche in un ambiente esistente (dalla gestione temporanea alla produzione) e ci sono state modifiche in tempo reale nella destinazione, verranno sovrascritte. Quindi ho delle domande su come organizzare il ciclo di vita dello sviluppo.

  • E 'possibile unire le modifiche che sono stati fatto da più sviluppatori in parallelo (unire i file modello XML esportati)? Sto indovinando che la fusione di eventuali modifiche significative potrebbe essere difficile ma non l'ho tentata.
  • Come gestire le versioni modifiche? Suppongo che potresti esportare l'intera configurazione come modello e verificarlo nel controllo della versione?
  • Come distribuire un flusso su un altro server? È possibile implementare una distribuzione NiFi azionaria e quindi aggiornarla dal modello esportato (come menzionato sopra) utilizzando l'API NiFi REST?
  • Come gestire la distribuzione in un ambiente diverso che potrebbe avere configurazione diversa? Dovresti aggiornare il file XML del modello? O posso farlo in modo dinamico da qualcosa come Zookeeper?

risposta

13

Come l'autore originale dell'articolo che ha citato e un membro del PMC Apache NiFi, vorrei iniziare dicendo che stai facendo grandi domande e posso apprezzare da dove vieni. Dovremmo probabilmente migliorare il documento introduttivo per riflettere meglio le preoccupazioni che stai sollevando.

Hai ragione che l'approccio attuale è quello di creare modelli dei flussi e quindi è possibile inviarli al controllo di versione. È anche il caso che la gente automatizza la distribuzione di questi modelli utilizzando script che interagiscono con l'API REST di NiFi. Ma possiamo e dovremmo fare molto più di quanto dobbiamo rendere più semplice il processo di gestione del flusso di dati, indipendentemente dal fatto che tu sia uno sviluppatore che scrive esattamente ciò che verrà distribuito o se sei una persona focalizzata sulle operazioni che deve mettere insieme questi pezzi.

  1. La gestione e il controllo delle versioni dei flussi [1] devono essere più semplici e gestiti centralmente per essere condivisi tra più cluster e ambienti [2].
  2. Dobbiamo assicurarci che i valori specifici dell'ambiente siano facilmente mappati in un dato ambiente ma che i modelli siano ancora portatili [3].
  3. Abbiamo bisogno di rendere l'esperienza utente multiutente/multi-tenant molto più intuitiva e naturale [4].

Gli elementi di 1 e 2 saranno presenti nella prossima versione 1.0 e l'articolo 3 è completamente coperto in quella prossima versione. Nel frattempo, per il caso di più sviluppatori, penso che abbia senso trattare la propria istanza locale come luogo in cui "testare le unità" del loro flusso e quindi utilizzare un ambiente di produzione o di staging condiviso. La cosa fondamentale da tenere a mente è che per molti flussi e con l'approccio di NiFi è ok avere più istanze di un determinato modello di flusso che esegue ognuno di essi alimentato dal feed live dei dati. I risultati/l'output di quel flusso possono essere cablati per essere effettivamente consegnati da qualche parte o semplicemente essere messi a terra.In questo modo è molto simile al modello mentale di ramificazione nel controllo del codice sorgente come Git. Si può scegliere quale si considera "produzione" rispetto a quale flusso sul grafico è semplicemente un ramo di funzionalità in corso, se lo si desidera. Per le persone che provengono da un approccio più tradizionale questo non è ovvio e dobbiamo fare di più per descriverlo e dimostrarlo. Tuttavia, dovremmo anche supportare approcci più tradizionali e questo è ciò che abiliterà alcune delle proposte di funzionalità che ho collegato.

[1] https://cwiki.apache.org/confluence/display/NIFI/Configuration+Management+of+Flows

[2] https://cwiki.apache.org/confluence/display/NIFI/Extension+Registry

[3] https://cwiki.apache.org/confluence/display/NIFI/Variable+Registry

[4] https://cwiki.apache.org/confluence/display/NIFI/Multi-Tentant+Dataflow

+1

Sembra [1], [2] e [3] sono non ancora implementato. Puoi dare un aggiornamento su come risolvere i problemi dichiarati nella versione attuale? Penso che in questo momento le persone stiano semplicemente importando ed esportando modelli. Questo ha alcuni inconvenienti, ad es. nessuna opzione di aggiornamento reale, è sufficiente rimuovere la vecchia versione e leggerne la nuova. –

+0

Hai ragione non esiste una vera opzione di aggiornamento (per un gruppo di processi esistente). Il modello comune oggi è quello di spingere una nuova versione del gruppo di processi, quindi modificare le connessioni che alimentano quel gruppo. Questo può essere fatto con un paio di chiamate REST programmaticamente. Il registro apache nifi per la gestione del flusso, le variabili del gruppo di processi e i componenti con versioni sono tutti ben avviati con gli ultimi due nell'ultima versione. La prossima versione sembra probabile che il registro Apache nifi sia integrato per i flussi con versione e a quel punto si otterrà il vero aggiornamento! Dovrebbe essere molto bello. –

Problemi correlati