Web-Crawler-Architektur
(velog.io)-
Die bisher im Internet zahllos vorgestellten Web-Crawler sind größtenteils eher "Scraper" und lassen sich kaum wirklich als Crawler bezeichnen.
-
Der Autor stellt die Arbeiten, die Web-Crawler definieren, kurz vor.
-
Ein Crawler ist eine Anwendung, die die Welt des Internets per BFS und DFS durchläuft.
-
Robots-Regeln sind ein so wichtiges Thema, dass sie sogar das Image eines Unternehmens prägen können, doch viele Startups kennen sich damit nicht aus.
4 Kommentare
Schon letztes Jahr habe ich einen Text dieser Person gelesen und mich gefragt, warum sie so quer zur Welt lebt; vielleicht ist es inzwischen wenigstens etwas besser geworden.
Wenn man es realistisch betrachtet: Wenn man nicht gerade bei einem Großunternehmen arbeitet, das buchstäblich eine Suchmaschine betreibt ...
Selbst wenn man einen Crawler einsetzt, sind im Bereich Text Mining die Vorverarbeitungskosten hoch, sofern es nicht um Englisch geht. Deshalb ist es mit einem Crawler dieser Art schwer, qualitativ hochwertige Daten zu gewinnen. Im Bereich Bildverarbeitung gibt es ohnehin reichlich hochwertige Datensätze, sodass es keinen besonderen Grund gibt, extra einen Crawler zu betreiben. Es ist kein Zufall, dass sich trotz solcher guten Theorie am Ende Scraper durchsetzen. Das liegt einfach daran, dass der Wert den enormen Aufwand nicht rechtfertigt.
Der „vollständige Crawler“, von dem diese Person spricht, mag theoretisch gut klingen, läuft am Ende aber nur darauf hinaus, Daten mit etwas höherer Wahrscheinlichkeit zu extrahieren. Für heutige KI und ähnliche Bereiche ist das ein schwer nutzbares Mittelding. Die Wartung ist nicht billig, die extrahierten Daten sind nicht vollständig, die Verwaltung ist mühsam, und rechtliche Probleme gibt es ebenfalls viele. Statt all diese Punkte zu berücksichtigen, ist es für Einzelpersonen oder Unternehmen wirtschaftlicher, einfach ein paar Scraper auf großen Websites laufen zu lassen. Ein gut analysierter und sauber gebauter Scraper für eine große Website ist um ein Vielfaches wirtschaftlicher und bequemer, als 10.000 nutzlose Websites abzuklappern. Einen einzigen Crawler breit angelegt und „gut“ zu betreiben, ist selbst mit mehreren Master- und Promotionsabsolventen schwierig. Wenn man den Crawler auch noch überwachen und die Logik laufend anpassen muss, wird es noch schlimmer. Allein die Logs wären gewaltig, sodass selbst das verteilt verarbeitet werden müsste.
Natürlich stimme ich vollkommen zu, dass Crawler eine zentrale Grundlage sind und wichtig bleiben, aber ich frage mich, ob man so ein Argument wirklich ein ganzes Jahr lang vorbringen musste, während man dabei Crawler und Scraper künstlich in Klassen einteilt.
Auch jetzt verstehe ich nicht, warum diese Person Scrapy so ignoriert. Zumindest was Optionen und Erweiterungen angeht, dürfte es deutlich mehr bieten als gocolly.
Nun ja, je nach persönlicher Sichtweise mag das unterschiedlich sein, aber ich arbeite selbst in einem Team für Big-Data-Erfassung und hinterlasse daher meine bescheidene Meinung.
Dem stimme ich zu.
Da es offenbar noch ein unvollständiger Artikel ist, gibt es ein paar Stellen, an denen es so wirkt, als würde noch Inhalt fehlen, der eigentlich vorhanden sein sollte.
Bei der in der Mitte erwähnten Besuchs-Neuplanung: Bezieht sich [Lambda Crawl] auf das Paper Effective Page Refresh Policies For Web Crawlers? Wenn man nach diesem Stichwort sucht, findet man nämlich jede Menge Geschichten darüber, mit Lambdas serverlosem AWS-Dienst zu crawlen und Ähnliches. In der untenstehenden Literaturliste scheint dieses Paper selbst aber nicht aufgeführt zu sein …
http://ilpubs.stanford.edu:8090/604/1/2003-44.pdf
Dieses Paper, „Tractable near-optimal policies for crawling“, kommt darin vor.