Wybór projektu crawlera open source jest prostszy, gdy rozdzieli się cztery role: ogólne crawlowanie, automatyzację przeglądarki, harmonogram i kolejki oraz parsowanie i przechowywanie. Tekst omawia zadania, typowe problemy integracji i cztery praktyczne kryteria.
Wyszukiwanie crawlerów na GitHubie może zwrócić setki, a nawet tysiące repozytoriów. Wiele osób wybiera projekt, patrząc na liczbę gwiazdek, i zaczyna od najpopularniejszego.
Popularność i dopasowanie do konkretnego zastosowania to dwie różne rzeczy. Nawet bardzo popularny projekt będzie uciążliwy, jeśli jego przeznaczenie nie odpowiada twojemu scenariuszowi. Najprościej zacząć od rozdzielenia odpowiedzialności: system zbierania danych działający stabilnie przez długi czas zwykle składa się z kilku elementów o różnych zadaniach. Gdy wiadomo, za co odpowiada każda część, porównywanie konkretnych implementacji jest znacznie łatwiejsze.
Ogólne frameworki crawlerów: dla stron o stabilnej strukturze
Takie frameworki obsługują planowanie żądań, równoległe pobieranie i potoki danych. Na wejściu otrzymują zestaw adresów URL, a na wyjściu zwracają ustrukturyzowane wyniki. Dojrzałe ekosystemy i mechanizmy middleware pozwalają dodawać własną logikę oraz prowadzić długotrwałe zadania na dużą skalę.
Nie poradzą sobie samodzielnie ze stronami, których treść pojawia się dopiero po wykonaniu JavaScriptu. W takim przypadku początkowa odpowiedź jest jedynie pustą powłoką i trzeba dołączyć silnik renderujący. Dobrze nadają się do stabilnych celów, takich jak strony list, strony szczegółów i otwarte API.
Automatyzacja przeglądarki: dla renderowania i interakcji
Strony wymagające rzeczywistego renderowania, zalogowanej sesji albo kilku kliknięć przed pojawieniem się treści najlepiej obsługiwać przez automatyzację przeglądarki. Takie narzędzia mogą działać na różnych silnikach, mają dojrzałe mechanizmy oczekiwania i pozwalają bezpośrednio przejmować żądania oraz odpowiedzi strony.
Kosztem jest znacznie większe zużycie zasobów niż przy zwykłych żądaniach HTTP. Limit współbieżności zależy głównie od lokalnej pamięci i procesora. Automatyzacja pozostawia też rozpoznawalne cechy, które serwisy z rygorystycznym wykrywaniem mogą zauważyć.
Harmonogram i kolejki: potrzebne, gdy rośnie liczba zadań
Przy niewielu celach wystarczy prosta pętla. Gdy zadań są tysiące, a do tego trzeba kontrolować częstotliwość i ponowienia, przydaje się osobna warstwa harmonogramu: jak ustawiać zadania w kolejce, jaką współbieżność dopuścić, ile czekać przed ponowieniem po błędzie i które zadania porzucić. Umieszczenie całej tej logiki w frameworku crawlera szybko komplikuje kod.
Częstym błędem przy budowie tej warstwy jest użycie kolejki działającej wyłącznie w pamięci procesu. Po restarcie wszystkie oczekujące zadania znikają. Kolejka powinna co najmniej zachowywać dane trwale i umożliwiać sprawdzanie stanu.
Parsowanie i przechowywanie: decydują, czy dane są od razu użyteczne
Pobierany jest HTML, ale potrzebne są konkretne pola. Warstwa parsowania powinna zarządzać regułami ekstrakcji, walidować pola, usuwać duplikaty i zapisywać dane. W przypadku serwisów często zmieniających strukturę warto rozważyć adaptacyjną ekstrakcję, która lokalizuje dane na podstawie cech strony zamiast sztywno zapisanych selektorów, co może zmniejszyć koszty utrzymania.
Po stronie przechowywania ważna jest idempotencja. Ponowienia są czymś normalnym, więc zapisy trzeba deduplikować według unikalnego identyfikatora; w przeciwnym razie duplikaty trafią do dalszych analiz.
Problemy pojawiające się po połączeniu komponentów
Każdy element osobno jest dość prosty. Problemy zwykle pojawiają się na styku komponentów.
- Warstwa harmonogramu ponawia zadanie, ale warstwa parsowania nie usuwa duplikatów i powstają powtórzone wiersze
- Warstwa przeglądarki nie ma limitu współbieżności, zużywa wszystkie lokalne zasoby i powoduje awarię całej partii
- Reguły parsowania są zapisane na sztywno w kodzie, więc każda zmiana serwisu wymaga nowej wersji
- Komponenty używają różnych identyfikatorów tej samej operacji, stany się rozjeżdżają i nie da się wznowić pracy od punktu kontrolnego
Cztery kryteria oceny
Po ustaleniu potrzebnej kategorii użyj tych czterech kryteriów do wyboru konkretnych projektów.
Przy ocenie aktywności utrzymania sprawdzaj częstotliwość commitów i szybkość odpowiedzi na issues z ostatnich miesięcy, a nie łączną liczbę gwiazdek. Projekt, który nie jest już utrzymywany, może przestać działać natychmiast po zmianie serwisu docelowego.
Dokumentacja i przykłady decydują o koszcie wejścia. Niejasna dokumentacja lub przykłady ograniczone do najprostszych przypadków często oznaczają dłuższą naukę, niż zakładano.
W kwestii rozszerzalności sprawdź dostępne punkty integracji: czy można zmienić proxy, podłączyć własny silnik renderujący albo zastąpić warstwę przechowywania. Projekty z wyraźnymi punktami rozszerzeń pozwalają później wprowadzać zmiany bez modyfikowania kodu źródłowego.
Łatwo pominąć ryzyka licencyjne i zgodność. Przed użyciem komercyjnym sprawdź typ licencji i unikaj licencji niezgodnych z planowanym zastosowaniem. Oceń także zakres zbierania, częstotliwość żądań i warunki serwisu docelowego; te kwestie są niezależne od jakości technicznej frameworka.
Warstwa środowiska to osobny poziom
Framework rozwiązuje problem sposobu pobierania danych, ale nie tożsamości i skali. Gdy zadania wymagają logowania, rozdzielenia regionów albo równoległego użycia wielu kont, uruchamianie wszystkiego w jednym środowisku przeglądarki powoduje dwa problemy: sesje wzajemnie się zanieczyszczają, ponieważ pliki cookie i pamięć lokalna się nakładają, a serwis docelowy może potraktować niezależne zadania jako tę samą grupę odwiedzin.
Dojrzałym podejściem jest potraktowanie środowisk przeglądarki jako niezależnej warstwy zasobów. Zadania pobierają środowisko z puli i zwalniają je po zakończeniu. W takiej architekturze PurpleMark pełni właśnie tę rolę, udostępniając środowiska, które można tworzyć grupowo, wiązać z niezależnymi wyjściami sieciowymi i sprawdzać ich stan.
Granice zgodności
Przestrzegaj zasad robots i warunków korzystania z serwisu docelowego, nie zbieraj danych osobowych, nie omijaj technicznych zabezpieczeń i kontroluj częstotliwość żądań, aby nie zakłócać normalnego działania usługi. Wybór projektu rozwiązuje problem efektywności; te oceny określają, czy dane działanie w ogóle powinno być wykonywane.
