Co to jest web scraping i jak działa automatyczne pobieranie danych z internetu?

Web scraping to automatyczne pobieranie informacji znajdujących się na stronach internetowych i przekształcanie ich do postaci, którą można dalej analizować, zapisywać lub wykorzystywać w innych systemach.

Zamiast ręcznie otwierać setki podstron, kopiować dane i wklejać je do arkusza, odpowiednio przygotowany program może wykonać te czynności automatycznie.

Scraper może na przykład odwiedzić katalog produktów, odczytać nazwy, ceny, dostępność i parametry, a następnie zapisać informacje do pliku CSV, bazy danych albo przekazać je bezpośrednio do innego systemu.

Sam mechanizm brzmi prosto, ale profesjonalny web scraping jest znacznie bardziej złożony niż pobranie kodu HTML i wyszukanie w nim kilku fragmentów tekstu.

Strony się zmieniają, dane mogą być ładowane przez JavaScript, serwery stosują limity, informacje bywają rozproszone pomiędzy wieloma podstronami, a niektórych danych nie wolno lub nie powinno się automatycznie pozyskiwać.

Co oznacza web scraping?

Angielskie określenie web scraping można rozumieć jako automatyczne wydobywanie danych ze stron internetowych.

Proces składa się zazwyczaj z kilku etapów:

1. program pobiera stronę internetową,
2. analizuje jej strukturę,
3. odnajduje interesujące informacje,
4. oczyszcza i normalizuje dane,
5. zapisuje wynik,
6. przechodzi do kolejnej strony.

Scraper nie musi zachowywać całej strony.

Może interesować go wyłącznie niewielka część informacji, na przykład:

• nazwa produktu,
• cena,
• EAN,
• SKU,
• dostępność,
• adres URL,
• parametry techniczne.

Wynikiem pracy nie jest wtedy kopia strony, ale uporządkowany zbiór danych.

Jak działa web scraping?

Najprostszy scraper działa podobnie do bardzo szybkiego użytkownika wykonującego powtarzalne czynności.

Otwiera adres, pobiera zawartość, odszukuje określone elementy i zapisuje ich wartości.

Przykładowo na stronie produktu znajduje się:

• nazwa w nagłówku,
• cena w określonym elemencie HTML,
• kod produktu w sekcji parametrów,
• status dostępności obok przycisku zakupu.

Scraper może posiadać reguły mówiące:

• pobierz tekst z nagłówka produktu,
• odczytaj cenę,
• znajdź w parametrach EAN,
• sprawdź status magazynowy.

Następnie zapisuje rekord i przechodzi do kolejnego adresu.

HTML jako źródło danych

Klasyczny web scraping najczęściej zaczyna się od kodu HTML strony.

HTML opisuje strukturę dokumentu i zawiera informacje wyświetlane użytkownikowi.

Program może analizować między innymi:

• nagłówki,
• akapity,
• linki,
• listy,
• atrybuty elementów,
• metadane,
• dane strukturalne.

Problem polega na tym, że kod strony został zazwyczaj przygotowany dla przeglądarki i użytkownika, a nie dla scrapera.

Nazwa produktu może więc być bardzo łatwa do znalezienia albo ukryta w skomplikowanej strukturze wygenerowanej przez framework JavaScript.

Selektory w web scrapingu

Scraper musi wiedzieć, które elementy strony mają zostać odczytane.

Do wskazywania konkretnych fragmentów dokumentu można wykorzystywać między innymi selektory CSS lub XPath.

Przykładowo program może otrzymać informację:

znajdź element reprezentujący cenę i pobierz znajdujący się w nim tekst.

To działa dobrze, dopóki struktura strony pozostaje taka sama.

Jeżeli właściciel serwisu zmieni szablon, nazwę klasy albo układ produktu, scraper może nagle przestać znajdować dane.

Dlaczego scrapery przestają działać?

Jedną z najważniejszych cech web scrapingu jest zależność od zewnętrznej strony.

Nie kontroluję kodu serwisu, z którego pobierane są informacje.

Jego właściciel może w każdej chwili:

• zmienić HTML,
• przebudować stronę,
• zmienić sposób ładowania danych,
• dodać zabezpieczenia,
• zmienić strukturę adresów,
• usunąć określone informacje.

Dlatego dobrze zaprojektowany scraper powinien nie tylko pobierać dane, ale również wykrywać, że coś przestało działać prawidłowo.

Scraping stron wykorzystujących JavaScript

Nie każda informacja znajduje się bezpośrednio w HTML otrzymanym z serwera.

Współczesna strona może najpierw wysłać podstawowy dokument, a później przy pomocy JavaScriptu pobrać dodatkowe dane.

Użytkownik widzi produkt i cenę w przeglądarce, ale prosty scraper pobierający wyłącznie początkowy HTML może ich nie znaleźć.

W takim przypadku trzeba ustalić, skąd rzeczywiście pochodzą dane.

Możliwe są między innymi dwa podejścia:

• odtworzenie zapytania wykorzystywanego przez stronę do pobrania danych,
• uruchomienie przeglądarki sterowanej programowo i wykonanie JavaScriptu.

Headless browser

Headless browser to przeglądarka, którą można sterować automatycznie bez klasycznego interfejsu widocznego dla użytkownika.

