Bachelorarbeit: Web-Scraper für die akademische Forschung

Web Scraping ist für die akademische Forschung oft der einzige Weg an Daten, die sonst unzugänglich blieben — etwa wenn eine Webseite keine API anbietet. Genau hier setzt die Arbeit an: Statt auf externe Dienste angewiesen zu sein, sollte der Lehrstuhl ein eigenes, frei konfigurierbares System bekommen, das sich auf die jeweiligen Forschungsprojekte zuschneiden lässt.

Entstanden ist eine lokale Webanwendung in Java mit Spring Boot. Sie beherrscht zwei Betriebsarten: manuelles Scraping, bei dem man eine URL eingibt und sofort eine Vorschau der extrahierten Daten bekommt, sowie automatisiertes Scraping über konfigurierbare Tasks, die ein Scheduler in Intervallen von fünf Minuten bis zu vier Wochen anstößt. Die Ergebnisse landen in einer Datenbank, lassen sich in der Oberfläche nachbearbeiten — Spalten umbenennen oder löschen — und nach CSV oder JSON exportieren, inklusive automatischer Typzuweisung.

Der inhaltliche Kern liegt auf der robusten Extraktion von Tabellen- und Listenstrukturen. Da HTML in der Praxis in unzähligen Varianten auftritt, wurden spezialisierte Extraktionsmethoden mit Fallback-Strategien entworfen: tief verschachtelte Listen, Listeneinträge aus mehreren HTML-Elementen, leere und whitespace-dominierte Felder, unregelmäßige Header. Für dynamische, JavaScript-getriebene Seiten kommt Selenium zum Einsatz, das echte Nutzerszenarien simulieren kann — anders als reine HTML-Parser wie JSoup.

Architektonisch folgt die Anwendung dem Ports-and-Adapters-Muster (hexagonale Architektur) mit sauber getrennten Application-, Domain- und Infrastructure-Schichten. Dependency Inversion hält den Anwendungskern frei von Infrastrukturabhängigkeiten, Datenbankobjekte sind konsequent von Domain-Modellen getrennt. Das macht das System nicht nur wartbar, sondern auch gut testbar — abgesichert durch umfangreiche Unit- und Integrationstests über Controller, Services, Datenbank und Scraper.

Für Performanz sorgt Multithreading: Die zu verarbeitenden Daten werden in gleich große Blöcke aufgeteilt und parallel abgearbeitet, wobei die Threadanzahl konfigurierbar ist und gegen die real verfügbaren Kerne validiert wird. Als Datenbank fiel die Wahl bewusst auf MongoDB, weil gescrapte Inhalte heterogen und schemalos sind — alle Ergebnisse landen in einem einheitlichen ScrapedData-Modell samt Metadaten.