Web Scraping im großen StilEin vollständiger Leitfaden

Ein paar hundert Seiten zu scrapen ist ein Skript. Millionen zu scrapen ist ein System. Sobald Ihre Zielanzahl von "läuft über Nacht auf meinem Laptop" zu "muss diese Woche fertig sein, ohne alles zum Schmelzen zu bringen" wechselt, hört das Schwierige auf, das Parsing zu sein, und wird zu allem drumherum: wie Sie Arbeit in eine Queue einreihen, sie auf Worker verteilen, Blockierungen vermeiden, Fehler wiederholen und das Ergebnis speichern und prüfen. Dies ist der grundlegende Walkthrough von Large-Scale Web Scraping als Architektur, nicht als Snippet.

Er beschränkt sich auf öffentliche Daten, die in großem Volumen erfasst werden: Produktlisten, Preise, Suchergebnisse, öffentliche Profile und Ähnliches. Die Form der Arbeit ist unabhängig von der Quelle gleich, daher liegt der Fokus auf der Pipeline und den Kompromissen in jeder Stufe, mit expliziten Hinweisen auf die Teile, die Sie nicht selbst bauen sollten.

Was Large-Scale Web Scraping wirklich bedeutet

Large-Scale Web Scraping ist die Praxis, Daten aus Millionen von Seiten zu extrahieren, entweder von einer riesigen Website oder von Tausenden kleinerer gleichzeitig. Der Sprung vom regulären Scraping ist nicht nur eine größere Zahl, und eine Zahl macht es konkret. Stellen Sie sich eine Kategorie mit 20.000 Listingseiten vor, jeweils 20 Einträge, also 400.000 Seiten zum Abrufen. Bei realistischen 2,5 Sekunden pro Seite dauert ein streng sequenzieller Lauf etwa 1.000.000 Sekunden, also ungefähr 11,5 Tage Warten auf Seitenladevorgänge, bevor Sie ein einziges Feld parsen. Diese Zahl ist der ganze Grund, warum dieser Artikel existiert: Bei großem Maßstab ist Zeit die Einschränkung, und Parallelität ist das Mittel, sie zurückzugewinnen. 200 Seiten parallel zu verarbeiten lässt diese 11,5 Tage auf etwa eine Stunde Echtzeit schrumpfen.

Die Architektur auf einen Blick

Ein Scraper, der Millionen von Seiten überlebt, ist ein kleines verteiltes System mit einer Handvoll benannter Teile. Jeder löst ein Problem, das nur bei großem Volumen auftaucht.

• Eine Queue hält die noch abzurufenden URLs und entkoppelt Discovery von der Arbeit, sodass Produzenten und Konsumenten in ihrem eigenen Tempo laufen können.
• Asynchrone oder verteilte Worker ziehen aus der Queue und führen das Abrufen gleichzeitig durch. Hier kommen die Einsparungen bei der Echtzeit her.
• Eine Proxy- und Anti-Bot-Schicht rotiert IPs und präsentiert Traffic, den Ziele wie einen echten Browser lesen, sodass eine einzelne Adresse niemals ein Rate-Limit auslöst.
• Rendering, nur wenn nötig, führt einen Headless Browser für JavaScript-lastige Seiten aus und überspringt ihn für statische, da Rendering das Teuerste ist, was Sie tun können.
• Wiederholungen mit Backoff fangen die vorübergehenden Fehler auf, die bei diesem Volumen garantiert auftreten.
• Deduplizierung verhindert, dass Sie dieselbe URL zweimal abrufen oder speichern.
• Speicherung nimmt die geparsten Zeilen und legt sie an einem abfragbaren Ort ab.
• Monitoring und Datenqualitätsprüfungen sagen Ihnen, dass der Lauf gesund ist und die Ausgabe vertrauenswürdig ist.