Może:

• otworzyć stronę,
• wykonać JavaScript,
• kliknąć przycisk,
• przewinąć dokument,
• poczekać na załadowanie danych,
• odczytać końcową zawartość strony.

Takie podejście pozwala obsługiwać bardziej skomplikowane aplikacje.

Jest jednak znacznie cięższe od zwykłego pobierania dokumentów HTML.

Uruchomienie dziesiątek lub setek pełnych instancji przeglądarki wymaga więcej procesora, pamięci i czasu.

Web scraping a API

Jeżeli potrzebne dane są dostępne przez oficjalne API, zazwyczaj preferuję właśnie API zamiast scrapingu.

API zostało przygotowane specjalnie do komunikacji pomiędzy systemami.

Może zwracać uporządkowane dane, na przykład:

• JSON,
• XML,
• inne przewidywalne formaty.

Web scraping musi natomiast odczytywać informacje z interfejsu zaprojektowanego przede wszystkim dla człowieka.

Dlaczego API jest zwykle stabilniejsze?

Jeżeli właściciel serwisu zmieni kolor, układ albo szablon strony, API może pozostać dokładnie takie samo.

Scraper analizujący HTML może przestać działać już po niewielkiej zmianie struktury.

API może również posiadać:

• dokumentację,
• autoryzację,
• wersjonowanie,
• limity zapytań,
• określony sposób raportowania błędów.

Scraping jest więc szczególnie przydatny wtedy, gdy odpowiednie API nie istnieje albo nie udostępnia potrzebnych danych.

Web scraping a crawler

Scraper i crawler są często mylone.

Crawler przede wszystkim odkrywa i odwiedza strony.

Scraper przede wszystkim wydobywa z nich określone informacje.

System może wykonywać oba zadania jednocześnie.

Przykładowo:

1. crawler znajduje wszystkie produkty w kategorii,
2. przechodzi na ich podstrony,
3. scraper odczytuje ceny i parametry.

Robot wyszukiwarki również działa częściowo jak crawler, ponieważ przemierza internet, odkrywając kolejne dokumenty.

Jak crawler znajduje kolejne strony?

Najprostszym sposobem jest analiza linków.

Program rozpoczyna od jednego adresu i zapisuje znalezione odnośniki.

Następnie odwiedza kolejne strony.

Może korzystać również z:

• map XML,
• paginacji,
• list kategorii,
• z góry przygotowanej listy URL,
• danych otrzymanych z API.

W dużym serwisie samo odnalezienie wszystkich właściwych adresów może być równie istotnym problemem jak późniejsze pobieranie danych.

Do czego wykorzystuje się web scraping?

Zastosowań jest bardzo dużo.

Scraping może wspierać między innymi:

• monitorowanie cen,
• analizę konkurencji,
• zbieranie danych produktowych,
• monitorowanie dostępności,
• budowanie zestawień,
• badania rynku,
• monitorowanie zmian na stronach,
• agregowanie publicznie dostępnych danych,
• automatyzację pracy z serwisami bez API.

W każdym przypadku trzeba jednak osobno ocenić, czy pobieranie konkretnych danych jest technicznie, prawnie i biznesowo uzasadnione.

Monitorowanie cen

Jednym z najbardziej oczywistych zastosowań jest sprawdzanie zmian cen.

Zamiast codziennie otwierać kilkaset produktów, system może cyklicznie pobierać:

• nazwę,
• cenę aktualną,
• cenę regularną,
• informację o promocji,
• datę pomiaru.

Dzięki temu można zbudować historię zmian.

Ważne jest jednak prawidłowe dopasowanie tego samego produktu pomiędzy kolejnymi pomiarami.

Dopasowywanie produktów

Nazwa nie zawsze jest dobrym identyfikatorem.

Ten sam produkt może być opisany na kilka sposobów.

Znacznie bardziej przydatne są stabilne oznaczenia takie jak:

• EAN,
• GTIN,
• numer producenta,
• SKU, jeśli jest publicznie dostępne i stabilne.

Jeżeli ich nie ma, można próbować dopasowywać produkty na podstawie wielu cech jednocześnie.

Takie dopasowanie jest jednak znacznie bardziej podatne na pomyłki.

Monitorowanie dostępności

Scraper może regularnie sprawdzać, czy produkt jest:

• dostępny,
• niedostępny,
• dostępny na zamówienie,
• wycofany.

Takie dane mogą być użyteczne w analizie rynku lub wewnętrznych procesach biznesowych.

Trzeba jednak pamiętać, że komunikat wyświetlany użytkownikowi nie zawsze odpowiada rzeczywistemu stanowi magazynowemu.

Scraping danych produktowych

W e-commerce często pojawia się potrzeba pobrania większej liczby danych z katalogu.

Mogą to być:

• nazwy produktów,
• opisy,
• kategorie,
• parametry techniczne,
• identyfikatory,
• dostępność,
• adresy zdjęć.

Samo techniczne pobranie danych nie oznacza jednak automatycznie prawa do ich dalszego wykorzystywania.

Szczególnie ostrożnie trzeba podchodzić do treści chronionych prawem autorskim, baz danych oraz informacji objętych warunkami konkretnej usługi.

Scraping w integracjach

