Tworzenie potoku do scrapowania stron internetowych z wykorzystaniem usług AWS

Czym jest scraping stron internetowych i dlaczego go potrzebujemy?#

Scraping stron internetowych to technika służąca do pozyskiwania danych z witryny. Dane te obejmują zazwyczaj pliki tekstowe HTML/CSS/JavaScript oraz inne zasoby, takie jak obrazy, filmy i czcionki, z których przeglądarka korzysta, aby wyświetlić daną stronę. Zebrane dane są następnie zapisywane w plikach lub bazie danych w celu dalszego przetwarzania.

W TeleportHQ nieustannie szukamy sposobów na udoskonalenie naszych możliwości generowania kodu na podstawie makiet lub projektów w wysokiej rozdzielczości. Ponieważ proces ten w dużej mierze opiera się na uczeniu maszynowym, potrzebujemy znacznych ilości starannie opracowanych danych. Zbiór danych RICO dobrze sprawdził się na początek w przypadku natywnych stron mobilnych, ale uznaliśmy, że warto zainwestować wysiłek w stworzenie własnego zbioru danych dotyczącego stron internetowych z kilku powodów:

• Niewiele jest publicznych zbiorów danych, które spełniają nasze wymagania jakościowe
• Kontrola nad danymi — możemy dokładnie określić, jakie informacje mają być pobierane ze stron internetowych
• Skalowanie — w miarę postępów badań będziemy potrzebować coraz więcej danych
• Organizacja i dostępność — zapewnienie szybkiego i łatwego dostępu do danych

Jak to zrobić?#

Scrapowanie strony internetowej obejmuje 2 etapy: pobieranie jej i wyodrębnianie z niej danych. Pobieranie polega na ściągnięciu strony, czyli początkowego ciągu HTML oraz wszystkich zasobów, do których się odwołuje — dokładnie tak, jak robi to przeglądarka podczas wyświetlania strony. Dlatego przeszukiwanie sieci jest kluczowym elementem scrapowania: pobieramy strony, aby później je przetworzyć. W naszym przypadku przeszukiwanie odbywa się za pomocą Puppeteera, biblioteki Node.js udostępniającej wysokopoziomowe API do sterowania przeglądarką Chrome lub Chromium. Uruchamiając Chromium w trybie bez interfejsu graficznego, możemy pobierać strony internetowe i wykorzystywać je do pozyskiwania danych.

Istnieje wiele sposobów wyodrębniania danych ze stron internetowych, ale w naszym przypadku stosujemy technikę zwaną parsowaniem DOM. Po załadowaniu strony przeglądarka tworzy jej model obiektowy dokumentu (DOM), który następnie służy do wyświetlenia strony na ekranie. Model DOM dokumentu HTML ma postać drzewa obiektów, które można analizować, aby uzyskać potrzebne informacje.

Dla każdego elementu DOM pobieramy listę atrybutów zawierających informacje między innymi o rozmiarze, położeniu i kolorze.

Pierwsze problemy#

Po pracy ze zbiorem danych stron internetowych zauważyliśmy, że wiele zawartych w nim witryn sprawiało problemy, takie jak nakładanie się elementów lub wyświetlanie stron błędu 404.

Nakładanie się elementów było spowodowane przez niewidoczne elementy lub elementy znajdujące się poza obszarem widoku, które były ładowane do DOM, ale wyświetlały się dopiero po wystąpieniu określonego zdarzenia. Nie twierdzimy, że te witryny są źle zaprojektowane, ale mogłyby powodować niespójności podczas trenowania modelu uczenia maszynowego. Błąd 404 pojawiał się, ponieważ przeglądarka mogła połączyć się z serwerem, ale serwer nie mógł znaleźć żądanego zasobu. DOM strony błędu 404 nadal się ładuje, a strona jest parsowana, jednak nie można z niej uzyskać żadnych przydatnych informacji.

Klasyfikator uczenia maszynowego na ratunek#