Die folgenden Abschnitte gehen diese der Reihe nach durch. Der rote Faden durch alle ist ein Kompromiss zwischen Kontrolle und Betriebsaufwand: jede Schicht selbst aufbauen oder die schwierigsten (Proxies, Anti-Bot, Rendering, Wiederholungen) an eine verwaltete Schicht abgeben und Ihre Zeit mit den Daten verbringen.

Queue zuerst: Discovery von Abruf entkoppeln

Die wichtigste strukturelle Entscheidung ist, eine Queue zwischen "was scrapen" und "das Scrapen tun" zu setzen. Ein Produzent enumeriert URLs (aus einer Sitemap, einem Suchergebnis-Crawl oder einer Datenbank von IDs) und schiebt sie in die Queue; ein Pool von Workern zieht daraus. Keine Seite muss wissen, wie schnell die andere geht, und Sie können Worker hinzufügen, ohne den Produzenten zu berühren.

In Python ist das üblicherweise Celery oder RQ über Redis; in Node eine Bull- oder BullMQ-Queue über Redis; bei größerem Maßstab ein echter Broker wie RabbitMQ oder Kafka. Ein minimales Worker-Skript macht das Muster konkret.

import asyncio
import aiohttp

CONCURRENCY = 50
queue = asyncio.Queue()

async def worker(name, session):
    while True:
        url = await queue.get()
        try:
            async with session.get(url) as resp:
                html = await resp.text()
                parse_and_store(url, html)
        except Exception as err:
            print(f'failed {url}: {err}')
        finally:
            queue.task_done()

async def run(urls):
    for u in urls:
        queue.put_nowait(u)
    async with aiohttp.ClientSession() as session:
        workers = [asyncio.create_task(worker(i, session)) for i in range(CONCURRENCY)]
        await queue.join()
        for w in workers:
            w.cancel()

Das ist die gesamte Idee in einer Datei: ein begrenzter Pool gleichzeitiger Worker, der eine gemeinsame Queue leert. Der entscheidende Regler ist CONCURRENCY. Zu niedrig verschwendet die Parallelität, die Skalierung erst möglich macht; zu hoch überlastet sowohl das Ziel als auch Ihren eigenen Ausgang. Den richtigen Wert finden Sie, indem Sie beobachten, wie Fehlerraten steigen, weshalb Monitoring ein erstklassiger Teil des Systems ist.

Proxy-Rotation und Anti-Bot: das, was zuerst bricht

Bei niedrigem Volumen bemerken Sie Anti-Bot-Abwehr kaum; bei großem Maßstab bricht sie den Lauf zuerst. Senden Sie ein paar hunderttausend Anfragen von einer IP und Sie werden ratenbegrenzt, dann herausgefordert, dann blockiert. Die Lösung ist Rotation: Anfragen über viele Adressen verteilen, sodass keine einzelne missbräuchlich aussieht.

Die Art des Proxys spielt eine Rolle. Datacenter-IPs sind günstig und schnell, aber leicht per Fingerprint zu identifizieren und in großen Mengen zu blockieren. Residential Proxies leiten über echte Verbraucherverbindungen weiter und werden wie normale Benutzer wahrgenommen, was harte kommerzielle Ziele erwarten. Für die meisten großen Jobs ist der richtige Standard ein Pool aus rotierenden Residential Proxies, bei denen jede Anfrage oder kurze Sitzung von einer frischen Real-User-IP ausgeht. Wenn Sie das selbst zusammenstellen, ist das Richtigstellen der Rotationslogik (Sticky Sessions, wo eine Website sie benötigt, frische IPs, wo nicht) der größte Teil der Arbeit; siehe wie man rotierende Proxies verwendet.

Rotation ist notwendig, aber nicht hinreichend. Moderne Abwehrsysteme lesen auch TLS-Fingerprints, Header-Reihenfolge und Browser-Verhalten. Eine verwaltete Schicht wie der Crawlbase Smart AI Proxy kombiniert Rotation und Fingerprint-Behandlung in einem einzigen Endpunkt: Sie richten Ihren vorhandenen HTTP-Client auf eine Proxy-URL und er verwaltet den Pool, die Header und Wiederholungen bei Blockierungen dahinter. Für das vollständige Defensive-Playbook siehe wie man Websites scrapt, ohne blockiert zu werden.

