So speichern Sie gescrapte Daten in der Clouddauerhafte Speicherung mit Python

Eine Seite zu scrapen ist nur die halbe Arbeit. Die gesammelten Datensätze müssen irgendwo dauerhaft gespeichert werden, an einem Ort, den Teamkollegen und Analysetools erreichen können, und an einem Ort, den ein Laptop-Absturz nicht auslöschen kann. Eine lokale CSV-Datei ist für eine einmalige Sache in Ordnung, aber sobald ein Scrape zu einer wiederkehrenden Pipeline wird, wird eine einzige Festplatte zur Haftung: Kapazität wird knapp, Übertragungen zwischen Maschinen werden umständlich, und ein Festplattenausfall kostet Arbeit, die man nicht zurückbekommt.

Diese Anleitung zeigt, wie man gescrapte Daten in der Cloud speichert mit Python, von Anfang bis Ende. Es wird ein kleiner, ausführbarer Ablauf gebaut, der eine Seite über die Crawling API abruft, die Ergebnisse in saubere Datensätze strukturiert und sie dann in dauerhafte Cloud-Ziele schreibt: einen Objektspeicher mit S3-kompatiblen Buckets und eine verwaltete relationale Datenbank. Alles hier verwendet eine neutrale Beispiel-URL und Umgebungsvariablen-Platzhalter für Anmeldedaten, sodass man es auf das eigene Ziel und den eigenen Anbieter anpassen kann, ohne die Code-Struktur zu ändern.

Was man bauen wird

Ein Python-Skript, das ein kleines Dataset von einer öffentlichen Beispiel-Listing-Seite über die Crawling API scrapt, jede Zeile in einen typisierten Datensatz normalisiert und diese Datensätze auf zwei Arten in die Cloud schickt. Man kann einen oder beide Pfade behalten. Die Komponenten sind:

• Scrapen einer gerenderten Seite, die über die Crawling API abgerufen wird und fertiges HTML zurückgibt.
• Transformieren des rohen HTML in eine Liste strukturierter Datensätze mit konsistenten Feldnamen und Typen.
• Objektspeicher: eine JSON-Lines-Datei, die in einen S3-kompatiblen Bucket für günstige, dauerhafte Archivierung hochgeladen wird.
• Verwaltete Datenbank: dieselben Datensätze, die in eine Postgres-Tabelle für Abfragen und Joins eingefügt werden.
• Crawlbase Cloud Storage: ein optionaler Ein-Parameter-Pfad, der die rohe Crawl-Antwort serverseitig speichert.

Warum gescrapte Daten in der Cloud speichern

Lokaler Speicher ist praktisch, bis er es nicht mehr ist. Wenn ein Scrape von einigen hundert Zeilen zu einem wiederkehrenden Job wächst, der ein Dashboard speist, treten drei Probleme gleichzeitig auf. Kapazität wird zu einem wiederkehrenden Kostenpunkt: man kauft Festplatten, um Backups sicher aufzubewahren, und verbringt Zeit damit, sie zu verwalten. Zugang wird umständlich: Daten, die auf einer Maschine eingeschlossen sind, sind schwer mit einem Team zu teilen oder in ein Tool einzuspeisen, das woanders läuft. Und Haltbarkeit ist fragil: Stromprobleme, Firmware-Korruption und menschliche Fehler können eine einzelne Festplatte zum Absturz bringen, und mit ihr jede Arbeit, die nicht irgendwo anders kopiert wurde.

Cloud-Speicher beantwortet alle drei. Objektspeicher und verwaltete Datenbanken sind für Redundanz ausgelegt, sodass Daten über Standorte hinweg repliziert werden, anstatt auf einem Laufwerk zu sitzen. Sie skalieren, ohne dass man Hardware bereitstellen muss, sind von überall mit Anmeldedaten erreichbar und übergeben Backup und Haltbarkeit an den Anbieter. Für eine Scraping-Pipeline bedeutet das, dass man gesammelte Daten vom Moment ihrer Ankunft als dauerhaftes Gut behandeln kann, nicht als etwas, das man auf einer lokalen Festplatte betreuen muss.

Zwei Ziele und wann man welches verwendet