Czasami system, z którym trzeba się połączyć, nie posiada API ani żadnego przewidzianego mechanizmu integracji.

Web scraping może wtedy pełnić rolę rozwiązania zastępczego.

Traktuję go jednak jako rozwiązanie mniej stabilne od prawdziwego API.

Jeżeli cały proces biznesowy zależy od zewnętrznego HTML, trzeba od początku założyć możliwość zmian i przygotować mechanizmy monitorowania.

Scraping a automatyzacja

Web scraping bardzo często jest tylko pierwszym etapem większej automatyzacji.

Sam fakt pobrania danych niewiele daje, jeśli później ktoś musi codziennie ręcznie otwierać plik i wykonywać te same czynności.

Proces może wyglądać następująco:

1. scraper pobiera dane,
2. system je waliduje,
3. porównuje je z poprzednią wersją,
4. wykrywa zmianę,
5. wykonuje odpowiednią akcję,
6. zapisuje wynik.

Przykładowo system może wysłać powiadomienie tylko wtedy, gdy określona wartość rzeczywiście się zmieniła.

Właśnie takie procesy projektuję w ramach automatyzacji DIGIKROM: interesuje mnie nie tylko samo pobranie danych, ale przede wszystkim to, co ma się z nimi później wydarzyć.

Scraping jednorazowy i cykliczny

Jednorazowe pobranie danych jest stosunkowo proste.

Program działa raz, zapisuje wynik i kończy pracę.

Znacznie większym wyzwaniem jest scraper działający:

• codziennie,
• co godzinę,
• przez wiele miesięcy,
• na tysiącach adresów.

W takim przypadku zaczynają mieć znaczenie niezawodność, monitoring, koszty infrastruktury i obsługa zmian.

Harmonogram scrapera

Nie wszystkie dane wymagają tej samej częstotliwości odświeżania.

Jeżeli wartość zmienia się raz na miesiąc, wykonywanie zapytania co pięć minut jest bezsensowne.

Przy projektowaniu harmonogramu biorę pod uwagę między innymi:

• częstotliwość zmian danych,
• liczbę stron,
• znaczenie aktualności,
• obciążenie serwera źródłowego,
• koszt własnej infrastruktury.

Dlaczego nie należy odpytywać strony bez ograniczeń?

Program może wykonywać żądania znacznie szybciej niż człowiek.

Źle napisany scraper może więc w krótkim czasie wygenerować tysiące połączeń.

Może to:

• obciążyć cudzy serwer,
• spowodować blokadę adresu IP,
• uruchomić zabezpieczenia antybotowe,
• zakłócić działanie serwisu.

Dlatego scraper powinien posiadać rozsądne limity i opóźnienia.

Rate limiting

Rate limit określa maksymalną liczbę operacji wykonywanych w określonym czasie.

Przykładowo system może ograniczać się do kilku zapytań na sekundę albo jeszcze mniejszej częstotliwości.

Nie należy wybierać limitu wyłącznie na podstawie tego, ile technicznie potrafi wykonać komputer.

Ważne jest poszanowanie infrastruktury serwisu źródłowego.

Retry po błędzie

Połączenia internetowe czasami zawodzą.

Serwer może chwilowo zwrócić:

• błąd 500,
• błąd 502,
• błąd 503,
• timeout.

Nie oznacza to automatycznie, że produkt zniknął albo struktura strony się zmieniła.

Scraper może posiadać mechanizm ponowienia zapytania po określonym czasie.

Nie powinien jednak próbować bez końca.

Exponential backoff

Przy powtarzających się błędach można zwiększać odstęp pomiędzy kolejnymi próbami.

Przykładowo:

• pierwsza ponowna próba po kilku sekundach,
• kolejna po kilkunastu,
• następna jeszcze później.

Takie podejście zmniejsza ryzyko dodatkowego obciążania serwera, który już ma problemy.

Kody HTTP w scrapingu

Scraper powinien rozumieć podstawowe statusy HTTP.

Przykładowo:

• 200 oznacza zwykle poprawną odpowiedź,
• 301 i 302 oznaczają przekierowanie,
• 404 oznacza brak zasobu,
• 429 informuje zwykle o zbyt dużej liczbie zapytań,
• 5xx wskazują na problem po stronie serwera.

Każdy z tych przypadków wymaga innej reakcji.

Dlaczego kod 200 nie zawsze oznacza sukces?

Serwer może zwrócić kod 200, ale zamiast produktu wyświetlić:

• stronę logowania,
• CAPTCHA,
• komunikat o blokadzie,
• pusty szablon,
• informację o błędzie aplikacji.

Dlatego nie wystarczy sprawdzić status HTTP.

Trzeba również zweryfikować, czy odpowiedź rzeczywiście zawiera oczekiwane dane.

Walidacja danych

To jeden z najważniejszych elementów solidnego scrapera.

Jeżeli program spodziewa się ceny, powinien sprawdzić, czy pobrana wartość rzeczywiście wygląda jak cena.

Jeżeli nagle otrzyma pusty tekst albo napis „Zaloguj się”, nie powinien zapisywać go jako poprawnej wartości.

Walidacja może kontrolować:

• format,
• typ danych,
• zakres wartości,
• obecność wymaganych pól,
• relacje pomiędzy polami.

