Die Auswahl von Open-Source-Crawlern wird einfacher, wenn man vier Aufgabenbereiche trennt: allgemeines Crawling, Browser-Automatisierung, Planung und Queues sowie Parsing und Speicherung. Der Beitrag erklärt Aufgaben, typische Integrationsfehler und vier praktisch prüfbare Kriterien.
Wer auf GitHub nach Crawlern sucht, findet Hunderte oder sogar Tausende Repositories. Viele wählen ein Projekt nach der Zahl der Stars aus und beginnen mit dem populärsten.
Beliebtheit und Eignung sind jedoch zwei verschiedene Dinge. Selbst ein sehr verbreitetes Projekt macht mehr Arbeit, wenn seine Ausrichtung nicht zum eigenen Szenario passt. Der einfachere Einstieg ist, zuerst die Zuständigkeiten zu trennen: Ein Erfassungssystem, das langfristig stabil läuft, besteht ohnehin aus mehreren Bausteinen mit unterschiedlichen Aufgaben. Wer versteht, was jeder Baustein leistet, kann konkrete Implementierungen deutlich leichter vergleichen.
Allgemeine Crawler-Frameworks: für klar strukturierte Seiten
Diese Frameworks kümmern sich um Request-Planung, paralleles Abrufen und Datenpipelines. Als Eingabe dienen URL-Listen, als Ausgabe strukturierte Ergebnisse. Reife Ökosysteme und Middleware-Mechanismen erlauben eigene Logik, und auch sehr große, langfristige Aufgaben lassen sich damit zuverlässig betreiben.
Seiten, deren Inhalte erst durch JavaScript-Rendering erscheinen, können sie nicht allein verarbeiten. Dort liefert die reine Antwort nur eine leere Hülle, sodass zusätzlich eine Rendering-Engine nötig ist. Gut geeignet sind stabile Ziele wie Listen-, Detailseiten und offene APIs.
Browser-Automatisierung: für Rendering und Interaktion
Seiten, die echtes Rendering, einen angemeldeten Zustand oder mehrere Klicks benötigen, gehören in die Browser-Automatisierung. Solche Werkzeuge können über verschiedene Browser-Engines laufen, verfügen über ausgereifte Wartefunktionen und können Requests sowie Responses der Seite direkt übernehmen.
Der Preis ist ein deutlich höherer Ressourcenverbrauch als bei reinen HTTP-Anfragen. Die mögliche Parallelität wird im Wesentlichen durch lokalen Arbeitsspeicher und CPU begrenzt. Außerdem hinterlässt Automatisierung erkennbare Merkmale, die streng prüfende Websites identifizieren können.
Planung und Queues: erst bei vielen Aufgaben nötig
Bei wenigen Zielen reicht oft eine Schleife. Bei Tausenden Aufgaben sowie Anforderungen an Frequenzsteuerung und Wiederholungen braucht man eine eigene Scheduling-Schicht: Wie werden Aufgaben eingereiht, wie hoch ist die Parallelität, wie lange wartet man vor einem neuen Versuch und welche Aufgaben werden aufgegeben? Wird all das in das Crawler-Framework gepackt, wird der Code schnell unübersichtlich.
Ein typischer Fehler beim Eigenbau ist eine rein prozessinterne Queue. Startet der Prozess neu, sind alle wartenden Aufgaben verloren. Mindestens nötig sind Persistenz und ein abfragbarer Status.
Parsing und Speicherung: entscheiden über direkt nutzbare Daten
Abgerufen wird HTML, gebraucht werden Felder. Die Parsing-Schicht sollte Extraktionsregeln verwalten, Felder prüfen, Duplikate entfernen und Daten speichern. Bei Websites mit häufigen Strukturänderungen können adaptive Extraktionsverfahren sinnvoll sein, die Daten anhand von Seiteneigenschaften statt fest codierter Selektoren finden und so Wartungsaufwand sparen.
Auf der Speicherseite ist Idempotenz wichtig. Wiederholte Aufgaben sind normal; Schreibvorgänge sollten daher anhand einer eindeutigen Kennung dedupliziert werden, sonst gelangen Dubletten bis in nachgelagerte Analysen.
Typische Probleme nach dem Zusammensetzen
Jeder Baustein ist für sich überschaubar. Schwierigkeiten entstehen meist an den Übergängen.
- Die Scheduling-Schicht wiederholt eine Aufgabe, aber das Parsing dedupliziert nicht, sodass doppelte Zeilen entstehen
- Die Browser-Schicht hat kein Parallelitätslimit, verbraucht alle lokalen Ressourcen und die gesamte Charge fällt aus
- Parsing-Regeln sind fest im Code hinterlegt, daher erfordert jede Website-Änderung eine neue Veröffentlichung
- Komponenten verwenden unterschiedliche Kennungen für dieselbe Aufgabe, Status passen nicht zusammen und ein Fortsetzen am letzten Stand wird unmöglich
Vier Bewertungskriterien
Sobald die benötigte Kategorie feststeht, lassen sich konkrete Projekte mit diesen vier Punkten filtern.
Bei der Wartungsaktivität zählen Commit-Häufigkeit und Reaktionszeit auf Issues in den letzten Monaten, nicht die gesamte Zahl der Stars. Ein nicht mehr gepflegtes Projekt kann nach einer Änderung der Zielseite unmittelbar ausfallen.
Dokumentation und Beispiele bestimmen den Einstieg. Sind die Erklärungen unklar oder zeigen Beispiele nur den einfachsten Fall, fällt die Lernzeit oft höher aus als erwartet.
Bei der Erweiterbarkeit ist entscheidend, welche Schnittstellen vorgesehen sind: Lassen sich Proxy, eigene Rendering-Engine oder Speicher austauschen? Mit sauberen Erweiterungspunkten sind spätere Anpassungen oft ohne Änderungen am Quellcode möglich.
Lizenz- und Compliance-Risiken werden leicht übersehen. Vor kommerzieller Nutzung sollte die Lizenz geprüft und eine für den Einsatzzweck unpassende restriktive Lizenz vermieden werden. Auch Erfassungsumfang, Anfragefrequenz und Bedingungen der Zielwebsite müssen bewertet werden; das ist unabhängig von der technischen Qualität des Frameworks.
Die Umgebungsschicht ist eine andere Ebene
Ein Framework löst das Wie des Abrufs, nicht Identität und Skalierung. Wenn Aufgaben Login, regionale Trennung oder mehrere Konten parallel erfordern, verursacht eine gemeinsame Browser-Umgebung zwei Probleme: Sitzungen beeinflussen sich gegenseitig, weil Cookies und lokaler Speicher überlappen, und die Zielwebsite kann eigentlich unabhängige Aufgaben als dieselbe Besuchsgruppe einordnen.
Ein ausgereifter Ansatz macht Browser-Umgebungen zu einer eigenständigen Ressourcenschicht. Aufgaben fordern eine Umgebung aus einem Pool an und geben sie danach frei. PurpleMark übernimmt in einer solchen Architektur diese Schicht und stellt Umgebungsressourcen bereit, die stapelweise erstellt, an unabhängige Netzwerkausgänge gebunden und nach Status abgefragt werden können.
Grenzen durch Compliance
Beachte die robots-Regeln und Nutzungsbedingungen der Zielwebsite, sammle keine personenbezogenen Daten, umgehe keine technischen Schutzmaßnahmen und begrenze die Anfragefrequenz so, dass der normale Betrieb nicht beeinträchtigt wird. Die Projektauswahl beantwortet eine Effizienzfrage; diese Abwägungen entscheiden, ob die Erfassung überhaupt durchgeführt werden sollte.