Dieses Tutorial schreibt in zwei Arten von Cloud-Speicher, weil gescrapte Daten normalerweise beide wollen. Objektspeicher (S3-kompatible Buckets) ist das richtige Zuhause für rohe und archivarische Daten: günstig pro Gigabyte, gleichgültig gegenüber der DateiForm, und ideal für die Aufbewahrung der unberührten Scrape-Ausgabe, sodass man sie später erneut verarbeiten kann. Eine verwaltete relationale Datenbank (hier Postgres) ist das richtige Zuhause für die strukturierte, abfragbare Kopie, wo konsistente Spalten und Typen das Filtern, Aggregieren und Joinen mit SQL ermöglichen. Das übliche Muster ist, in beide zu schreiben, und der folgende Code tut genau das. Für einen tieferen Vergleich siehe Cloud-Speicher vs. lokaler Speicher und die Vorteile von Cloud-Speicher.

Voraussetzungen

Ein paar Dinge sollten vorhanden sein, bevor man irgendeinen Code schreibt. Keines davon dauert lange.

Python 3.8 oder höher. Version mit python --version bestätigen. Falls nicht vorhanden, von python.org oder über eine Distribution wie Anaconda installieren und sicherstellen, dass Python im PATH ist.

Ein Crawlbase-Konto und Token. Anmelden, das Dashboard öffnen und das Token kopieren. Crawlbase umfasst bis zu 20.000 kostenlose Anfragen zum Start, was für diese Anleitung mehr als ausreichend ist. Das Token wie ein Passwort behandeln und aus der Versionskontrolle heraushalten. Wenn das Ziel Inhalte clientseitig rendert, das JavaScript-Token verwenden; für eine statische Seite reicht das normale Token.

Cloud-Anmeldedaten. Für den Objektspeicher-Pfad wird ein S3-kompatibler Bucket und ein Zugriffsschlüsselpaar benötigt. Für den Datenbankpfad wird ein Verbindungsstring zu einer verwalteten Postgres-Instanz benötigt. Beide werden im folgenden Code über Umgebungsvariablen bereitgestellt, nie fest kodiert.

Vertrautheit mit Python und grundlegendem Scraping. Wer mit der Parsing-Seite noch nicht vertraut ist, findet im BeautifulSoup-Leitfaden und der Scraping mit Python-Anleitung gute Begleiter.

Das Projekt einrichten

Eine virtuelle Umgebung erstellen, damit Abhängigkeiten isoliert bleiben, dann die Bibliotheken installieren, die der Ablauf benötigt.

python --version

python -m venv cloud_env
source cloud_env/bin/activate

pip install crawlbase beautifulsoup4 boto3 psycopg2-binary

Unter Windows die Umgebung mit cloud_env\Scripts\activate statt der source-Zeile aktivieren. Vier Abhängigkeiten erledigen die Arbeit: crawlbase ist der offizielle Client für die Crawling API, beautifulsoup4 parsed das zurückgegebene HTML, boto3 kommuniziert mit S3-kompatiblem Objektspeicher, und psycopg2-binary verbindet sich mit Postgres. Das json-Modul wird mit der Standardbibliothek geliefert, sodass das Archivformat nichts Zusätzliches benötigt.

Schritt 1: Eine Seite über die Crawling API scrapen

Zuerst eine fertige Seite abrufen. Die CrawlingAPI-Klasse importieren, mit dem Token initialisieren und die Ziel-URL anfordern. Das Crawlbase-cb_status (legacy pc_status) vor dem Parsen zu prüfen hält Fehler laut statt still. Hier wird eine neutrale Beispiel-Listing-Seite verwendet; beim Anpassen des Ablaufs durch die eigene URL ersetzen.

from crawlbase import CrawlingAPI

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

def crawl(page_url):
    response = api.get(page_url)
    if response["headers"]["cb_status"] == "200":
        return response["body"].decode("utf-8")
    print(f"Request failed: {response['headers']['cb_status']}")
    return None

if __name__ == "__main__":
    page_url = "https://example.com/products"
    html = crawl(page_url)
    print(html[:500] if html else "No HTML returned")

