Databricks Autoloader: Der komplette Guide für Bronze-Ingestion

TL;DR: Autoloader (cloudFiles) ingestiert neue Files inkrementell aus Cloud-Object-Storage. Drei Dinge musst du richtig machen: immer schemaLocation setzen, schemaEvolutionMode: rescue als Default für Bronze nutzen und _rescued_data in Silver religiös monitoren.

Files aus S3, ADLS oder GCS zu ingestieren klingt simpel — bis du es mit Schema-Drift, Duplicate-Processing und Terabytes pro Stunde zu tun hast. Databricks Autoloader ist das Tool, zu dem die meisten Teams greifen — aber seine Defaults verstecken ein paar scharfe Kanten, die du vor Produktion kennen solltest.

Was ist Databricks Autoloader?

Databricks Autoloader (cloudFiles) ist eine Structured-Streaming-Source, die neue Files inkrementell aus Cloud-Object-Storage ingestiert. Statt bei jedem Lauf den gesamten Storage-Prefix zu scannen, trackt sie, welche Files schon verarbeitet wurden — entweder per File Notification (event-driven, via Cloud-Messaging) oder per Directory Listing (periodischer Scan). Für die meisten Produktions-Use-Cases ist File-Notification-Modus schneller und günstiger.

# PySpark — Autoloader with file notification (ADLS Gen2 example)
df = (
    spark.readStream
    .format("cloudFiles")
    .option("cloudFiles.format", "json")
    .option("cloudFiles.schemaLocation", "/mnt/checkpoints/landing_schema")
    .option("cloudFiles.useNotifications", "true")   # file notification mode
    .load("abfss://raw@storageaccount.dfs.core.windows.net/events/")
)

(
    df.writeStream
    .format("delta")
    .option("checkpointLocation", "/mnt/checkpoints/landing_checkpoint")
    .option("mergeSchema", "true")
    .outputMode("append")
    .table("bronze.raw_events")
)

Der schemaLocation-Parameter ist in der Praxis nicht optional — dort persistiert Autoloader das inferierte Schema zwischen Läufen. Ohne ihn wird bei jedem Restart neu inferiert.

Schema-Inferenz und Evolution

Autoloader kann Schemas automatisch aus deinen Files inferieren. Für JSON und CSV sampelt es die ersten cloudFiles.inferColumnTypes-Zeilen (Default: 10.000) und schreibt das inferierte Schema in den schemaLocation. Bei späteren Läufen liest es von dort statt neu zu inferieren.

# Schema inference options
.option("cloudFiles.inferColumnTypes", "true")   # infer int/long vs string
.option("cloudFiles.schemaEvolutionMode", "addNewColumns")  # | rescue | failOnNewColumns | none

Schema-Evolution-Modi — wann welcher:

Für die meisten Bronze-Ingestion-Layer ist rescue der richtige Default — du verlierst nie Daten, und du kannst _rescued_data in Silver inspizieren, um Edge-Cases zu behandeln.

Rescue-Data: dein Sicherheitsnetz

Die _rescued_data-Spalte ist Autoloaders meist unterschätztes Feature. Jedes Feld, das nicht zum aktuellen Schema passt, landet hier als JSON-String — inklusive malformed Values, unerwarteter Typen und tatsächlich neuer Felder.

# Spark SQL — inspect rescued data in bronze table
SELECT
    event_id,
    event_time,
    _rescued_data,
    _metadata.file_path AS source_file,
    _metadata.file_modification_time AS file_ts
FROM bronze.raw_events
WHERE _rescued_data IS NOT NULL
LIMIT 100;

Die _metadata-Spalte (automatisch von Autoloader ergänzt) liefert Source-File-Pfad, Modification-Time und Größe — unbezahlbar für Debugging und Auditing.

# Promote rescued fields to proper columns in silver
from pyspark.sql.functions import col, get_json_object

silver_df = (
    spark.table("bronze.raw_events")
    .withColumn("new_field", get_json_object(col("_rescued_data"), "$.new_field").cast("string"))
    .filter(col("event_id").isNotNull())
)

File Notification vs Directory Listing

Die Wahl zählt für Latenz und Kosten:

Für Dev/Test: Directory Listing. Für Produktion mit hohen File-Volumen: File Notification. Du kannst später wechseln — der Checkpoint ist format-agnostisch.

Häufige Fehler und Pitfalls

1. schemaLocation beim ersten Lauf vergessen Autoloader setzt Schema-Evolution ohne Schema-Location nicht durch. Stream funktioniert, infiziert aber bei jedem Restart neu.

2. Gleichen schemaLocation für mehrere Streams Jeder Autoloader-Stream braucht seinen eigenen schemaLocation. Teilen führt zu Schema-Korruption.

