Échelle éthique et rentable Scrapes de données

Peu de choses dans la vie me font plaisir comme gratter des données structurées et non structurées d'Internet et les utiliser dans mes modèles.

Par exemple, le Data Science Toolkit (ou RDSTKpour les programmeurs R) me permet d'extraire de nombreuses bonnes données géolocalisées en utilisant des adresses IP ou des adresses et le package tm.webmining.pluginfor R tmfacilite le grattage des données financières et d'actualités. En allant au-delà de ces données (semi-) structurées, j'ai tendance à utiliser XPath.

Cependant, je suis constamment limité par le nombre de requêtes que vous êtes autorisé à effectuer. Je pense que Google me limite à environ 50 000 demandes par 24 heures, ce qui est un problème pour les Big Data.

D'un point de vue technique , il est facile de contourner ces limites - il suffit de changer d'adresse IP et de purger les autres identifiants de votre environnement. Cependant, cela présente à la fois des préoccupations éthiques et financières (je pense?).

Y a-t-il une solution que je néglige?

Pour de nombreuses API (la plupart que j'ai vues), la limitation de rapport est fonction de votre clé API ou de vos informations d'identification OAuth. (Google, Twitter, NOAA, Yahoo, Facebook, etc.) La bonne nouvelle est que vous n'aurez pas besoin d'usurper votre adresse IP, il vous suffit d'échanger vos informations d'identification car elles atteignent leur limite de taux.

Un peu d'auto promotion sans vergogne ici, mais j'ai écrit un package python spécifiquement pour gérer ce problème.

https://github.com/rawkintrevo/angemilner

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

Il nécessite un démon mongodb et, fondamentalement, vous créez une page pour chacune de vos clés. Vous avez donc 4 adresses e-mail chacune avec une clé distincte attribuée. Lorsque vous chargez la clé, vous spécifiez le nombre maximal d'appels par jour et le temps minimum entre les utilisations.

Clés de chargement:

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)

Ensuite, lorsque vous exécutez votre grattoir, par exemple, 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'})

devient:

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']})

donc si vous avez 5 clés, l.check_out_api_keyretourne la clé qui a le moins d'utilisations et attend jusqu'à ce que suffisamment de temps se soit écoulé pour qu'elle soit réutilisée.

Enfin, pour voir à quelle fréquence vos clés ont été utilisées / utilisation restante disponible:

pprint(l.summary())

Je n'ai pas écrit ceci pour R car la plupart des grattages se font en python (la plupart de mes grattages). Il pourrait être facilement porté.

Voilà comment vous pouvez techniquement contourner la limitation de taux. Ethiquement ...

MISE À JOUR L'exemple utilise l'API Google Adresses ici

J'ai trouvé un moyen fantastique de contourner les blocs d'adresses IP: Amazon AWS (ou Azure ou tout autre service à la demande similaire). Une instance t2.nano d'AWS coûte presque le même prix qu'un proxy de haute qualité et est plus que capable de gérer très bien les requêtes à débit limité.

Par exemple, disons que vous devez supprimer 100 000 pages. À l'aide de l'AWS CLI, votre programme peut démarrer automatiquement 1 000 instances. Même si vous devez attendre 2 secondes entre les demandes, vous aurez quand même terminé en 200 secondes. Et combien payez-vous pour cela?

À l'heure actuelle, le prix d'une instance t2.nano est de 0,0058 USD par heure dans la région Ohio d'AWS. Pour mille cas, c'est seulement $ 5,8 heure. Mais vous n'avez pas besoin de toute l'heure. Votre travail de 100 000 pages a été terminé en moins de 200 secondes. Ajoutez du temps supplémentaire pour configurer le script, installer les packages requis, compresser les résultats et les télécharger sur votre serveur / PC et vous avez toujours utilisé au plus 10 minutes de temps de serveur par instance.

Ou environ un dollar. 100 000 pages en 200 secondes pour un dollar. Pas mal.

Remarque: lors d'une mise à l'échelle comme celle-ci, vous devez faire très attention à ne pas surcharger accidentellement la cible de raclage. Si vous libérez autant de puissance de feu sur un seul site Web, cela représente environ 1 000 demandes atteignant le serveur toutes les deux secondes. De quoi tuer la plupart des serveurs web. Ainsi, bien que l'option 1000 serveurs puisse être une bonne idée si vous avez une liste diversifiée de sites, vous devrez probablement utiliser 10-20 serveurs au maximum si vous visitez un seul site.