Opis projektu
PrzetłumaczoneRównie ważne jest to, co się dzieje po załadowaniu strony. Surowy HTML musi przekształcić się w zweryfikowane, zduplikowane rekordy, a ceny, daty i numery telefonów muszą być znormalizowane do jednolitych formatów przed trafieniem do bazy danych. Ma sens przechowywać tylko nowe lub zmienione dane, więc potrzebujemy logiki inkrementalnej. Poza tym, przejrzystość operacyjna ma dla nas znaczenie: pulpit nawigacyjny pokazujący wskaźniki sukcesu uruchomień i wolumeny, powiadomienia o awariach i anomaliach danych oraz powtarzalne wdrożenie, które można uruchomić od zera bez wiedzy plemiennej.
Konkretne docelowe strony internetowe są poufne i udostępniane na podstawie NDA po uzgodnieniu warunków. W swojej odpowiedzi napisz o tym, jakie zabezpieczenia przed botami napotkałeś i jak utrzymałeś stabilność parsera w czasie. Pełny zakres pracy poniżej.
1. Architektura skanera
— Scrapy + rotacja proxy i pula User-Agentów
— Playwright/Selenium dla stron JS
— Ominięcie CAPTCHA (2captcha / anti-captcha)
— Ograniczenie prędkości, zgodność z robots.txt
2. Pipeline danych
— HTML do uporządkowanego JSON
— Walidacja i usuwanie duplikatów
— Normalizacja cen, dat, numerów telefonów
— Przechowywanie w PostgreSQL z projektowaniem schematu
— Aktualizacje inkrementalne (tylko nowe/zmienione rekordy)
3. Monitorowanie i operacje
— Pulpit: sukces uruchomienia, liczba rekordów, błędy
— Powiadomienia Slack/email o awariach
— Wdrożenie Docker Compose
— Harmonogram Cron z logiką ponownego uruchamiania
Docelowe strony internetowe
— Poufne (NDA) — szczegóły po umowie
— Mieszanka stron statycznych i SPA
Wyniki do dostarczenia
— Kod źródłowy z testami
— Konfiguracja Docker Compose
— Migracje schematu bazy danych
— Runbook i konfiguracja monitorowania