Ausschreibungsparser mit ETP (JS-Render, Antibot) mit Normalisierung und Hochladen auf PostgreSQL und Telegram-Benachrichtigungen

Ausgangslage: Die Beschaffungsabteilung überwacht täglich neue Ausschreibungen auf 6 elektronischen Handelsplattformen (ETP). Derzeit erfolgt dies manuell in einem Browser mit Filtern, weshalb einige relevante Käufe übersehen werden und Daten von verschiedenen ETPs nicht in einem einzigen Formular zusammengeführt werden.

Technische Umgebung und Einschränkungen: Linux-Server (Ubuntu 22.04), Zugriff über SSH. Erlaubt ist die Verwendung von Python 3.11, Playwright oder Selenium, request/httpx, PostgreSQL 14 (Datenbank existiert bereits). Docker ist möglich, aber nicht erforderlich. Sie können keine kostenpflichtigen Anti-Captcha-Dienste nutzen und Anmeldeinformationen von persönlichen Konten nicht im Klartext speichern. Zugriff auf ETP nur als Gast, ohne Autorisierung. Einige Websites laden Inhalte mit JavaScript, verfügen über einen Anti-Bot-Schutz und begrenzen die Anforderungshäufigkeit.

Themengebiet: Ausschreibungen/Käufe. Es ist erforderlich, Einkaufskarten und Lose zu sammeln, Kategorien und Beträge zu normalisieren und einen Änderungsverlauf zu speichern.

Was passieren sollte: ein autonomer Parser, der nach einem Zeitplan Daten von 6 angegebenen ETPs sammelt (ich werde eine Liste von Domänen und Beispiele für Links zu Suchergebnissen bereitstellen), sie in ein gemeinsames Schema bringt und sie zu PostgreSQL hinzufügt und außerdem Benachrichtigungen an Telegram sendet, wenn neue relevante Käufe erscheinen.

Stufen und Hauptanforderungen:
1) Analyse der Quellen – Bestimmen Sie für jedes ETP die Lademethode (XHR/GraphQL/HTML/JS-Render), die Einstiegspunkte für die Ausgabe und Karten, eine Reihe von Feldern und Geschwindigkeitsbegrenzungen.
2) Implementierung des Assemblers – separate Adaptermodule für jede Quelle mit einer einzigen Schnittstelle. Wiederholungen, Backoffs, Timeouts, Parallelitätsbeschränkung, User-Agent-Rotation, das Arbeiten über einen Proxy (ich werde einen Proxy bereitstellen) und Widerstand gegen Teilausfälle müssen unterstützt werden.
3) Datennormalisierung – ein einzelnes Modell in der Datenbank: Kauf, Los, Kunde, Region, Daten (Veröffentlichung/Ende), NMC/Währung, Status, Link, Site, Textbeschreibung, CPV/OKPD2 (falls vorhanden) sowie ein berechnetes Relevanzfeld für Schlüsselwörter und Ausschlusswörter (ich werde eine Liste bereitstellen). Reduzieren Sie Beträge auf Zahlen, Datumsangaben auf UTC, entfernen Sie doppelte Werbung zwischen ETPs mithilfe einer Reihe von Heuristiken (TIN des Kunden + Betrag + Datumsangaben + Namensähnlichkeit).
4) Verlaufsspeicherung – Wenn sich der Status oder das Enddatum ändert, sollte ein neuer Eintrag in der Verlaufstabelle mit einem Zeitstempel und geänderten Feldern aufgezeichnet werden.
5) Benachrichtigungen – Der Telegram-Bot sendet eine Nachricht über neue relevante Käufe, nicht mehr als 1 Benachrichtigung pro Kauf, mit kurzen Feldern und einem Link. Der Befehl /health gibt auch Statistiken der letzten Ausführung zurück (wie viel wurde von der Quelle gesammelt, wie viele Fehler, Zeit).
6) Betrieb – Start über Cron oder Systemd-Timer, Protokollierung in einer Datei, Löschen von Fehlermeldungen für jede Quelle.

Spezifische Ausgabe: ein Repository mit Quellcode, Konfiguration (env/ini/yaml), SQL-Schema-Migrationen, Anweisungen für die Ausführung unter Ubuntu und eine Beispiel-Relevanzfilterkonfiguration.

Messbare Akzeptanzkriterien:
- Während eines Testlaufs sammelt der Parser innerhalb von 24 Stunden mindestens 95 % der Anzeigen aus den Suchergebnissen für jede Quelle innerhalb der ersten drei Seiten (überprüft durch manuelle Berechnung an einer Stichprobe von 30 Anzeigen pro Quelle).
- Duplikate in der Datenbank überschreiten nicht 2 % der Gesamtzahl der Datensätze pro Lauf (Überprüfung anhand eines eindeutigen Schlüssels und Deduplizierungsheuristik).
- Durch den wiederholten Start derselben Filter werden keine neuen Kaufdatensätze erstellt, wenn keine Änderungen in den Quellen vorliegen, und der Verlauf wird nur aktualisiert, wenn die Felder tatsächlich geändert werden.
- Die volle Laufzeit für alle Quellen beträgt nicht mehr als 45 Minuten auf einem 2 vCPU/4 GB RAM-Server mit einer Beschränkung auf bis zu 3 parallele Aufgaben.
- Protokolle enthalten separate Statistiken nach Quelle und Fehlerursachencodes (Zeitüberschreitung, Blockierung, Analyse, Strukturänderung).

Zusätzlich: Ich werde eine Liste von ETPs, URL-Beispielen, Schlüsselwörtern und Zugang zur Testdatenbank bereitstellen, nachdem ich mich auf den Ansatz und die Datenstruktur geeinigt habe.