Normalizacja danych

Dane pobrane ze strony często wymagają oczyszczenia.

Cena może mieć formę:

1 299,00 zł

a system potrzebuje liczby:

1299.00

Podobnie jednostki mogą być zapisane jako:

• kg,
• kilogram,
• kilogramy.

Normalizacja sprowadza różne warianty do wspólnej postaci.

Duplikaty danych

Ten sam produkt może być dostępny pod kilkoma adresami.

Może również występować w kilku kategoriach.

Jeżeli crawler zbiera wszystkie linki bez kontroli, ten sam rekord może zostać przetworzony wiele razy.

Dlatego potrzebny jest mechanizm deduplikacji.

Może wykorzystywać:

• kanoniczny URL,
• EAN,
• SKU,
• unikalny identyfikator strony.

Paginacja a scraping

Lista produktów często jest podzielona na wiele stron.

Scraper musi więc wiedzieć, jak przejść:

1 → 2 → 3 → 4

aż do końca zbioru.

Problemy mogą pojawić się, gdy serwis wykorzystuje:

• klasyczną paginację,
• przycisk Pokaż więcej,
• infinite scroll,
• dynamiczne zapytania AJAX.

Każdy model wymaga nieco innego podejścia.

Web scraping i infinite scroll

Przy infinite scroll kolejna część danych pojawia się dopiero podczas przewijania.

Scraper może wtedy:

• symulować przewijanie strony,
• odnaleźć zapytanie pobierające kolejne dane,
• ustalić ukryty mechanizm paginacji.

Druga metoda bywa znacznie bardziej wydajna niż automatyczne przewijanie całej przeglądarki.

Scraping danych strukturalnych

Niektóre strony zawierają informacje przygotowane specjalnie dla wyszukiwarek i innych systemów.

Mogą to być dane strukturalne opisujące między innymi:

• produkt,
• cenę,
• dostępność,
• markę,
• oceny.

Czasami łatwiej i stabilniej jest pobrać określoną informację właśnie z takiej struktury niż z warstwy wizualnej.

Nie można jednak zakładać, że dane strukturalne zawsze są kompletne i aktualne.

Scraping ze stron wielojęzycznych

Ten sam produkt może posiadać kilka wersji językowych.

Scraper powinien rozumieć, czy są to:

• oddzielne produkty,
• tłumaczenia tej samej pozycji,
• różne rynki cenowe.

Szczególnego znaczenia nabierają wtedy stabilne identyfikatory.

Scraping i różne waluty

Sklep może prezentować ceny w zależności od kraju lub wybranej waluty.

Ta sama strona może więc zwrócić różne informacje zależnie od:

• lokalizacji,
• cookies,
• ustawień użytkownika,
• domeny regionalnej.

Jeżeli celem jest porównywanie cen, scraper musi kontrolować kontekst, w którym wykonywane jest zapytanie.

Personalizacja stron

Niektóre serwisy pokazują różne treści różnym użytkownikom.

Może mieć na to wpływ:

• historia wizyty,
• konto użytkownika,
• lokalizacja,
• test A/B,
• urządzenie.

Wynik scrapingu nie zawsze musi więc odpowiadać temu, co zobaczy każdy użytkownik.

Cookies i sesje

Scraper może czasami potrzebować zachowania sesji pomiędzy kolejnymi żądaniami.

Cookies mogą odpowiadać za:

• wybraną wersję językową,
• region,
• preferencje,
• stan sesji.

W przypadku publicznie dostępnych danych najprostsze są procesy niewymagające logowania.

Automatyczne korzystanie z kont użytkowników wymaga dodatkowej ostrożności i analizy zasad konkretnego systemu.

Web scraping a logowanie

Technicznie możliwe jest automatyczne przechodzenie procesu logowania.

Nie oznacza to jednak, że powinno się robić to w każdej usłudze.

Trzeba uwzględnić:

• warunki korzystania z serwisu,
• uprawnienia użytkownika,
• charakter danych,
• bezpieczeństwo danych logowania,
• ewentualne ograniczenia automatyzacji.

Jeżeli system posiada oficjalne API, zwykle jest to znacznie lepsza droga do integracji.

CAPTCHA

CAPTCHA służy między innymi do rozróżniania człowieka od automatycznego programu.

Jeżeli scraper zaczyna regularnie otrzymywać CAPTCHA, jest to sygnał, że serwis próbuje ograniczyć automatyczny dostęp.

Nie powinno się traktować tego wyłącznie jako kolejnej przeszkody programistycznej do agresywnego obchodzenia.

Najpierw warto sprawdzić, czy istnieje prawidłowy i dozwolony sposób uzyskania danych.

Systemy antybotowe

Duże serwisy mogą stosować zaawansowane mechanizmy wykrywania automatycznego ruchu.

Analizują między innymi:

• częstotliwość żądań,
• zachowanie klienta,
• nagłówki HTTP,
• adres IP,
• sposób wykonywania JavaScriptu.

Ich celem może być ochrona infrastruktury przed nadużyciami, atakami i masowym pobieraniem danych.

User-Agent

User-Agent jest informacją przekazywaną przez klienta HTTP i opisującą program wykonujący żądanie.