3. _rescued_data in Silver nicht behandeln Wenn du diese Spalte in Silver droppst, ohne sie zu verarbeiten, verlierst du bei jedem Schema-Mismatch still Daten.

4. Directory-Listing auf tiefen Prefix-Hierarchien s3://bucket/ rekursiv mit Millionen Files zu listen erzeugt teure, langsame LIST-API-Calls. Pfad immer auf den spezifischsten Prefix scopen.

5. mergeSchema ohne Monitoring mergeSchema: true ohne _rescued_data-Monitoring bedeutet, dass deine Silver-Tabellen still Schema-Drift akkumulieren.

Produktions-Setup-Checkliste

- schemaLocation definiert und gebackupt
- checkpointLocation auf dauerhaftem Storage (nicht ephemeral)
- cloudFiles.schemaEvolutionMode explizit gesetzt
- _rescued_data-Spalte mit Alerts monitort
- _metadata-Spalten für Lineage verfügbar
- File Notification konfiguriert (Produktion)
- mergeSchema: true für Delta-Sink
- Separater Stream pro Datenquelle (keine geteilten Schema-Locations)

Wann Autoloader NICHT das richtige Tool ist

Autoloader glänzt für file-basierte Ingestion aus Object-Storage. Er ist nicht passend für:

• API-Polling — Structured Streaming mit Custom-Source oder Kafka nutzen
• Datenbank-CDC — Debezium + Kafka + Delta Live Tables
• Echtzeit-Sub-Sekunden-Latenz — Event Hub / Kafka sind schneller und zuverlässiger
• Festes Schema, hohes Volume, keine Evolution — ein simples COPY INTO ist oft einfacher und billiger

Wenn du Daten aus REST-APIs ziehst statt aus Files, sind Databricks Asset Bundles kombiniert mit Scheduled-Jobs oft das sauberere Pattern. Für den Silver-zu-Gold-Transformations-Layer: Guide zur Delta-Table-Optimierung.

Harbinger Explorer fürs Autoloader-Debugging

Sobald deine Bronze-Daten in Delta gelandet sind, willst du sie inspizieren — besonders _rescued_data und _metadata. Wenn kein Databricks-SQL-Endpoint griffbereit ist, lässt Harbinger Explorer dich einen Delta-Export oder Sample-CSV/JSON aus deinem Landing-Zone hochladen und SQL direkt im Browser via DuckDB WASM laufen lassen. Nützlich für schnelle Schema-Validierung und Rescued-Data-Inspektion ohne Warehouse hochzufahren.

FAQ

Wie verhält sich Autoloader bei DSGVO-Lösch-Anfragen?

Autoloader selbst kennt keine Lösch-Semantik — er ingestiert nur. Lösch-Anfragen werden im Silver- oder Gold-Layer per DELETE/MERGE umgesetzt, idealerweise mit getrenntem Source-Tracking. Bronze sollte für Audit-Zwecke länger gehalten werden, aber mit klarer Retention-Policy.

Kann Autoloader Parquet- und Avro-Files ingestieren?

Ja — cloudFiles.format unterstützt JSON, CSV, Parquet, Avro, ORC, Text, BinaryFile. Parquet hat schon Schema, also ist Schema-Inferenz schneller.

Wie hoch ist der Latenz-Floor?

Mit File Notification: ~5–30 Sekunden je nach Cloud. Mit Directory Listing: so schnell wie dein trigger-Intervall (typisch 1–5 Minuten).

Sollte ich availableNow=True oder Continuous-Modus nutzen?

availableNow=True für Batch-artige Verarbeitung (nimm, was da ist, dann beende) — günstig für Stunden-/Tages-Cadence. Continuous für Sub-Minuten-Latenz, aber mit höheren Cluster-Kosten.

Was, wenn ein File mit der gleichen Bezeichnung erneut kommt?

Autoloader trackt verarbeitete Files per Path + Modification-Time im Checkpoint. Wenn ein File überschrieben wird (neue Modification-Time), wird es erneut ingestiert. Bei reinen Re-Reads ohne Modification-Time-Änderung wird übersprungen.

Key Takeaways

Autoloader ist eines der produktionsreifsten inkrementellen Ingestion-Tools im Databricks-Ökosystem. Drei Dinge von Anfang an richtig machen: immer einen schemaLocation setzen, rescue als Evolution-Modus für Bronze wählen und _rescued_data in Silver religiös monitoren. Der Rest ist Tuning.

Nächster Schritt: Autoloader mit Databricks Streaming Tables für eine voll deklarative End-to-End-Pipeline kombinieren.

Weiterlesen

• Delta Table Optimization Guide
• Databricks Asset Bundles
• Databricks Medallion Implementation

Stand: 14. Mai 2026.