Mit python cloud_pipeline.py ausführen und echtes Seiten-Markup sollte ausgegeben werden, was bestätigt, dass der Abruf funktioniert, bevor man einen einzigen Selektor schreibt. Wenn das Ziel Inhalte clientseitig füllt, den Client mit dem JavaScript-Token initialisieren und {"ajax_wait": "true", "page_wait": 5000} an api.get übergeben, damit die API die Seite zuerst rendert. Für JS-intensive Ziele behandelt die Anleitung JavaScript-Seiten mit Python scrapen die Details.

Schritt 2: Das HTML in strukturierte Datensätze transformieren

Rohes HTML ist nichts, was man direkt in einer Datenbank speichern möchte. Der Transform-Schritt wandelt es in eine Liste von Wörterbüchern mit konsistenten Feldnamen und Typen um, sodass jeder Datensatz dieselbe Form hat. Das HTML in BeautifulSoup laden, jeden Artikel auf der Seite durchlaufen und die gewünschten Felder herausziehen. Die Selektoren hier sind illustrativ; sie durch die ersetzen, die zum eigenen Ziel passen.

from bs4 import BeautifulSoup

def text_of(node, selector):
    el = node.select_one(selector)
    return el.get_text(strip=True) if el else None

def to_price(raw):
    if not raw:
        return None
    digits = raw.replace("$", "").replace(",", "").strip()
    return float(digits) if digits.replace(".", "").isdigit() else None

def transform(html):
    soup = BeautifulSoup(html, "html.parser")
    records = []
    for card in soup.select("div.product"):
        records.append({
            "name": text_of(card, "h2.title"),
            "price": to_price(text_of(card, "span.price")),
            "sku": text_of(card, "span.sku"),
            "in_stock": text_of(card, "span.stock") == "In stock",
        })
    return [r for r in records if r["name"]]

Drei kleine Hilfsfunktionen halten die Datensätze sauber. text_of gibt den bereinigten Text eines Elements oder None zurück, wenn es fehlt, sodass eine Lücke in einer Karte die Schleife nicht zum Absturz bringt. to_price entfernt das Währungssymbol und Tausendertrennzeichen und wandelt in einen Float um, sodass die Datenbankspalte numerisch statt Text sein kann. Der abschließende Filter lässt Zeilen ohne Namen heraus, die meist Layout-Artefakte statt echter Einträge sind. Das Ergebnis ist eine Liste typisierter Datensätze, bereit zum Speichern. Für mehr zur guten Gestaltung gescrapter Daten siehe Strukturieren und Bereinigen von Web-Scraping-Daten.

Schritt 3: In S3-kompatiblen Objektspeicher hochladen

Das erste Cloud-Ziel ist ein Objektspeicher. Objektspeicher ist das natürliche Zuhause für rohe oder archivarische Daten: günstig, dauerhaft und gleichgültig gegenüber der Form des Inhalts. Die Datensätze werden als JSON Lines geschrieben (ein JSON-Objekt pro Zeile), was einfach zu ergänzen und später zu streamen ist. Anmeldedaten kommen aus Umgebungsvariablen, sodass nichts Sensibles im Quellcode landet.

import os
import json
import boto3

def upload_to_s3(records, key):
    s3 = boto3.client(
        "s3",
        endpoint_url=os.environ.get("S3_ENDPOINT_URL"),
        aws_access_key_id=os.environ["S3_ACCESS_KEY"],
        aws_secret_access_key=os.environ["S3_SECRET_KEY"],
    )
    body = "\n".join(json.dumps(r) for r in records)
    s3.put_object(
        Bucket=os.environ["S3_BUCKET"],
        Key=key,
        Body=body.encode("utf-8"),
        ContentType="application/x-ndjson",
    )
    print(f"Uploaded {len(records)} records to s3://{os.environ['S3_BUCKET']}/{key}")

Der endpoint_url-Parameter macht dies S3-kompatibel statt nur AWS: für AWS S3 nicht gesetzt lassen, oder auf jeden S3-kompatiblen Anbieter zeigen (zum Beispiel eine selbst gehostete MinIO-Instanz oder den Objektspeicher eines anderen Cloud-Anbieters). Die vier Umgebungsvariablen vor dem Ausführen setzen, zum Beispiel export S3_BUCKET=my-scrape-archive und die passenden Schlüssel. Der Key ist der Objektpfad innerhalb des Buckets; ein datumgestempelter Schlüssel wie scrapes/2026-06-11/products.jsonl hält aufeinanderfolgende Läufe getrennt und leicht auffindbar.