Przeglądarki przesyłają własne identyfikatory.

Bot również może posiadać własny User-Agent.

Nie należy zakładać, że zmiana User-Agent na nazwę popularnej przeglądarki automatycznie rozwiązuje problemy scrapingu.

Współczesne systemy analizują znacznie więcej cech ruchu.

robots.txt a web scraping

Plik robots.txt został zaprojektowany przede wszystkim do komunikowania zasad crawlowania robotom.

Nie jest systemem autoryzacji i nie zabezpiecza danych przed dostępem.

Jednocześnie może pokazywać, jakie obszary właściciel serwisu chce ograniczyć dla automatycznych crawlerów.

Przy projektowaniu legalnego i odpowiedzialnego procesu warto uwzględniać takie sygnały razem z regulaminem i charakterem danych.

Czy web scraping jest legalny?

Nie da się odpowiedzieć jednym zdaniem, że web scraping jest zawsze legalny albo zawsze nielegalny.

Znaczenie ma między innymi:

• jakie dane są pobierane,
• czy są publicznie dostępne,
• w jaki sposób będą wykorzystane,
• czy są chronione prawem autorskim,
• czy istnieją prawa do bazy danych,
• czy występują dane osobowe,
• jakie warunki korzystania posiada serwis,
• w jakim kraju odbywa się przetwarzanie.

Przy projekcie, którego podstawą ma być masowe pobieranie cudzych danych, aspekt prawny należy ocenić przed wdrożeniem, a nie po zbudowaniu systemu.

Publicznie widoczne nie znaczy dowolne do wykorzystania

To bardzo ważne rozróżnienie.

Fakt, że informacja jest widoczna na stronie bez logowania, nie oznacza automatycznie, że można ją dowolnie kopiować, publikować lub sprzedawać.

Techniczna dostępność i prawo do określonego wykorzystania danych to dwie różne kwestie.

Dane osobowe

Szczególnej ostrożności wymagają dane dotyczące osób fizycznych.

Masowe pobieranie:

• imion,
• adresów e-mail,
• numerów telefonu,
• profili użytkowników,

może wiązać się z dodatkowymi obowiązkami dotyczącymi ochrony danych.

Scraping nie powinien być traktowany jako sposób na omijanie zasad dotyczących przetwarzania danych osobowych.

Prawa autorskie

Scraper może technicznie pobrać artykuł, opis produktu lub zdjęcie.

To nie oznacza, że treści można później bez ograniczeń wykorzystać na własnej stronie.

Opis napisany przez inną firmę może być chroniony.

Podobnie zdjęcia produktowe czy materiały redakcyjne.

Dlatego należy oddzielić techniczną możliwość pobrania od prawa do publikacji.

Scraping a obciążenie serwera

Nawet w przypadku danych, które można legalnie pozyskiwać, sposób działania automatu powinien być rozsądny.

Nie ma potrzeby wysyłania stu zapytań na sekundę do niewielkiego serwisu, jeżeli te same dane można pobrać spokojnie w ciągu kilku minut.

Dobrze przygotowany scraper ogranicza ruch do poziomu potrzebnego do realizacji zadania.

Jak przechowywać dane ze scrapingu?

Wynik może trafiać do:

• CSV,
• Excela,
• bazy SQL,
• bazy dokumentowej,
• systemu ERP,
• aplikacji analitycznej,
• innego API.

Format powinien wynikać z dalszego zastosowania.

Jeżeli dane będą później regularnie porównywane i aktualizowane, baza danych zazwyczaj jest wygodniejsza od kolejnych plików.

Historia zmian danych

Czasami nie wystarczy znać aktualną wartość.

Warto wiedzieć również, jak wyglądała wcześniej.

Przykładowo system monitorujący ceny może zapisywać:

• produkt,
• cenę,
• datę i godzinę pomiaru.

Na tej podstawie można później analizować historię.

Jeżeli za każdym razem nadpisywana jest tylko aktualna cena, cała wcześniejsza informacja znika.

Pełny import czy tylko zmiany?

Przy dużych zbiorach można stosować dwa podstawowe modele.

Pierwszy pobiera za każdym razem wszystko.

Drugi próbuje wykrywać wyłącznie dane, które się zmieniły.

Pełne pobranie jest prostsze, ale może generować znacznie większy ruch i koszt.

Mechanizm różnicowy jest bardziej wydajny, ale wymaga dobrego sposobu identyfikowania zmian.

Hash danych

Jednym ze sposobów wykrywania zmian jest obliczenie skrótu dla określonego zestawu informacji.

Jeżeli hash jest taki sam jak wcześniej, można założyć, że monitorowana część rekordu się nie zmieniła.

Jeżeli jest inny, system wykonuje dokładniejszą analizę.

To przydatne przy dużej liczbie obiektów.

Logowanie działania scrapera

Automat działający bez logów jest bardzo trudny do utrzymania.

Warto zapisywać między innymi:

• czas rozpoczęcia zadania,
• liczbę przetworzonych stron,
• liczbę poprawnych rekordów,
• błędy HTTP,
• brakujące pola,
• czas zakończenia.

Gdy proces przestaje działać, logi pozwalają ustalić, od którego momentu pojawił się problem.

Monitoring scrapera

