Ethisch und kosteneffiziente Skalierung von Datenproblemen

Nur wenige Dinge im Leben machen mir Spaß, strukturierte und unstrukturierte Daten aus dem Internet zu kratzen und in meinen Modellen zu verwenden.

Mit dem Data Science Toolkit (oder RDSTKfür R-Programmierer) kann ich beispielsweise viele gute standortbasierte Daten mithilfe von IPs oder Adressen abrufen, und mit dem Paket tm.webmining.pluginfür R lassen sich tmFinanz- und Nachrichtendaten direkt abrufen. Wenn ich über solche (halb-) strukturierten Daten hinausgehe, tendiere ich dazu, sie zu verwenden XPath.

Die Anzahl der Abfragen, die Sie stellen dürfen, ist jedoch ständig begrenzt. Ich denke, Google beschränkt mich auf ungefähr 50.000 Anfragen pro 24 Stunden, was ein Problem für Big Data ist.

Aus technischer Sicht ist es einfach, diese Grenzen zu umgehen - wechseln Sie einfach die IP-Adresse und entfernen Sie andere Identifikatoren aus Ihrer Umgebung. Dies ist jedoch sowohl ethisch als auch finanziell bedenklich (glaube ich?).

Gibt es eine Lösung, die ich übersehen habe?

Für viele APIs (die meisten, die ich gesehen habe) ist das Ratelimiting eine Funktion Ihres API-Schlüssels oder Ihrer OAuth-Berechtigungsnachweise. (Google, Twitter, NOAA, Yahoo, Facebook usw.) Die gute Nachricht ist, dass Sie Ihre IP-Adresse nicht fälschen müssen, sondern lediglich die Anmeldeinformationen austauschen müssen, sobald sie das Ratenlimit erreicht haben.

Ein bisschen schamlose Eigenwerbung, aber ich habe ein Python-Paket geschrieben, um dieses Problem zu lösen.

https://github.com/rawkintrevo/angemilner

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

Es erfordert einen Mongodb-Daemon und im Grunde genommen erstellen Sie eine Seite für jeden Ihrer Schlüssel. Sie haben also 4 E-Mail-Adressen, denen jeweils ein eigener Schlüssel zugewiesen ist. Wenn Sie den Schlüssel eingeben, geben Sie die maximale Anzahl von Anrufen pro Tag und die minimale Zeit zwischen den Verwendungen an.

Schlüssel laden:

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)

Dann, wenn Sie Ihren Schaber zum Beispiel die NOAA-API ausführen:

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

wird:

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

Wenn Sie also über 5 Schlüssel verfügen l.check_out_api_key, wird der am wenigsten verwendete Schlüssel zurückgegeben und es wird gewartet, bis genügend Zeit verstrichen ist, bis er wieder verwendet werden kann.

Um zu sehen, wie oft Ihre Schlüssel verwendet wurden / wie oft sie noch verwendet werden können, gehen Sie wie folgt vor:

pprint(l.summary())

Ich habe dies nicht für R geschrieben, da das meiste Scraping in Python ausgeführt wird (der größte Teil von MEINEM Scraping). Es könnte leicht portiert werden.

So können Sie Ratenbeschränkungen technisch umgehen. Ethisch ...

UPDATE Das Beispiel verwendet Google Places API hier

Ich habe eine fantastische Möglichkeit gefunden, um IP-Adressblöcke zu umgehen: Amazon AWS (oder Azure oder ein ähnlicher On-Demand-Dienst). Eine t2.nano-Instanz von AWS kostet fast dasselbe wie ein qualitativ hochwertiger Proxy und ist mehr als in der Lage, ratenbegrenzte Anforderungen zu bearbeiten.

Nehmen wir zum Beispiel an, Sie müssen 100.000 Seiten kratzen. Mit der AWS CLI kann Ihr Programm automatisch 1.000 Instanzen starten. Selbst wenn Sie zwischen den Anforderungen 2 Sekunden warten müssen, sind Sie in 200 Sekunden fertig. Und wie viel zahlst du dafür?

Derzeit liegt der Preis für eine t2.nano-Instanz in der Region Ohio von AWS bei 0,0058 USD pro Stunde. Für tausend Fälle sind das nur 5,8 US-Dollar pro Stunde. Aber du brauchst nicht die ganze Stunde. Ihr Auftrag von 100.000 Seiten wurde in weniger als 200 Sekunden erledigt. Fügen Sie zusätzliche Zeit hinzu, um das Skript einzurichten, die erforderlichen Pakete zu installieren, die Ergebnisse zu komprimieren und auf Ihren Server / PC herunterzuladen, und Sie haben immer noch höchstens 10 Minuten Serverzeit pro Instanz verbraucht.

Oder ungefähr einen Dollar. 100.000 Seiten in 200 Sekunden für einen Dollar. Nicht schlecht.

Hinweis: Wenn Sie so skalieren, müssen Sie sehr vorsichtig sein, damit das Abstreifziel nicht versehentlich überlastet wird. Wenn Sie so viel Feuerkraft auf einer einzelnen Website entfesseln, treffen etwa 1.000 Anfragen jede zweite Sekunde auf den Server. Genug, um die meisten Webserver zu töten. Während die Option mit 1.000 Servern eine gute Idee ist, wenn Sie eine abwechslungsreiche Liste von Sites haben, müssen Sie wahrscheinlich maximal 10-20 Server verwenden, wenn Sie eine einzelne Site treffen.