Etyczne i ekonomiczne skalowanie skalowania danych


13

Niewiele rzeczy w życiu sprawia mi przyjemność, jak skrobanie uporządkowanych i nieustrukturyzowanych danych z Internetu i wykorzystywanie ich w moich modelach.

Na przykład zestaw narzędzi Data Science Toolkit (lub RDSTKdla programistów R) pozwala mi wyciągać wiele dobrych danych opartych na lokalizacji za pomocą adresów IP lub adresów, a pakiet tm.webmining.pluginfor R tmułatwia natychmiastowe usuwanie danych finansowych i wiadomości. Kiedy wychodzę poza takie (częściowo) ustrukturyzowane dane, zwykle używam XPath.

Jednak ciągle dławią mnie ograniczenia liczby zapytań, które możesz zadawać. Myślę, że Google ogranicza mnie do około 50 000 żądań na 24 godziny, co jest problemem dla Big Data.

Z technicznego punktu widzenia obejście tych limitów jest łatwe - wystarczy zmienić adresy IP i usunąć inne identyfikatory ze swojego środowiska. Jednak dotyczy to zarówno kwestii etycznych, jak i finansowych (tak myślę?).

Czy istnieje rozwiązanie, które przeoczam?

Odpowiedzi:


6

W przypadku wielu interfejsów API (większość, które widziałem) ratelimiting jest funkcją klucza API lub poświadczeń OAuth. (Google, Twitter, NOAA, Yahoo, Facebook itp.) Dobrą wiadomością jest to, że nie musisz fałszować adresu IP, wystarczy wymienić dane uwierzytelniające, gdy osiągną limit prędkości.

Trochę bezwstydna autopromocja tutaj, ale napisałem pakiet python specjalnie do obsługi tego problemu.

https://github.com/rawkintrevo/angemilner

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

Wymaga demona mongodb i zasadniczo tworzysz stronę dla każdego ze swoich kluczy. Masz więc 4 adresy e-mail, każdy z osobnym kluczem. Po załadowaniu klucza określ maksymalną liczbę połączeń dziennie i minimalny czas między kolejnymi uruchomieniami.

Załaduj klucze:

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)

Następnie po uruchomieniu skrobaczki, na przykład interfejsu 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'})

staje się:

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

więc jeśli masz 5 kluczy, l.check_out_api_keyzwraca klucz, który ma najmniejsze użycie i czeka, aż upłynie wystarczająco dużo czasu na jego ponowne użycie.

Na koniec, aby zobaczyć, jak często Twoje klucze były używane / pozostały dostępny dostęp:

pprint(l.summary())

Nie napisałem tego dla R, ponieważ większość skrobania odbywa się w Pythonie (większość MOJE skrobanie). Można go łatwo przenieść.

W ten sposób można technicznie obejść ograniczenia stawek. Etycznie ...

UPDATE Przykład korzysta z Google Places API tutaj


0

Znalazłem fantastyczny sposób na obejście bloków adresów IP jest Amazon AWS (lub Azure lub inna podobna usługa na żądanie). Instancja t2.nano z AWS kosztuje prawie tyle samo, co wysokiej jakości serwer proxy i jest w stanie obsłużyć żądania o ograniczonej szybkości w porządku.

Załóżmy na przykład, że musisz zeskrobać 100 000 stron. Korzystając z AWS CLI, twój program może automatycznie uruchomić 1000 instancji. Nawet jeśli musisz poczekać 2 sekundy między prośbami, nadal możesz to zrobić za 200 sekund. A ile za to płacisz?

W tej chwili cena za instancję t2.nano wynosi 0,0058 USD za godzinę w regionie AWS w Ohio. W tysiącach przypadków to tylko 5,8 USD za godzinę. Ale nie potrzebujesz całej godziny. Twoje zadanie 100 000 stron zostało ukończone w mniej niż 200 sekund. Dodaj trochę czasu na skonfigurowanie skryptu, instalację wymaganych pakietów, skompresowanie wyników i pobranie ich na serwer / komputer, a nadal będziesz używać maksymalnie 10 minut czasu serwera na instancję.

Lub około jednego dolara. 100 000 stron w 200 sekund za jednego dolara. Nie jest zły.

Uwaga: Podczas skalowania w ten sposób należy bardzo uważać, aby nie przypadkowo przeciążyć cel zgarniania. Jeśli uwolnisz tyle siły ognia na jednej stronie internetowej, to około 1000 żądań trafiających na serwer co sekundę. Wystarczająco, aby zabić większość serwerów. Tak więc, mimo że opcja 1000 serwerów może być dobrym pomysłem, jeśli masz zróżnicowaną listę witryn, prawdopodobnie będziesz musiał użyć maksymalnie 10-20 serwerów, jeśli odwiedzasz jedną witrynę.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.