Jeszcze ważniejsze jest wykrycie sytuacji, w której scraper pozornie działa, ale zapisuje błędne dane.

Przykładowo proces uruchomił się poprawnie i zakończył bez wyjątku, ale zamiast 12 000 produktów znalazł tylko 14.

Technicznie zadanie zostało wykonane.

Biznesowo jest to awaria.

Dlatego można monitorować:

• liczbę rekordów,
• procent brakujących pól,
• nietypowe zmiany wartości,
• czas wykonania,
• odsetek błędów.

Alerty o zmianie struktury

Jeżeli scraper nagle przestaje znajdować cenę na większości stron, prawdopodobnie zmienił się szablon.

Zamiast zapisywać tysiące pustych rekordów, system powinien zatrzymać proces lub zgłosić problem.

To bardzo ważna różnica pomiędzy skryptem napisanym jednorazowo a systemem przygotowanym do regularnej pracy.

Scraper nie powinien zgadywać

Jeżeli program nie znajduje określonej wartości, lepiej oznaczyć ją jako brakującą niż próbować bez kontroli pobierać podobny tekst z innego miejsca strony.

Automatyczne zgadywanie może prowadzić do bardzo trudnych do wykrycia błędów.

Brak danych jest często bezpieczniejszy niż dane nieprawdziwe.

Wersjonowanie parserów

Przy większym systemie scraper może obsługiwać wiele źródeł.

Każde z nich ma własną strukturę.

Zmiana parsera dla jednego serwisu nie powinna przypadkowo wpływać na pozostałe.

Warto więc rozdzielać logikę pobierania i przetwarzania danych dla konkretnych źródeł.

Scraping wielu serwisów

Jeżeli dane pochodzą z kilku stron, trzeba liczyć się z tym, że każda działa inaczej.

Różnice mogą dotyczyć:

• struktury HTML,
• paginacji,
• nazewnictwa,
• walut,
• jednostek,
• sposobu prezentacji dostępności.

Największą pracą często nie jest samo pobranie informacji, ale późniejsze sprowadzenie ich do wspólnego modelu.

Model danych

Przed stworzeniem rozbudowanego scrapera warto ustalić, jak ma wyglądać wynik.

Dla produktu można zdefiniować na przykład:

• identyfikator,
• nazwę,
• markę,
• EAN,
• cenę,
• walutę,
• dostępność,
• źródło,
• adres URL,
• datę pobrania.

Dzięki temu niezależnie od wyglądu źródłowej strony dane trafiają do wspólnej struktury.

Scraping a machine learning i AI

Dane pozyskane ze stron mogą później być analizowane przy pomocy modeli statystycznych lub AI.

Web scraping jest wtedy jedynie etapem pozyskiwania materiału wejściowego.

Przed wykorzystaniem danych trzeba jednak zadbać o:

• jakość,
• spójność,
• brak duplikatów,
• zgodność z zasadami ich wykorzystania.

Duża liczba rekordów nie rekompensuje złej jakości danych.

Scraping a SEO

Web scraping można wykorzystywać również do analiz technicznych.

Program może odwiedzać strony serwisu i pobierać między innymi:

• title,
• meta description,
• nagłówki,
• canonical,
• status HTTP,
• linki wewnętrzne.

Tak działają również różne klasy crawlerów wykorzystywanych podczas audytów SEO.

W tym przypadku celem nie jest kopiowanie treści, ale analiza struktury własnej albo kontrolowanego serwisu.

Scraping własnej strony

Automatyczne analizowanie własnego serwisu może być bardzo użyteczne.

Można wykrywać:

• brakujące dane,
• uszkodzone linki,
• nieprawidłowe metadane,
• problemy z produktami,
• różnice pomiędzy systemami.

W takim przypadku nie występuje wiele problemów związanych z pobieraniem cudzych danych, a crawler może być elementem wewnętrznej kontroli jakości.

Web scraping a WooCommerce

W kontekście WooCommerce scraping może być używany jako pomocnicze źródło danych, ale nie powinien bez kontroli zastępować prawidłowych integracji.

Jeżeli hurtownia posiada API lub feed XML, zwykle lepiej korzystać właśnie z niego.

Jeżeli jednak nie istnieje żaden mechanizm wymiany danych, możliwe jest zbudowanie procesu pobierającego wybrane publiczne informacje.

Trzeba wtedy szczególnie pilnować identyfikatorów produktów i walidacji.

Scraping a feed XML

Feed produktowy jest kolejnym rozwiązaniem znacznie stabilniejszym od scrapingu HTML.

Dostawca może udostępniać plik zawierający:

• produkty,
• ceny,
• stany,
• parametry.

Jeżeli taki feed istnieje i zawiera potrzebne informacje, nie ma sensu pobierać ich z warstwy wizualnej sklepu.

Hierarchia źródeł danych

Przy integracjach stosuję prostą zasadę: im bardziej oficjalne i strukturalne źródło danych, tym lepiej.

W typowej sytuacji preferencja wygląda następująco:

1. oficjalne API,
2. dedykowany feed lub eksport,
3. kontrolowany dostęp do bazy albo plików,
4. web scraping.

Scraping jest bardzo użytecznym narzędziem, ale najlepiej stosować go wtedy, gdy rzeczywiście jest potrzebny.