Rozwiązaniem tych problemów okazało się stworzenie klasyfikatora uczenia maszynowego, który określa prawdopodobieństwo, że dana strona internetowa nadaje się do wykorzystania. Zaczęliśmy od ręcznego przypisywania stron do różnych kategorii na podstawie obiektywnych kryteriów, takich jak: „Czy elementy na siebie nachodzą?” lub „Czy strona zawiera wystarczająco dużo informacji?”. Aby uprościć ten proces, stworzyliśmy własną aplikację internetową w R Shiny, wyposażoną w specjalny widok, który umożliwiał ręczne oznaczanie kolejnych punktów danych.

Następnie wykorzystaliśmy oznaczenia jako dane treningowe dla naszego modelu XGBoost. Po jego przetestowaniu uzyskaliśmy dokładność na poziomie 85%. Do wdrożenia użyliśmy SageMakera, głównie dlatego, że biblioteka XGBoost była zbyt duża, by umieścić ją w kontenerze Lambda.

Średnie prawdopodobieństwo przydatności stron internetowych w zależności od liczby elementów w DOM

Prawdopodobieństwa wśród 200 tys. witryn

Skalowanie#

Pierwsza wersja Web Scrapera była aplikacją Node.js, która wykorzystywała wywołania asynchroniczne do równoległego przetwarzania stron. Był to dobry początek, który pozwolił nam szybko przetworzyć pierwsze witryny. Jednak gdy spróbowaliśmy zrównoleglić pracę, szybko natknęliśmy się na ograniczenia sprzętowe naszego lokalnego komputera. Pamięć RAM szybko się wyczerpywała, a procesor nie był w stanie sprostać obciążeniu. Aby zwiększyć moc obliczeniową, zdecydowaliśmy się przenieść parser na instancję EC2 m4.4xlarge w AWS, wyposażoną w 16 vCPU i 64 GB pamięci RAM. Zrobiliśmy to wyłącznie po to, aby zwiększyć szybkość przetwarzania stron.

Główną wadą tego rozwiązania było to, że wszystko trzeba było robić ręcznie: wprowadzanie adresów witryn, przygotowanie cech, wnioskowanie modelu ML, przesyłanie danych do S3 po zakończeniu i nie tylko. Rozwiązaniem tego problemu było utworzenie potoku, który wykonywałby wszystkie te czynności automatycznie i porządkował je, ułatwiając dostęp do danych. Ponadto AWS Lambda obsługuje wiele funkcji działających jednocześnie, co pozwoliłoby nam przetwarzać więcej witryn na minutę.

Struktura potoku#

Potok składa się z dwóch rodzajów elementów: procesorów i pamięci masowej. Procesorami są funkcje Lambda wyzwalane przez określone zdarzenia, a do przechowywania danych służą baza NoSQL DynamoDB oraz zasobnik S3. DynamoDB zawiera podstawowe informacje o witrynach, takie jak domena, strona czy czas przetworzenia witryny. Zasobnik S3 jest podzielony na trzy foldery:

• Multi-site-CSV — zawiera pliki CSV z wieloma witrynami do przetworzenia
• Meta — zawiera informacje o jednej witrynie potrzebne do jej przetworzenia
• Data — zawiera wyniki działania parsera: jeden zrzut ekranu i jeden plik JSON ze wszystkimi informacjami wyodrębnionymi z DOM

Punkt wyjścia#

Aby rozpocząć proces, musimy podać adres jednej lub kilku witryn. Można to zrobić na dwa sposoby. Pierwszy polega na wywołaniu punktu końcowego i przekazaniu adresu URL jako parametru żądania. Spowoduje to przetworzenie wyłącznie wskazanej witryny, a w odpowiedzi zwróci jej nazwę w S3. Drugi sposób polega na przesłaniu pliku CSV ze wszystkimi witrynami do przetworzenia do folderu „multi-site-CSV”.

Wyzwalacze Lambda#

W potoku znajdują się 3 funkcje Lambda, które napędzają cały proces.

Pierwsza funkcja Lambda, „CSV-split”, jest uruchamiana za każdym razem, gdy plik CSV zostaje przesłany do folderu „multi-site-CSV”. Dzieli duży plik CSV na mniejsze pliki zawierające informacje o pojedynczych witrynach, a następnie przesyła je do folderu „meta” w S3.

