Prima di tutto, parliamo di cosa dovrebbe essere Storm . Dalla loro prima pagina otteniamo:
Storm is a distributed realtime computation system. Similar to how Hadoop provides a set of general primitives for doing batch processing, Storm provides a set of general primitives for doing realtime computation. Storm is simple, can be used with any programming language, is used by many companies, and is a lot of fun to use!
E da la loro wiki abbiamo anche:
Unfortunately, these data processing technologies are not realtime systems, nor are they meant to be. There's no hack that will turn Hadoop into a realtime system; realtime data processing has a fundamentally different set of requirements than batch processing.
However, realtime data processing at massive scale is becoming more and more of a requirement for businesses. The lack of a "Hadoop of realtime" has become the biggest hole in the data processing ecosystem.
Storm fills that hole.
Con la "citazione di denaro" che è questa parte:
Storm provides a set of general primitives for doing realtime computation. Storm is simple...
Quindi Storm è nato come qualcosa che doveva essere piccolo, follemente veloce 1 e semplice.
E mentre non ho tirato il file jar per vedere le sue dimensioni effettive, la mia aspettativa basata sulla descrizione del progetto è che il "file jar grasso" è ragionevolmente piccolo. Se non lo è, penso che il progetto abbia perso uno dei suoi obiettivi originali.
Il fatto che stiano tentando di creare un set di primitive per questo tipo di calcolo implica anche che stiano cercando di mantenere le cose concise. O detto in un altro modo, stanno cercando di evitare il rigonfiamento e si stanno concentrando sul fornire solo un nucleo di funzionalità.
Dobbiamo anche considerare la semplicità come uno degli obiettivi principali del progetto. Really Good Simplicity (tm) si estende oltre le chiamate API e nel pacchetto stesso. Non avere molte opzioni di configurazione rende più semplice e semplice la distribuzione del progetto.
Quando arrotoli questi tre elementi insieme, penso che il contrario della tua domanda sia una risposta appropriata. Perché vorresti vuoi l'ulteriore capacità di configurazione che stai descrivendo? Complicherà l'implementazione (quindi è meno semplice), incoraggerà l'allontanamento da un set di funzionalità ristrette e, comunque, ti preoccuperai comunque di una dimensione di file banale.
E questa è la tua risposta architettonica. Non è stato fatto perché non è mai stato concepito per essere supportato in quel modo. L'architettura e il design implicano il taglio di percorsi in modo che la forma possa essere formata o definita. Anche se certamente non ho progettato il pacchetto Storm, posso vedere dove i loro architetti possono aver rifiutato quello che stai chiedendo al fine di raggiungere gli altri obiettivi del progetto.
1 Okay, i sistemi in tempo reale sono meglio definiti come sistemi che garantiranno una risposta entro un determinato periodo di tempo.