Web scraping a dedykowany system

Przy większym procesie prosty skrypt może szybko przestać wystarczać.

Potrzebne stają się:

• harmonogramy,
• kolejki zadań,
• baza danych,
• monitoring,
• alerty,
• panel kontroli,
• historia zmian.

Wtedy scraper jest tylko jednym modułem większego systemu.

Jeżeli proces ma być krytycznym elementem działania firmy, projektuję go jak normalną aplikację, a nie jednorazowy skrypt. Takie rozwiązania mieszczą się również w obszarze dedykowanych systemów operacyjnych DIGIKROM.

Kolejka zadań

Przy tysiącach adresów nie zawsze warto uruchamiać wszystkie operacje jednocześnie.

Kolejka pozwala rozdzielać pracę na mniejsze zadania.

Można wtedy:

• kontrolować tempo,
• ponawiać tylko błędne rekordy,
• rozłożyć pracę pomiędzy kilka procesów,
• monitorować postęp.

Równoległe pobieranie

Wydajność można zwiększać poprzez wykonywanie kilku żądań jednocześnie.

Nie oznacza to jednak, że im więcej równoległych połączeń, tym lepiej.

Trzeba uwzględnić zarówno własne zasoby, jak i obciążenie źródłowego serwera.

Cache w scraperze

Jeżeli ten sam adres jest potrzebny wielokrotnie, czasami można przechować odpowiedź i nie pobierać strony ponownie.

Cache ogranicza liczbę zapytań i przyspiesza pracę.

Nie można jednak używać go bezterminowo, jeżeli dane mają być aktualne.

Timeout

Każde połączenie powinno posiadać maksymalny czas oczekiwania.

Bez timeoutu pojedyncza niedostępna strona może zatrzymać cały proces na bardzo długo.

Po przekroczeniu limitu zadanie można oznaczyć jako błędne i ewentualnie ponowić później.

Idempotencja procesu

Dobrze zaprojektowany proces powinien możliwie bezpiecznie znosić ponowne uruchomienie.

Jeżeli scraper zakończy się w połowie, nie powinno być konieczne ręczne czyszczenie całej bazy przed ponowną próbą.

System powinien wiedzieć, które rekordy zostały już poprawnie przetworzone.

Co się dzieje po awarii?

To pytanie warto zadać przed uruchomieniem automatyzacji.

Przykładowo:

• czy zadanie zostanie automatycznie wznowione,
• czy ktoś otrzyma alert,
• czy stare dane pozostaną dostępne,
• czy system zapisze częściowy wynik,
• czy istnieje możliwość ręcznego ponowienia.

Automatyzacja jest wartościowa tylko wtedy, gdy jej awaria nie pozostaje niezauważona.

Jak często trzeba utrzymywać scraper?

Nie istnieje scraper, któremu można zagwarantować wieczne działanie na zewnętrznej stronie.

Jeżeli źródło zmieni strukturę, parser może wymagać aktualizacji.

Dlatego przy planowaniu kosztów trzeba uwzględnić również późniejsze utrzymanie.

Najczęstszy błąd: scraper bez monitoringu

Program zostaje uruchomiony na serwerze i nikt później nie sprawdza jego wyników.

Po dwóch miesiącach okazuje się, że przez trzy tygodnie zapisywał puste ceny.

Sam harmonogram nie jest monitoringiem.

Najczęstszy błąd: dopasowanie tylko po nazwie

Nazwy produktów się zmieniają.

Producenci dodają oznaczenia, sklepy modyfikują tytuły, a warianty mogą wyglądać niemal identycznie.

Jeżeli jest to możliwe, warto opierać powiązania na stabilniejszych identyfikatorach.

Najczęstszy błąd: brak reakcji na zmianę HTML

Jeżeli selektor przestanie działać, scraper zapisuje pustą wartość i kontynuuje pracę.

Dobra walidacja powinna wykryć nagły wzrost braków i zgłosić problem.

Najczęstszy błąd: zbyt agresywne tempo

Program próbuje pobrać cały serwis w kilka sekund.

Może to doprowadzić do blokady i niepotrzebnie obciążać cudzą infrastrukturę.

Szybciej nie zawsze oznacza lepiej.

Najczęstszy błąd: brak rozróżnienia błędu od braku produktu

Timeout nie oznacza, że produkt nie istnieje.

Błąd 503 nie oznacza, że produkt jest niedostępny.

CAPTCHA nie oznacza ceny 0 zł.

Każdy stan trzeba interpretować zgodnie z jego rzeczywistym znaczeniem.

Najczęstszy błąd: bezpośrednia aktualizacja produkcji

Scraper pobiera dane i natychmiast nadpisuje nimi sklep bez żadnej walidacji.

Jeżeli źródło zwróci błędną odpowiedź, można w kilka minut zepsuć tysiące produktów.

Bezpieczniej jest stosować etap pośredni:

1. pobranie,
2. walidacja,
3. porównanie,
4. zatwierdzenie reguł,
5. dopiero aktualizacja.

Najczęstszy błąd: brak kopii poprzednich danych

Jeżeli nowy import nadpisuje wszystko bez historii, trudno cofnąć błąd.

