Scalabilità dei dati in modo etico ed economico

Poche cose nella vita mi fanno piacere come scartare dati strutturati e non strutturati da Internet e usarli nei miei modelli.

Ad esempio, il Data Science Toolkit (o RDSTKper i programmatori R) mi consente di estrarre molti buoni dati basati sulla posizione utilizzando IP o indirizzi e il pacchetto tm.webmining.pluginfor R tmsemplifica la raccolta di dati finanziari e di notizie. Quando vado oltre tali dati (semi) strutturati, tendo a usarli XPath.

Tuttavia, sono costantemente ostacolato dai limiti sul numero di query che è possibile effettuare. Penso che Google mi limiti a circa 50.000 richieste ogni 24 ore, il che è un problema per i Big Data.

Da un punto di vista tecnico aggirare questi limiti è semplice: basta cambiare indirizzo IP ed eliminare altri identificatori dal proprio ambiente. Tuttavia, ciò presenta preoccupazioni sia etiche che finanziarie (penso?).

C'è una soluzione che sto trascurando?

Per molte API (la maggior parte delle quali ho visto) la ratelimitazione è una funzione della chiave API o delle credenziali OAuth. (Google, Twitter, NOAA, Yahoo, Facebook, ecc.) La buona notizia è che non avrai bisogno di falsificare il tuo IP, devi solo scambiare le credenziali quando raggiungono il limite di velocità.

Un po 'di auto-promozione spudorata qui, ma ho scritto un pacchetto Python appositamente per gestire questo problema.

https://github.com/rawkintrevo/angemilner

https://pypi.python.org/pypi/angemilner/0.2.0

Richiede un demone mongodb e fondamentalmente crei una pagina per ognuna delle tue chiavi. Quindi hai 4 indirizzi email ciascuno con una chiave separata assegnata. Quando si carica la chiave, si specificano il numero massimo di chiamate al giorno e il tempo minimo tra gli usi.

Carica chiavi:

from angemilner import APIKeyLibrarian
l= APIKeyLibrarian()
l.new_api_key("your_assigned_key1", 'noaa', 1000, .2)
l.new_api_key("your_assigned_key2", 'noaa', 1000, .2)

Quindi, quando esegui il tuo raschietto, ad esempio l'API NOAA:

url= 'http://www.ncdc.noaa.gov/cdo-web/api/v2/stations' 
payload= {  'limit': 1000,
        'datasetid':  'GHCND', 
        'startdate': '1999-01-01' }

r = requests.get(url, params=payload, headers= {'token': 'your_assigned_key'})

diventa:

url= 'http://www.ncdc.noaa.gov/cdo-web/api/v2/stations'
payload= {  'limit': 1000,
            'datasetid':  'GHCND',
            'startdate': '1999-01-01' }

r = requests.get(url, params=payload, headers= {'token': l.check_out_api_key('noaa')['key']})

quindi se hai 5 chiavi, l.check_out_api_keyrestituisce la chiave che ha il minor numero di usi e attende fino a quando non è trascorso abbastanza tempo per essere riutilizzata.

Infine, per vedere con che frequenza sono state utilizzate le chiavi / utilizzo rimanente disponibile:

pprint(l.summary())

Non ho scritto questo per R perché la maggior parte dei raschiamenti viene eseguita in Python (la maggior parte dei MIEI raschietti). Potrebbe essere facilmente trasferito.

Ecco come puoi tecnicamente aggirare la limitazione della frequenza. Eticamente ...

AGGIORNAMENTO L'esempio utilizza l'API di Google Places qui

Ho trovato un modo fantastico per aggirare i blocchi di indirizzi IP è Amazon AWS (o Azure o qualsiasi altro servizio on demand simile). Un'istanza t2.nano di AWS ha quasi lo stesso valore di un proxy di alta qualità ed è più che in grado di gestire bene le richieste a tariffa ridotta.

Ad esempio, supponiamo che tu debba raschiare 100.000 pagine. Utilizzando l'interfaccia della riga di comando di AWS, il programma può avviare automaticamente 1.000 istanze. Anche se hai bisogno di attendere 2 secondi tra le richieste, avresti comunque finito in 200 secondi. E quanto paghi per questo?

Al momento, il prezzo di un'istanza t2.nano è di $ 0,0058 all'ora nella regione dell'Ohio di AWS. Per un migliaio di casi, questo è solo $ 5,8 l'ora. Ma non hai bisogno dell'intera ora. Il tuo lavoro di 100.000 pagine è stato completato in meno di 200 secondi. Aggiungi un po 'di tempo extra per impostare lo script, installare i pacchetti richiesti, comprimere i risultati e scaricarli sul tuo server / pc e hai comunque utilizzato al massimo 10 minuti di tempo del server per istanza.

O circa un dollaro. 100.000 pagine in 200 secondi per un dollaro. Non male.

Nota: quando si esegue il ridimensionamento in questo modo, è necessario fare molta attenzione a non sovraccaricare accidentalmente l'obiettivo di raschiatura. Se si scatena così tanta potenza di fuoco su un singolo sito Web, si tratta di circa 1.000 richieste che colpiscono il server ogni secondo alternativo. Abbastanza per uccidere la maggior parte dei server web. Quindi, mentre l'opzione 1.000 server potrebbe essere una buona idea se hai un elenco diversificato di siti, probabilmente dovrai utilizzare 10-20 server al massimo se colpisci un singolo sito.