5

Sto iniziando a delineare la struttura di un sito di servizio di informazioni quantitative-finance scritto in Python (3.x spero) e sono giunto alla conclusione - correggimi se io ' m sbagliato - che dovrò utilizzare sia la libreria di rete dell'eventolet e la libreria di multiprocessing.domande multithreading e multiprocessing per il sito quant

Una parte del sistema è fondamentalmente un lavoro cron eseguito in background, che esamina il mercato azionario e altri dati finanziari dopo la chiusura del mercato, esegue l'apprendimento automatico e calcoli quant, quindi inserisce le previsioni in un semplice database o forse anche in un file delimitato da virgola piatta. (Gli argomenti vengono quindi passati tra le sezioni del sistema tramite file.)

Comprendo che l'eventlet può essere utilizzato per l'I/O non bloccante in modo che una bella zuppa o scrapy possa racchiudere le informazioni da molti siti contemporaneamente (sorta di) e la libreria di multiprocessing può consentire agli algoritmi di apprendimento automatico/quantizzazione di eseguire i calcoli su tutti i dati di magazzino in parallelo come processi separati.

Per visualizzare le previsioni, gli utenti accedono all'altra parte del sistema creata con Flask che accede al database e visualizza le previsioni.

Suppongo che tutte queste routine di librerie e di thread combinati/multiprocessing si accompagnino l'una con l'altra? Userò pythonanywhere.com come host e sembra che abbiano un bel po 'di "batterie incluse". Naturalmente, quando il test sarà terminato, probabilmente dovrò aggiornare il numero di "lavoratori" per alimentare il sito finale distribuito.

Eventuali insidie ​​nel mixare thread e multiprocessing in qualcosa di così complicato?

+0

non può rispondere alla tua domanda conclusivamente come non ho provato esattamente, ma in generale è bene avere più thread e processi multipli. – 101

+0

Non sono sicuro di quanto strettamente * gevent * sia correlato a * eventlet *, ma per supportare il multiprocessing da * gevent * quando i thread sono rattoppati, ho dovuto usare il * subprocess * per la comunicazione e * pickle * per serializzazione perché il multiprocessing non è supportato da * gevent *. – cpburnz

+0

PythonAnywhere dev. Qui. Una delle cose che devi sapere su PythonAnywhere è che limitiamo i thread e i processi che gli utenti possono avviare, quindi probabilmente avrai bisogno di usare un pool thread/process. Credo che il multiprocessing lo abbia integrato. – Glenn

risposta

2

Solo alcuni pensieri generali che non poteva essere inserito nella sezione commenti:

  1. Scrapy ha già alcuni modi per elaborare concurrent richieste di rete via contorta. Questo significa che potresti non aver bisogno di usare l'eventlet? Naturalmente, questo dipende da come esattamente si sta facendo il raschiamento/che cosa è esattamente necessario per raschiare. Da quello che ho provato molto tempo fa (forse sono totalmente sbagliato), se dici selenio necessario per raschiare le risposte javascript, allora è difficile farlo in concomitanza con scrapy. Ma se stai solo ottenendo richieste con urllib o qualcosa del genere (ad es. Per le API), allora penso che sia abbastanza rottame.

  2. Sono d'accordo con il tuo commento: la parte di scraping web sarà sempre soggetta a errori, quindi è assolutamente necessario separare le parti di raschiatura e quelle di previsione. È necessario prendere in considerazione gli errori non riusciti (ad esempio: cosa succede se il sito Web è inattivo, o cosa succede se si ottengono dati errati) e pulire tutti i dati prima di inserire i dati puliti nel proprio database e quindi eseguire (separatamente) il materiale di apprendimento automatico su quei dati.

Ma una cosa importante qui è che è sicuramente bisogno di un database tra la raschiatura e la macchina di apprendimento (non si può semplicemente passare in memoria o tramite csv come da te suggerito). Innumerevoli ragioni, un paio sono:

  • risparmiare sui tuoi graffi (non sarà necessario scaricare più giorni di dati ogni volta, proprio il giorno più recente)
  • ti danno il backup e dati storici nel caso in cui il vostro web i graffi non sono più disponibili (ad esempio: diciamo che stai raschiando gli ultimi 365 giorni) e se la tua fonte di informazioni ti da solo gli ultimi 365 giorni ma improvvisamente vuoi 700 giorni?Vuoi avere salvato i dati dai tuoi precedenti scrap da qualche parte)
  • essere molto più veloce/migliore/meno flakey: avere un db indicizzato correttamente sarà probabilmente altrettanto importante se non più importante di qualsiasi tipo di elaborazione parallela del tuo apprendimento macchina algoritmo.

btw Django anche opere really well con Scrapy ...