Schritt 4: In eine verwaltete Datenbank einfügen

Das zweite Ziel ist eine verwaltete Postgres-Datenbank, in der die strukturierte Kopie für Abfragen gespeichert wird. Die folgende Funktion öffnet eine Verbindung aus einer einzelnen Umgebungsvariablen, stellt sicher, dass die Zieltabelle existiert, und fügt die Datensätze ein. Die Verwendung parametrisierter Abfragen (die %s-Platzhalter) hält die Werte korrekt maskiert, statt sie in das SQL zu konkatenieren.

import os
import psycopg2
from psycopg2.extras import execute_values

CREATE = """
CREATE TABLE IF NOT EXISTS products (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    price NUMERIC,
    sku TEXT,
    in_stock BOOLEAN,
    scraped_at TIMESTAMPTZ DEFAULT now()
)
"""

def save_to_db(records):
    conn = psycopg2.connect(os.environ["DATABASE_URL"])
    with conn, conn.cursor() as cur:
        cur.execute(CREATE)
        rows = [(r["name"], r["price"], r["sku"], r["in_stock"]) for r in records]
        execute_values(
            cur,
            "INSERT INTO products (name, price, sku, in_stock) VALUES %s",
            rows,
        )
    conn.close()
    print(f"Inserted {len(records)} rows into products")

DATABASE_URL auf den Verbindungsstring der verwalteten Postgres-Instanz setzen, zum Beispiel postgresql://user:pass@host:5432/dbname, und in der Umgebung statt in der Datei belassen. Das CREATE TABLE IF NOT EXISTS macht die Funktion sicher für wiederholte Ausführung, die scraped_at-Spalte stempelt jeden Ladevorgang mit einem Zeitstempel, sodass man Änderungen über die Zeit verfolgen kann, und execute_values bündelt die Einfügungen in eine Runde statt einer Abfrage pro Zeile. Sobald die Zeilen drin sind, kann man mit einfachem SQL filtern und aggregieren und sie dann in pandas zur Analyse ziehen.

Schritt 5: Die vollständige Pipeline zusammensetzen

Jetzt die Schritte zu einem ausführbaren Skript zusammenführen: scrapen, transformieren, dann die Datensätze an beide Ziele senden. Den Speicheraufruf behalten, der zum Workflow passt; beide werden hier gezeigt.

import os
import json
from datetime import date
from crawlbase import CrawlingAPI
from bs4 import BeautifulSoup

# crawl, transform, upload_to_s3 and save_to_db are defined above

def main():
    page_url = "https://example.com/products"
    html = crawl(page_url)
    if not html:
        print("Nothing scraped, stopping.")
        return

    records = transform(html)
    print(f"Parsed {len(records)} records")
    if not records:
        return

    key = f"scrapes/{date.today().isoformat()}/products.jsonl"
    upload_to_s3(records, key)
    save_to_db(records)

if __name__ == "__main__":
    main()

Der Ablauf ist linear und leicht nachzuvollziehen: Seite abrufen, früh beenden, wenn das Scraping fehlgeschlagen ist, das HTML in Datensätze transformieren, erneut beenden, wenn nichts zu speichern ist, dann die Datensätze in den Bucket archivieren und in die Datenbank laden. Der datumgestempelte Objektschlüssel hält das Archiv jedes Laufs getrennt, während die Datenbank jeden Ladevorgang mit einem Zeitstempel akkumuliert. Mit python cloud_pipeline.py ausführen, sobald die Umgebungsvariablen gesetzt sind.

Wie die Ausgabe aussieht

Der Objektspeicher-Pfad schreibt eine JSON-Lines-Datei, einen Datensatz pro Zeile, die im Bucket landet:

{"name": "Aluminium Tripod", "price": 129.99, "sku": "TRP-014", "in_stock": true}
{"name": "USB-C Hub", "price": 39.5, "sku": "HUB-203", "in_stock": false}
{"name": "Wireless Mouse", "price": 24.0, "sku": "MSE-088", "in_stock": true}

Der Datenbankpfad speichert dieselben Datensätze als typisierte Spalten, sodass eine schnelle Abfrage den Ladevorgang bestätigt und die Form zeigt, die man analysieren kann:

SELECT name, price, in_stock FROM products WHERE in_stock = true ORDER BY price;

--      name       | price  | in_stock
-- ----------------+--------+----------
--  Wireless Mouse |  24.00 | t
--  Aluminium Tripod| 129.99 | t

Mit beiden vorhandenen Kopien hat man ein günstiges, dauerhaftes Archiv der rohen Datensätze und eine abfragbare strukturierte Tabelle, die vom selben Lauf geschrieben wurden.

Eine Ein-Parameter-Abkürzung: Crawlbase Cloud Storage

Wenn das Ziel einfach darin besteht, eine serverseitige Kopie jeder Crawl-Antwort aufzubewahren, ohne zunächst einen eigenen Bucket oder eine eigene Datenbank einzurichten, bietet Crawlbase Cloud Storage einen Ein-Parameter-Pfad. &store=true zu einer Crawling-API-Anfrage hinzufügen, und eine Kopie der Antwort wird automatisch in der Cloud gespeichert, wo sie später über die API oder das Dashboard gesucht, abgerufen oder gelöscht werden kann.

from crawlbase import CrawlingAPI

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

response = api.get("https://example.com/products", {"store": "true"})
# the response also includes a storage RID you can use to fetch it later
print(response["headers"].get("storage_url"))

Jede gespeicherte Anfrage erhält einen eindeutigen Bezeichner (eine RID), mit dem man sie anzeigen oder löschen kann. Dieser Pfad ist der schnellste Weg, rohe Antworten aufzubewahren, und er passt gut zum asynchronen Crawler, wenn man viele Anfragen ausführt und die Speicherung serverseitig erledigt haben möchte. Für größere strukturierte Datensätze wird man immer noch eine eigene Datenbank wollen, aber für die Archivierung roher Antworten ist der store-Parameter in punkto Einfachheit schwer zu überbieten.

Die Pipeline skalieren

Der obige Ablauf scrapt eine Seite. Sie zu einem wiederkehrenden Job zu machen geht hauptsächlich um Tempo und Widerstandsfähigkeit. Ein paar Gewohnheiten halten einen größeren Lauf gesund:

• Schreibvorgänge bündeln. Datensätze akkumulieren und in Batches hochladen oder einfügen, statt einen Datensatz nach dem anderen. execute_values bündelt die Datenbank-Einfügungen bereits; dasselbe für Objekt-Uploads tun, indem man eine Datei pro Lauf statt pro Datensatz schreibt.
• Schlüssel mit Datum stempeln. Einen datierten Objektschlüssel wie scrapes/2026-06-11/products.jsonl verwenden, damit jeder Lauf isoliert ist und man nie den Verlauf überschreibt. Die scraped_at-Spalte der Datenbank spielt auf der Abfrageseite dieselbe Rolle.
• Nach Zeitplan ausführen. Das Skript in einen Cron-Job oder eine geplante Aufgabe einwickeln, damit die Cloud-Kopie aktuell bleibt. Da die Tabelle IF NOT EXISTS verwendet und der Bucket-Schlüssel datiert ist, sind Wiederholungsläufe sicher.
• Den Abruf bei großem Maßstab auslagern. Bei vielen Seiten stellt der asynchrone Crawler Anfragen in eine Warteschlange und liefert Ergebnisse an einen Webhook, was für hohes Volumen ohne offene Verbindungen geeignet ist.

Verantwortungsvoll scrapen

Verantwortungsvoll sammeln. Nur öffentliche Daten scrapen, die Nutzungsbedingungen jeder Website und deren robots.txt respektieren und die Anfragerate vernünftig halten, damit man die Server, auf die man angewiesen ist, nicht belastet. Wenn die gesammelten Daten etwas enthalten, das mit identifizierbaren Personen verknüpft ist, gelten Datenschutzgesetze wie DSGVO und CCPA, daher sollte man personenbezogene Daten vermeiden, es sei denn, man hat eine rechtmäßige Grundlage und einen klaren Zweck für ihre Aufbewahrung. Das Speichern von Daten in der Cloud ändert nichts daran: dieselbe Sorgfalt, die man beim Sammeln walten lässt, gilt auch für die Aufbewahrung, und das längere Aufbewahren personenbezogener Daten als nötig fügt nur Risiken hinzu.