Nur rendern, wenn es sein muss

Eine Seite in einem Headless Browser zu rendern ist die teuerste Operation in der Pipeline: sie kostet CPU, Arbeitsspeicher und Sekunden pro Seite, und bei einer Million Seiten dominieren diese Sekunden alles. Rendern Sie also nur, wenn die Daten es wirklich erfordern.

Viele Websites liefern ihre Daten noch im initialen HTML oder stellen sie über einen JSON-Endpunkt bereit, den die Seite aufruft. Für diese ist ein einfacher HTTP-Abruf plus Parser um eine Größenordnung günstiger als ein Browser. Reservieren Sie Rendering für Seiten, die Inhalte clientseitig aufbauen, wo ein roher Abruf eine leere Hülle zurückgibt. Die Disziplin ist einfach: zuerst den günstigen Weg versuchen, die Felder bestätigen und nur für Seiten auf Rendering eskalieren, die es brauchen. Beides in einem Lauf zu mischen (statischer Abruf für Katalogseiten, Rendering für die wenigen JS-lastigen Detailseiten) ist normal und dort liegen die Einsparungen.

Die verwaltete Skalierungsschicht: Crawling API und der asynchrone Crawler

Proxies, Anti-Bot und Rendering sind die drei Schichten, die am schwierigsten zu bauen und gesund zu halten sind, und genau das verwaltet Crawlbase für Sie. Die Crawling API ist ein einzelner Aufruf, der eine URL hinter rotierenden Residential IPs abruft, die Anti-Bot-Herausforderung behandelt, die Seite optional mit einem echten Browser rendert und fertiges HTML zurückgibt. Sie entscheiden pro Anfrage, ob gerendert werden soll, indem Sie ein JavaScript-Token hinzufügen; statische Seiten bleiben günstig und JS-lastige Seiten erhalten einen Browser.

from crawlbase import CrawlingAPI

api = CrawlingAPI({ 'token': 'YOUR_CRAWLBASE_TOKEN' })

options = {
    'ajax_wait': 'true',
    'page_wait': 3000,
    'country': 'US',
}

resp = api.get('https://www.example.com/products?page=42', options)
if resp['status_code'] == 200:
    parse_and_store(resp['body'])

Synchrone Aufrufe passen perfekt in den obigen Worker-Pool: Jeder Worker ruft api.get auf und die API übernimmt Proxy, Anti-Bot und Rendering. Aber für wirklich große Jobs gibt es ein besseres Muster. Der asynchrone Crawler kehrt den Fluss um: Statt eine Verbindung offen zu halten, während jede Seite abgerufen wird, übergeben Sie URLs und er crawlt sie nach eigenem Zeitplan, dann postet er jede fertige Seite zurück an einen Webhook-Endpunkt, den Sie kontrollieren. Sie fügen zwei Parameter zum Crawling-API-Aufruf hinzu, &callback=true&crawler=YourCrawlerName, und der Crawler übernimmt Queuing, Scheduling und Wiederholungen.

from crawlbase import CrawlingAPI

api = CrawlingAPI({ 'token': 'YOUR_CRAWLBASE_TOKEN' })

# Push as many URLs as you like; the Crawler queues and crawls them async,
# then POSTs each finished page to the webhook on your registered crawler.
for url in urls_to_crawl:
    api.get(url, {
        'callback': 'true',
        'crawler': 'my-products-crawler',
    })