Druga funkcja Lambda, „parse-added”, stanowi podstawę potoku. Zawiera parser i jest najbardziej wymagająca pod względem zasobów. Uruchamia się po każdym przesłaniu nowego pliku CSV do folderu „meta” i przetwarza odpowiednią witrynę. Jeśli przetwarzanie się powiedzie, zwraca zrzut ekranu, plik JSON oraz listę linków wewnętrznych, które zostaną później wykorzystane w potoku do rekurencyjnego przetwarzania. Następnie aktualizuje wpis dotyczący witryny w bazie danych i przesyła 2 pliki do folderu „data” w zasobniku S3. Jeśli przetwarzanie się nie powiedzie, elementy w S3 i bazie danych są usuwane, aby uniknąć niespójności.

Trzecia i ostatnia funkcja Lambda obsługuje część potoku związaną z uczeniem maszynowym. Jest uruchamiana po przesłaniu każdego pliku JSON do folderu „data” i wykorzystuje zawarte w nim dane do przygotowania cech. Następnie wysyła żądanie z cechami do punktu końcowego SageMaker, który zwraca prawdopodobieństwo, że witryna jest dobra. Jeśli prawdopodobieństwo jest wystarczająco wysokie, funkcja przesyła do folderu „multi-site-CSV” plik CSV zawierający wszystkie linki wewnętrzne danej witryny. To przesłanie uruchamia pierwszą funkcję Lambda, tworząc pętlę.

Wyniki#

Wydajność#

W trakcie prac rozwojowych wydajność znacznie się poprawiła. Aplikacja Node.js przetwarzała średnio 20 witryn na minutę. Po przeniesieniu jej na EC2 i wprowadzeniu kilku innych optymalizacji udało nam się zwiększyć szybkość przetwarzania do 240 witryn na minutę. To jednak nic w porównaniu z 4500 witrynami na minutę, które osiągnęliśmy dzięki AWS Lambda.

Co możemy zrobić z tymi danymi?#

Jednym z kierunków, którymi postanowiliśmy się zająć, jest wykrywanie obiektów na zrzutach ekranu witryn internetowych. Informacje zebrane ze stron dostarczyły nam wszystkiego, czego potrzebowaliśmy, aby rozpocząć pracę.

Po lewej — przewidywanie / po prawej — dane referencyjne

Naszym celem jest precyzyjne wykrywanie elementów na stronie internetowej. Wykorzystujemy współrzędne każdego elementu (górną, lewą, szerokość i wysokość), aby obliczyć odpowiadające im ramki, a następnie używamy ich do trenowania modelu uczenia maszynowego. Dane wyodrębnione z DOM dla powyższego przykładu były niespójne, przez co pojawiały się niewidoczne elementy albo niektóre elementy nie były wykrywane. Ponieważ do trenowania wykorzystaliśmy wysokiej jakości strony internetowe, model potrafił wywnioskować nawet położenie tych elementów (akapit z obrazem w tle w górnej części strony) i zignorować niewidoczne elementy (elementy po lewej stronie).

Początkowo klasyfikowaliśmy każdy element jako tekst lub obraz, ale wraz z postępem prac będziemy uwzględniać także inne znaczniki HTML, takie jak tabele, listy czy pola formularzy.

Wnioski#

Publicznie dostępnych, starannie opracowanych zbiorów danych dotyczących stron internetowych jest bardzo niewiele, a te nieliczne zawierają ograniczoną liczbę przykładów. Te prace przygotowawcze pozwoliły nam uniezależnić się i precyzyjnie kontrolować jakość oraz ilość naszych danych. Dodatkową istotną korzyścią jest możliwość dynamicznego tworzenia nowych, zaktualizowanych i ulepszonych zbiorów danych w zaledwie kilka godzin. Jeśli jesteś badaczem i chcesz uzyskać dostęp do naszych danych, napisz do nas.

Podczas tworzenia rozwiązania dowiedzieliśmy się również wiele o naszej branży i wykorzystywanych w niej technologiach. Ta wiedza pozwoliła nam lepiej zrozumieć, na czym powinniśmy skupić nasze badania nad automatyzacją procesu tworzenia interfejsów użytkownika.

Jak zawsze, bardzo chętnie wymienimy się doświadczeniami z innymi pasjonatami tego tematu. Jeśli interesują Cię nasze prace, skontaktuj się z nami za pośrednictwem dowolnego kanału w mediach społecznościowych, którego adres znajdziesz w stopce tej strony.