SRP nell'impostazione "big data"

Question

SRP nell'impostazione "big data"

#1 da (1 voti)
#2 da (0 voti)

2

Abbiamo una base di codice al lavoro che:

Ingerisce (in basso) migliaia di piccoli file. Ciascuno di questi file di input contiene circa 50k "micro-articoli"
Questi "micro-elementi" vengono quindi raggruppati insieme per trovare "macro-elementi"
Le "macro-voci" diventano l'input per una varietà di altri importanti calcoli e analisi aziendali. Questi macro-articoli sono la linfa vitale della nostra organizzazione.
Tutto questo funziona usando la libreria Apache's Crunch (che è supportata da Hadoop)

È vero che alcuni di questi passaggi sopra sono difficili da fare senza Crunch. Il "problema del clustering" in particolare è probabilmente impossibile da eseguire rigorosamente in memoria su una macchina. Ci sono troppi elementi che devono essere considerati nella fase di clustering.

Potresti anche sostenere che abbiamo così tanti dati che non vale la pena avere una soluzione che non sia costruita per la scala.

Detto questo, mi sento come se il nostro code-break interrompesse l'SRP a destra ea sinistra. Ad esempio, gli algoritmi che analizzano i file di input non possono essere facilmente separati dalle classi "fai enmasse" di Crunch. Significato se ho solo un file di input non posso analizzarlo senza eseguire un lavoro di Crunch su larga scala. Inoltre, non posso accedere o testare facilmente "l'algoritmo di clustering" e gli "importanti calcoli aziendali".

Si tratta di un problema comune nello spazio dei big data? SRP esce dalla finestra quando ho tonnellate di dati?

Sta cercando di separare questo codice in due progetti A e B in un obiettivo ragionevole? Suppongo che Project (A) definisca e test correttamente gli algoritmi di analisi, la logica di clustering e l'importante computazione aziendale mentre il progetto (B) dipenderà dal progetto (A) e utilizzerà Crunch per fare tutte queste cose su larga scala. / p>

Parte del motivo per cui voglio sostenere una separazione rigorosa è di migliorare notevolmente il testing su tutti i calcoli non distribuiti. È orribile quando un lavoro di Crunch distribuito fallisce ed è difficile capire perché.

java single-responsibility distributed-computing hadoop

posta Ivan 05.08.2016 - 16:14

fonte

2 risposte

Leggi altre domande sui tag java single-responsibility distributed-computing hadoop

La programmazione integrata impedisce l'allocazione dinamica Multi-Tenancy è un'opzione percorribile in qualsiasi Framework RAD Java?

score 1 · Answer 1

L'SRP avviene nel modulo (o nella libreria), nel pacchetto (o nello spazio dei nomi), nella classe e nel livello di funzione.

Ciò significa:

Una biblioteca ha una ragione per cambiare. Ad esempio, si crea una libreria di rete. I motivi validi per il cambiamento includono: supporto di un nuovo protocollo, correzione di un bug in un protocollo esistente. Motivi di modifica invalidi: modifica degli endpoint client o server.
Uno spazio dei nomi ha una ragione per cambiare: fare un passo avanti nella libreria di rete. Lo spazio dei nomi MyCompany.Networking.Http dovrebbe cambiare solo in relazione alle modifiche all'implementazione di HTTP. Non dovrebbe interessare FTP o SMTP, si cambierebbe solo il pacchetto per supportare le modifiche a HTTP, i bug nell'implementazione o le nuove versioni del protocollo.
Una classe ha un solo motivo per cambiare: MyCompany.Networking.Http.HttpClient dovrebbe ... beh, hai ottenuto l'immagine.

Se Crunch è solo un'utilità che il tuo sistema utilizza per ridimensionare le operazioni, allora sì, direi che le operazioni stesse dovrebbero essere implementate separatamente dal crunch.

La divisione che hai citato ha perfettamente senso logico. Le operazioni stesse sarebbero vincolate da SRP a cambiare solo per supportare i cambiamenti nella tua logica aziendale. Il coordinatore farebbe l'orchestrazione tra le tue operazioni e Crunch. (Se ne senti la necessità, puoi proteggere il coordinatore dai cambiamenti nel fatto che tu usi il crunch per l'elaborazione su larga scala ma una regola empirica per SRP è che tu proteggi contro una classe di modifiche man mano che diventano applicabili. Vale a dire se le possibilità di il passaggio dei motori di attività è ridotto a zero, non è molto utile in quanto fornisce l'astrazione da esso.

score 0 · Answer 2

Non sono un programmatore Java, ma il problema che hai descritto è più generale.

In questo momento hai una soluzione che non è affidabile al 100%. Da quello che ho capito, devi mantenerlo . Esiste un debito tecnico che vorresti pagare per ridurre il dolore che stai vivendo durante le "sessioni di recupero".

Prova ad estrarre singoli pezzi dal codice base. Di solito, dopo aver giocato con il codice, lo capisci meglio e ti senti più sicuro di cosa sia il refactoring. Separare ogni singola riga di codice è una vittoria per te.

In seguito vedresti schemi o gruppi di funzioni simili. Uniscili in una classe e forniscili come DI.