Das asynchrone Modell ist die richtige Wahl für Millionen von Seiten, weil es den Teil des Systems entfernt, den Sie sonst beaufsichtigen würden. Sie halten keine Verbindungen offen, betreiben keine Render-Flotte und verwalten keine Wiederholungs-Queue; Sie übergeben und empfangen. Der Crawler überwacht sogar Ihren Webhook: Wenn Ihr Endpunkt ausfällt, pausiert er, benachrichtigt Sie, wiederholt die fehlgeschlagene Lieferung und setzt automatisch fort, wenn Ihr Server wieder läuft. Das ist Queuing, Scheduling, Wiederholungen und Lieferzuverlässigkeit als verwaltete Schicht, was der größte Teil dessen ist, was der Rest dieses Artikels Sie zu bauen auffordert.

Wiederholungen und Backoff: Fehler sind der Normalzustand

Bei einer Million Anfragen ist eine 1%-ige vorübergehende Fehlerrate 10.000 fehlgeschlagene Seiten. Fehler sind bei diesem Volumen kein Ausnahmefall; sie sind der Normalzustand, und Ihre Pipeline muss einen fehlgeschlagenen Abruf als Routine behandeln, nicht als fatal. Das Muster ist Wiederholung mit exponentiellem Backoff und einem Cap: kurz warten, dann länger, dann noch länger, und nach einigen Versuchen die URL in eine Dead-Letter-Queue verschieben, statt den Lauf zu blockieren.

Die Nuance liegt im Lesen warum eine Anfrage fehlgeschlagen ist, weil nicht jeder Fehler eine Wiederholung verdient. Ein Timeout oder ein 503 ist es wert, erneut zu versuchen; ein hartes 404 nicht. Bei Proxy-Traffic erhalten Sie auch proxy-spezifische Status-Signale, die Ihnen sagen, ob Sie zurückgehen, rotieren oder die IP-Schicht eskalieren sollen; diese als Signal statt als Rauschen zu behandeln hält einen langen Lauf gesund. Siehe wie man Proxy-Status-Fehlercodes löst für die vollständige Zuordnung. Eine verwaltete Schicht wiederholt Blockierungen intern, aber Sie besitzen weiterhin Wiederholungen für Ihre eigene Logik und Speicherung.

Deduplizierung: Nicht dieselbe Seite zweimal crawlen

Discovery bei großem Maßstab produziert ständig Duplikate: dasselbe Produkt über drei Kategoriepfade erreichbar, Tracking-Parameter, die eine Seite wie zehn aussehen lassen, Paginierung, die in Schleifen geht. Ohne Dedup verschwenden Sie Budget damit, Seiten erneut abzurufen, und korrumpieren Ihren Datensatz mit wiederholten Zeilen.

Zwei Schichten behandeln es. Erstens: Normalisieren Sie URLs, bevor sie in die Queue eingehen: Tracking-Parameter entfernen, Host kleinschreiben, Query-Keys sortieren, relative Links in eine kanonische Form auflösen. Zweitens: Halten Sie ein Seen-Set (ein Redis-Set oder ein Bloom-Filter für sehr große Läufe) und überspringen Sie jede URL, die bereits darin ist. Ein Bloom-Filter tauscht eine winzige False-Positive-Rate gegen eine massive Speichereinsparung ein, der richtige Kompromiss, wenn Seen-Sets Hunderte von Millionen erreichen. Deduplizieren Sie auch die Ausgabe: schlüsseln Sie Zeilen auf einen stabilen Identifier, sodass eine zweimal abgerufene Seite nicht zu zwei Datensätzen wird.

Speicherung: Den Speicher dem Zugriffsmuster anpassen

Wo die Daten landen, hängt davon ab, was Sie als nächstes damit tun. Flat-Files (CSV, JSONL) oder Objektspeicher eignen sich für append-lastige Archivierung und günstige Bulk-Verarbeitung. Eine relationale Datenbank passt, wenn Sie Zeilen abfragen, verknüpfen und aktualisieren müssen. Ein Document Store passt für semistrukturierte Datensätze, deren Form je nach Quelle variiert. Der Fehler ist, alles in eine davon zu zwingen, weil sie die erste zur Hand war.