Häufig gestellte Fragen

Soll ich gescrapte Daten in Objektspeicher oder in einer Datenbank speichern?

Das hängt davon ab, was man damit macht. Objektspeicher (S3-kompatible Buckets) ist günstig, dauerhaft und ideal für rohe oder archivarische Daten jeder Form, daher ist er das richtige Zuhause für die unberührte Scrape-Ausgabe. Eine verwaltete relationale Datenbank ist für die strukturierte Kopie, die man mit SQL abfragt, filtert und verknüpft. Viele Pipelines schreiben in beide: rohe Datensätze in einem Bucket archivieren und bereinigte Datensätze in eine Datenbank laden.

Wie halte ich meine Cloud-Anmeldedaten aus dem Code heraus?

Sie aus Umgebungsvariablen oder einem Secrets-Manager lesen, statt sie fest zu kodieren. Der Code in dieser Anleitung zieht die S3-Schlüssel und den Postgres-Verbindungsstring aus os.environ, sodass nichts Sensibles in der eingecheckten Datei steht. Ein in die Versionskontrolle eingecheckter Schlüssel ist ein Schlüssel, den man rotieren muss, also in der Umgebung belassen.

Was ist der Unterschied zwischen Crawlbase Cloud Storage und dem Hochladen in den eigenen Bucket?

Crawlbase Cloud Storage ist ein Ein-Parameter-Pfad: &store=true zu einer Crawling-API-Anfrage hinzufügen und die rohe Antwort wird serverseitig gespeichert, über eine RID abrufbar, ohne eigene Infrastruktur einrichten zu müssen. Das Hochladen in den eigenen Bucket oder die eigene Datenbank gibt volle Kontrolle über Format, Schema, Aufbewahrung und Speicherort, was man für strukturierte Datensätze möchte. Die beiden ergänzen sich: der store-Parameter für schnelle Archivierung roher Antworten, eigene Speicher für die verarbeiteten Daten.

Funktioniert der S3-Code auch mit anderen Anbietern als AWS?

Ja. Der boto3-Client nimmt einen endpoint_url-Parameter; für AWS S3 nicht gesetzt lassen, oder auf jeden S3-kompatiblen Anbieter zeigen, wie eine selbst gehostete MinIO-Instanz oder den Objektspeicher eines anderen Clouds. Der Rest des Codes bleibt unverändert, weshalb das Beispiel den Endpunkt aus einer Umgebungsvariablen liest.

Wie führe ich das nach einem Zeitplan aus, damit die Cloud-Kopie aktuell bleibt?

Das Skript in einen Cron-Job oder eine geplante Aufgabe einwickeln, die in dem Rhythmus läuft, in dem sich die Daten ändern. Die Pipeline ist sicher zu wiederholen: die Datenbanktabelle verwendet CREATE TABLE IF NOT EXISTS, der Objektschlüssel ist datumgestempelt, sodass Läufe sich nie gegenseitig überschreiben, und jede Datenbankzeile trägt einen scraped_at-Zeitstempel, sodass man Änderungen über die Zeit verfolgen kann. Für viele Seiten den Abruf an den asynchronen Crawler abgeben, damit der Job nicht an einer Verbindung hängt.

Ist es sicher, gescrapte personenbezogene Daten in der Cloud zu speichern?

Das ist zunächst eine Rechts- und Datenschutzfrage. Das Sammeln von Daten, die mit identifizierbaren Personen verknüpft sind, vermeiden, es sei denn, man hat eine rechtmäßige Grundlage und einen klaren Zweck, da Datenschutzgesetze wie DSGVO und CCPA unabhängig vom Speicherort gelten. Wenn man personenbezogene Daten aufbewahrt, nur das Notwendige speichern, nicht länger als nötig aufbewahren und den Zugriff absichern. Personenbezogene Daten länger als erforderlich aufzubewahren fügt nur Risiken ohne Mehrwert hinzu.

BA

Bilal Ahmed

Softwareentwickler · Crawlbase

Softwareentwickler, der einige der meistgelesenen Beiträge im Crawlbase-Blog verfasst hat, über Web Scraping, Proxys und Daten-Tooling.