Przy krytycznych procesach warto zachować przynajmniej poprzednią poprawną wersję albo historię zmian.

Jak zaplanować projekt web scrapingu?

Przed napisaniem kodu warto odpowiedzieć na kilka pytań.

1. Jakie dokładnie dane są potrzebne?
2. Skąd mają pochodzić?
3. Czy istnieje oficjalne API lub feed?
4. Jak często dane mają być aktualizowane?
5. Ile stron trzeba przetwarzać?
6. Jak identyfikować rekordy?
7. Co zrobić, gdy danych brakuje?
8. Gdzie zapisywać wynik?
9. Co ma się wydarzyć po wykryciu zmiany?
10. Jak monitorować poprawność procesu?

Dopiero po odpowiedzi na te pytania można sensownie dobrać technologię.

Web scraping nie zawsze wymaga AI

Wiele zadań można rozwiązać za pomocą klasycznych parserów i jednoznacznych reguł.

Jeżeli cena zawsze znajduje się w konkretnym miejscu, model językowy nie jest potrzebny do jej odczytania.

AI może być przydatne przy danych mniej uporządkowanych, ale zwiększa koszt i niepewność.

Najpierw wybieram najprostsze rozwiązanie, które daje wystarczająco pewny wynik.

Kiedy AI może pomóc?

Może być użyteczne przy:

• klasyfikacji tekstu,
• rozpoznawaniu typów produktów,
• normalizacji nazw,
• analizie nieustrukturyzowanych opisów,
• wykrywaniu podobnych rekordów.

Nadal jednak wynik powinien być walidowany, szczególnie gdy później wpływa na dane produkcyjne.

Scraping jako etap ETL

Web scraping można traktować jako część procesu ETL.

ETL oznacza:

• Extract – pobierz dane,
• Transform – przekształć je,
• Load – zapisz w docelowym systemie.

Scraping realizuje głównie etap Extract.

Największa wartość biznesowa często pojawia się jednak dopiero w dwóch kolejnych etapach.

Dlaczego samo pobranie danych to dopiero początek?

Plik zawierający 100 tysięcy rekordów nie rozwiązuje jeszcze problemu.

Trzeba wiedzieć:

• które rekordy są nowe,
• które się zmieniły,
• które zniknęły,
• które są błędne,
• co należy z nimi zrobić.

Dlatego w praktycznych wdrożeniach znaczna część pracy dotyczy logiki znajdującej się po scrapingu.

Kiedy web scraping ma sens?

Scraping jest dobrym narzędziem wtedy, gdy potrzebne informacje są dostępne w internecie, ale nie istnieje lepszy, strukturalny sposób ich pobrania.

Szczególnie sensowny jest, gdy:

• czynność ręczna jest powtarzalna,
• liczba stron jest duża,
• dane posiadają przewidywalną strukturę,
• proces można legalnie i bezpiecznie zautomatyzować,
• wartość automatyzacji przewyższa koszt utrzymania.

Kiedy lepiej nie używać scrapingu?

Nie wybierałbym go, jeśli:

• istnieje dobre oficjalne API,
• dostępny jest regularny feed danych,
• potrzebne informacje są chronione i nie ma prawa ich wykorzystywać,
• serwis wyraźnie nie przewiduje automatycznego dostępu,
• dane zmieniają strukturę tak często, że utrzymanie procesu jest nieopłacalne,
• informacje można uzyskać bezpośrednio od ich właściciela.

Web scraping jako narzędzie, nie cel

Najważniejsze jest określenie problemu biznesowego.

Pytanie nie powinno brzmieć:

„Czy możemy zrobić scraper?”

Lepiej zapytać:

„Jaką informację chcemy uzyskać i co ma się wydarzyć później?”

Może się wtedy okazać, że najlepszym rozwiązaniem jest:

• API,
• feed XML,
• webhook,
• bezpośrednia integracja,
• scraper.

Co warto zapamiętać o web scrapingu?

Web scraping pozwala automatycznie pobierać informacje ze stron internetowych i przekształcać je do uporządkowanej postaci.

Może służyć do monitorowania cen, dostępności, analizy rynku, zbierania danych produktowych oraz budowania procesów automatyzacji.

Najprostszy scraper pobiera HTML i wyszukuje w nim określone elementy. Bardziej zaawansowane rozwiązania obsługują JavaScript, paginację, sesje, wiele źródeł, harmonogramy, kolejki i historię zmian.

Największym wyzwaniem nie jest jednak jednorazowe pobranie danych. Jest nim stworzenie procesu, który przez dłuższy czas potrafi wykrywać błędy, zmiany struktury strony i nieprawidłowe wyniki.

Web scraping nie powinien również automatycznie zastępować API. Jeśli istnieje oficjalny i stabilny sposób integracji, zwykle będzie lepszym wyborem.

W dobrze zaprojektowanej automatyzacji scraper jest tylko jednym z elementów. Dane trzeba jeszcze zweryfikować, ujednolicić, porównać z poprzednimi wartościami i zdecydować, jaka akcja ma zostać wykonana.

Dlatego skuteczny web scraping zaczyna się nie od pisania parsera, ale od dokładnego określenia źródła, zakresu danych, zasad ich wykorzystania oraz tego, co cały system ma dzięki nim osiągnąć.