Zwei skalierungsspezifische Gewohnheiten sind wichtig. Schreiben Sie in Batches, nicht eine Zeile pro Anfrage, damit Speicherung nicht Ihr Engpass ist; der Worker sollte puffern und spülen. Und trennen Sie Roh- von Parsed-Daten: Behalten Sie das ursprüngliche HTML (oder eine Referenz darauf), damit Sie erneut parsen können, ohne erneut zu crawlen, wenn sich Selektoren ändern oder Sie ein neues Feld finden. Crawlbase kann Seiten direkt an Cloud Storage oder Ihren Webhook liefern, was die Aufnahme-Klempnerei von Ihrer Seite entfernt.

Monitoring und Datenqualität

Ein großer Lauf ist ohne Instrumentierung undurchsichtig. Sie möchten Live-Zähler für abgerufene Seiten, Erfolgsrate, Fehlerrate nach Typ, Queue-Tiefe und Durchsatz, damit Sie einen Block-Sturm oder eine feststeckende Queue sehen können, während er passiert, anstatt im leeren Datensatz von morgen. Queue-Tiefe, die steigt, während der Durchsatz fällt, bedeutet, dass Worker feststecken; ein Anstieg an Herausforderungen bedeutet, dass es Zeit ist, zurückzugehen oder stärker zu rotieren.

Datenqualität ist die Hälfte des Monitorings, die Teams überspringen, und die Hälfte, die bestimmt, ob die Daten verwendbar sind. Ein Lauf kann 100% HTTP-Erfolg melden und trotzdem Müll produzieren, wenn sich das Layout geändert hat und Ihre Selektoren jetzt nichts treffen. Fügen Sie günstige, kontinuierliche Prüfungen hinzu: Behaupten Sie, dass erforderliche Felder nicht leer sind, dass Preise als Zahlen in einem vernünftigen Bereich geparst werden, dass die Zeilenzahl pro Seite ungefähr dem entspricht, was Sie erwarten. Wenn eine Prüfung über viele Seiten gleichzeitig fehlschlägt, hat sich das Markup verändert und Ihr Parser braucht Aufmerksamkeit. Besser, das auf Seite 5.000 zu erkennen als nach dem Speichern von fünf Millionen leerer Zeilen.

Wo die Build-vs-Buy-Grenze liegt

Alles Oben Genannte ist baubar, also ist die ehrliche Frage, welche Teile Ihre Engineering-Zeit wert sind. Das Datenmodell, die Parsing-Logik, Qualitätsprüfungen und das Speicherschema sind spezifisch für Ihr Projekt und nur Sie können sie gut bauen. Der Proxy-Pool, Anti-Bot-Behandlung, Headless-Render-Flotte und asynchrone Wiederholungs-und-Lieferungs-Queue sind generische Infrastruktur, die teuer zu bauen und mühsam zu gesund zu halten ist, wenn sich Ziele entwickeln. Das ist die Grenze, auf der eine verwaltete Skalierungsschicht sitzt: Verwenden Sie die Crawling API oder den asynchronen Crawler für Abruf, Rendering und Anti-Bot; den Smart AI Proxy, um Ihren eigenen Client zu behalten und einen verwalteten rotierenden Endpunkt einzutauschen; oder die Crawling API für geparste JSON-Daten von unterstützten Seiten, um Selektoren vollständig zu überspringen. Verbringen Sie Ihre Zeit mit den Daten; mieten Sie die Teile, die für alle gleich sind.

Häufig gestellte Fragen

Was gilt als Large-Scale Web Scraping?

Grob gesagt jeder Job, der so groß ist, dass ein einzelnes sequenzielles Skript nicht mehr praktikabel ist, was in der Praxis Hunderttausende bis Millionen von Seiten bedeutet, über eine große Website oder viele kleinere hinweg. Das definierende Merkmal ist nicht die Zahl, sondern dass Sie jetzt Parallelität, Proxy-Rotation, Wiederholungen und Monitoring benötigen, um in angemessener Zeit fertig zu werden, ohne blockiert zu werden. Unterhalb dieser Schwelle ist eine einfache Schleife in Ordnung; darüber betreiben Sie ein kleines verteiltes System.

Wie scrapt man Millionen von Seiten, ohne blockiert zu werden?

Verteilen Sie Anfragen über viele IPs, sodass keine einzelne Adresse missbräuchlich aussieht, bevorzugen Sie rotierende Residential Proxies für harte Ziele, präsentieren Sie Traffic, der wie ein echter Browser aussieht, drosseln Sie Ihre Anfragen und gehen Sie zurück, wenn Herausforderungen auftauchen. All das selbst zu bauen ist erhebliche Arbeit, daher leiten die meisten Teams durch eine verwaltete Schicht wie die Crawling API oder den Smart AI Proxy, die Rotation, Fingerprints und Challenge-Solving hinter einem Endpunkt behandeln.

Soll ich synchrones oder asynchrones Scraping bei großem Maßstab verwenden?

Asynchron, für alles wirklich Große. Synchrones Abrufen hält eine Verbindung pro Seite offen und bindet einen Worker, bis jede Anfrage abgeschlossen ist. Das asynchrone Crawler-Modell lässt Sie URLs übergeben und fertige Seiten auf einem Webhook-Callback empfangen, sodass Queuing, Scheduling und Wiederholungen serverseitig stattfinden und Ihre Anwendung nicht wartend blockiert ist. Sie übergeben und empfangen, was weit einfacher zu skalieren und zu betreiben ist.

Brauche ich immer einen Headless Browser für Large-Scale Scraping?

Nein, und vermeiden Sie ihn, wo Sie können. Rendering ist der teuerste Schritt pro Seite, also reservieren Sie ihn für Websites, die Inhalte clientseitig aufbauen und einem einfachen Abruf eine leere Hülle zurückgeben. Viele Websites liefern verwendbare Daten im initialen HTML oder stellen einen JSON-Endpunkt bereit, beides weit günstiger abzurufen. Einen günstigen statischen Pfad mit Rendering nur für Seiten zu mischen, die es brauchen, ist der kosteneffektive Standard.

Wie behandle ich Fehler und Duplikate über Millionen von Anfragen?

Behandeln Sie beides als Routine. Wiederholen Sie vorübergehende Fehler (Timeouts, 503s) mit exponentiellem Backoff und einem Cap, dann senden Sie hartnäckige in eine Dead-Letter-Queue statt den Lauf zu blockieren; wiederholen Sie keine harten 404s. Für Duplikate normalisieren Sie URLs vor dem Queuing, halten Sie ein Seen-Set oder Bloom-Filter, um bereits abgerufene URLs zu überspringen, und schlüsseln Sie gespeicherte Zeilen auf einen stabilen Identifier, sodass eine zweimal abgerufene Seite nicht zu zwei Datensätzen wird.

Wo soll ich Daten aus einem großen Scrape speichern?

Passen Sie den Speicher daran an, wie Sie die Daten verwenden werden: Objektspeicher oder JSONL für günstige Archivierung, eine relationale Datenbank, wenn Sie abfragen und verknüpfen müssen, ein Document Store für variabel strukturierte Datensätze. Schreiben Sie in Batches statt einer Zeile pro Anfrage, damit Speicherung nicht der Engpass ist, und behalten Sie das rohe HTML neben der geparsten Ausgabe, damit Sie erneut parsen können, ohne erneut zu crawlen, wenn sich Selektoren ändern oder Sie ein Feld hinzufügen.

FA

Farwa Anees

Technische Redakteurin · Crawlbase

Technische Redakteurin, die im Crawlbase-Blog über Proxys, Web Scraping und Dateninfrastruktur schrieb und dichte Netzwerkthemen in Leitfäden verwandelte, die Entwickler tatsächlich zu Ende lesen.