Databricks Auto Loader: Dateien aus S3, ADLS und GCS sauber nach Bronze laden
Wie Databricks Auto Loader Cloud-Files inkrementell in Delta Bronze lädt – mit Schema Evolution, File Notifications und sauberem Backfill.
Die Kernaussagen auf einen Blick.
- Auto Loader lädt neue Dateien aus Cloud-Speichern inkrementell in die Bronze-Schicht. Als cloudFiles-Quelle merkt er sich, welche Dateien bereits verarbeitet wurden, und verhindert doppelte Verarbeitung.
- Neue Dateien erkennt Auto Loader auf zwei Arten: Directory Listing (einfach, listet das Verzeichnis) und File Notification (aufwändiger, reagiert auf Events). Die Unterschiede liegen bei Einrichtung, Latenz und laufenden Cloud-Kosten.
- Für Schemaänderungen gibt es vier Modi: addNewColumns, rescue, failOnNewColumns und none.
- Checkpoint und Schema-Location speichern, was schon verarbeitet wurde und welches Schema gilt.
- Empfehlenswert ist, Auto Loader als Standard für Cloud-Dateien zu nutzen: den Erkennungsmodus nach Dateimenge, Latenzanforderung und Betriebsaufwand wählen, die Rescue-Spalte standardmäßig aktivieren und Checkpoint- und Schema-Pfade fest in der Deployment-Konfiguration setzen.
Inhaltsverzeichnis
Drei Probleme, die jede Ingestion neu lösen muss
Eine selbst gebaute Ladepipeline für Bronze sieht am Anfang einfach aus: ein spark.read.format("json").load(path), dazu etwas eigene Logik, um bereits verarbeitete Dateien zu erkennen, und ein Job alle 15 Minuten. Doch sobald die Quelle ein neues Feld liefert, passt das Schema nicht mehr und die Pipeline bricht ab. Wächst die Dateizahl, dauert das Suchen neuer Dateien irgendwann länger als die eigentliche Verarbeitung. Und wird der Checkpoint-Pfad versehentlich gelöscht, kann der nächste Lauf die komplette Historie erneut laden.
Genau das passiert häufig, sobald Datei-Ingestion aus S3, ADLS oder GCS produktiv genutzt wird. Jede selbst gebaute Pipeline muss dieselben drei Fragen lösen: Welche Dateien sind seit dem letzten Lauf neu? Wie geht der Job mit Schema-Drift um, ohne zu stoppen? Wie verhindert er, dass Dateien nach Fehlern oder Neustarts doppelt verarbeitet werden? Das ist keine fachliche Logik, sondern wiederkehrende technische Infrastruktur, die sonst für jede Quelle neu gebaut und betrieben werden muss.
Auto Loader bringt dafür eine fertige Quelle für Structured Streaming mit. Damit geht es weniger ums Selbstbauen und mehr um die richtige Konfiguration: Discovery-Modus je nach Dateimenge, Schema-Strategie je Quelle, Trigger-Modus je nach Latenz, dazu ein fester Ort für den Zustand jeder Pipeline.
Was ist Databricks Auto Loader?
Auto Loader ist eine Quelle für Spark Structured Streaming und wird über cloudFiles verwendet. Praktisch bedeutet das: Eine Streaming-Abfrage liest Dateien aus einem Cloud-Pfad (s3://, abfss://, gs://). Auto Loader speichert, welche Dateien bereits verarbeitet wurden, und verarbeitet im nächsten Lauf nur neue Dateien. Microsoft Learn dokumentiert Auto Loader für Cloud-Speicher. Solange der Checkpoint erhalten bleibt, verarbeitet die Pipeline jede Datei genau einmal, auch nach Fehlern oder Neustarts.
Der Weg vom Cloud-Speicher bis zur Analyse läuft in wenigen klaren Stufen: Cloud Storage liefert neue Dateien, die Auto Loader über Directory Listing oder File Notification erkennt und deren Verarbeitungszustand er in RocksDB hält. Über Structured Streaming gelangen die Daten in die Bronze-Tabellen in Delta Lake, von dort über Silver nach Gold – bereit für Business Intelligence und Machine Learning.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
cloudFiles: Quellpfad, Schema-Location und Checkpoint
Eine Auto-Loader-Pipeline braucht drei dauerhaft stabile Pfade:
Quellpfad
S3-Präfix, ADLS-Container oder GCS-Bucket, in dem neue Dateien ankommen.
Schema-Location
Speichert die von Auto Loader erkannten Schemaversionen.
Checkpoint-Pfad
Speichert den Verarbeitungszustand des Streams – welche Dateien schon verarbeitet wurden.
Diese drei Pfade bilden zusammen den Zustand der Pipeline. Sie sollten über die gesamte Lebensdauer der Pipeline stabil bleiben. Wenn sie geändert oder gelöscht werden, kann sich die Pipeline beim Neustart anders verhalten als erwartet. Im Betrieb wird das oft übersehen. Die Folge sind doppelte Daten, Datenlücken oder unnötige Reloads.
Auto Loader ist damit eine zustandsbehaftete Streaming-Quelle. Gegenüber anderen Ladeverfahren hat das eigene Vor- und Nachteile:
COPY INTO
Gut für wiederholte Batch-Loads, hat aber keinen vergleichbaren Streaming-State.
Eigene Watermark-Logik
spark.read.format(...).load(path) mit eigener Logik: Zustand und Fehlerbehandlung müssen selbst gebaut werden.
Externe Tools (ADF, Glue)
Bringen eigenen Betrieb, eigenes Monitoring und eigene Governance außerhalb von Databricks mit.
Directory Listing oder File Notification: Welche Erkennung passt wann?
Auto Loader kann neue Dateien auf zwei Arten erkennen. Die Wahl beeinflusst Einrichtung, Latenz und laufende Cloud-Kosten. Databricks vergleicht beide Dateierkennungsmodi und hält fest: Der Modus lässt sich bei einem Stream-Neustart wechseln, ohne die Exactly-Once-Garantie zu verlieren.
Directory Listing. Auto Loader listet das Quellverzeichnis regelmäßig über die Cloud-Storage-API auf und vergleicht das Ergebnis mit dem gespeicherten Verarbeitungsstand. Die Einrichtung ist einfach: Dafür reicht zunächst der Quellpfad. Bei jedem Lauf fallen API-Aufrufe fürs Auflisten an, und je größer das Verzeichnis wird, desto länger dauert die Erkennung neuer Dateien. Bei kleineren Verzeichnissen fällt das kaum ins Gewicht. Bei mehreren Millionen Dateien kann das Auflisten spürbar Zeit und API-Kosten verursachen.
File Notification. Hier reagiert Auto Loader auf Ereignisse des Cloud-Speichers: Für neue Dateien wird eine Nachricht an einen Queue- oder Messaging-Dienst gesendet. Auf AWS laufen S3 Event Notifications meist auf eine SQS-Queue, auf Azure über Event Grid und eine Storage Queue, auf GCP über Pub/Sub. Die Einrichtung ist aufwändiger: IAM-Rollen, Queue-Policies und eine Notification-Konfiguration pro Quelle. Dafür muss das Verzeichnis nicht regelmäßig vollständig durchsucht werden, neue Dateien werden meist schneller erkannt, und die Kosten hängen vor allem an der Zahl der Events und Queue-Zugriffe.
| Achse | Directory Listing | File Notification |
|---|---|---|
| Einrichtungsaufwand | gering, ein Pfad reicht | IAM-Rolle, Queue, Notification-Regel pro Quelle |
| Skalierung | wächst mit der Verzeichnisgröße | wächst mit der Zahl neuer Dateien |
| Latenz | Minuten (Listing-Intervall) | Sekunden (ereignisbasierte Zustellung) |
| Cloud-API-Kosten | List-Calls auf das Verzeichnis | Notification-Events plus Queue-Polling |
| Betriebsaufwand in der Cloud | minimal | Notification-Regel, Queue-Tiefe, Dead-Letter-Handling |
| Empfehlung | Geeignet für kleine bis mittlere Dateibestände | Bei sehr großen Verzeichnissen oder niedrigen Latenzanforderungen sinnvoll prüfen |
Als Faustregel gilt: Directory Listing ist der einfachere Start. File Notification lohnt sich, wenn Listing zu langsam, zu teuer oder zu ungenau für die Latenzanforderung wird. Den Modus kannst du später wechseln, du musst dich also nicht zum Start endgültig festlegen. Die Einrichtung solltest du zentral standardisieren; danach läuft sie meist mit wenig Aufwand.
Wie funktioniert Schema Evolution im Auto Loader?
Beim ersten Lauf erkennt Auto Loader das Schema aus einer Stichprobe der Quelldateien und speichert es an der Schema-Location. Danach prüft Auto Loader bei neuen Dateien, ob sie zum bekannten Schema passen. Wie Auto Loader mit Abweichungen umgeht, legt der gewählte Schema-Evolution-Modus fest, den du pro Pipeline setzt:
| Modus | Was bei neuen Feldern passiert | Eignung |
|---|---|---|
| addNewColumns (Default für nicht-Avro-Formate) | Neue Spalten werden ergänzt und die Schemaänderung wird gespeichert, der Stream muss danach neu gestartet werden | Für Quellen mit erwarteten, kontrollierten Erweiterungen |
| rescue | Unbekannte Felder werden als JSON-String in _rescued_data gespeichert, der Stream läuft ohne Restart weiter | Für unplanbare oder häufig wechselnde Quellstrukturen, bei denen die Pipeline trotz unbekannter Felder weiterlaufen soll |
| failOnNewColumns | Der Stream stoppt, sobald ein neues Feld auftaucht | Für Quellen mit verbindlichem Schemavertrag |
| none | Schema-Drift wird ignoriert, neue Felder werden nicht in das bekannte Schema übernommen | Nur selten sinnvoll, meist eher für Tests |
Warum _rescued_data in Bronze wichtig ist
Die Rescue-Spalte hilft, Schemaabweichungen kontrolliert zu behandeln. Ist cloudFiles.rescuedDataColumn aktiv, schreibt Auto Loader jedes Feld, das nicht zum bekannten Schema passt oder nicht in den erwarteten Datentyp umgewandelt werden kann, als JSON in die Spalte _rescued_data. So bleibt der ursprüngliche Inhalt erhalten, der Job läuft weiter, und nachgelagerte Schritte können diese Werte prüfen, strukturieren oder verwerfen. Ohne Rescue-Spalte können falsch interpretierte oder unbekannte Inhalte verloren gehen.
Für produktive Pipelines ist sinnvoll: Die Rescue-Spalte standardmäßig aktivieren. Sie ergänzt Bronze um eine technische Spalte, die im Monitoring berücksichtigt werden sollte. So werden Schemaabweichungen sichtbar und auswertbar, statt nur die Pipeline zu stoppen. Den passenden Evolution-Modus wählst du trotzdem je nach Quelle: kontrollierte Erweiterung mit addNewColumns, unkontrollierten Drift mit rescue, strikten Vertrag mit failOnNewColumns.
Trigger.AvailableNow: Auto Loader als geplanten Batch-Job nutzen
Technisch läuft Auto Loader als Structured-Streaming-Abfrage. Ein laufender Cluster verarbeitet neue Dateien in Mikro-Batches, standardmäßig alle 500 Millisekunden. Für Bronze-Pipelines ohne echte Echtzeitanforderung ist ein dauerhaft laufender Cluster oft unnötig.
Trigger.AvailableNow
Verarbeitet alles seit dem letzten Lauf und beendet sich danach – der Standard für Bronze-Pipelines ohne Echtzeitanforderung.
Trigger.Once
Veraltet. Bestehende Pipelines sollten auf AvailableNow migrieren – die Umstellung ist meist klein.
Continuous Streaming
Nur nötig, wenn die Latenz unter einer Minute liegen muss, etwa bei Realtime-Dashboards oder ereignisgesteuerten Folgeprozessen.
Für viele periodische Bronze-Pipelines passt Trigger.AvailableNow besser. Die Abfrage verarbeitet alles, was seit dem letzten Lauf angekommen ist, und beendet sich danach. So verhält sich Auto Loader wie ein geplanter Batch-Job, viertelstündlich, stündlich oder täglich, je nach Quelle. Die Exactly-Once-Garantie bleibt erhalten, weil der Checkpoint den Stand zwischen den Läufen hält. Und Compute fällt nur während der tatsächlichen Verarbeitung an. Für Bronze ohne Echtzeitanforderung ist das häufig der beste Standard.
Trigger.Once sollte in neuen Pipelines nicht mehr verwendet werden. Läuft eine Pipeline noch damit, lohnt der Wechsel auf AvailableNow, und die Umstellung ist meist klein. Der Unterschied: AvailableNow hält sich an maxFilesPerTrigger und maxBytesPerTrigger und verarbeitet auch größere Rückstände in kontrollierten Schritten.
Kontinuierliches Streaming lohnt sich erst, wenn die Latenz unter einer Minute liegen muss: Realtime-Dashboards, ereignisgesteuerte Folgeprozesse oder Quellen, die sehr häufig neue Dateien ablegen. Dann muss der Cluster durchlaufen. Die Entscheidung sollte sich an fachlicher Latenzanforderung und Betriebskosten orientieren.
Checkpoint und Schema-Location schützen: Was bei Verlust schiefgeht
Checkpoint-Pfad und Schema-Location speichern den Zustand, den Auto Loader für Wiederanlauf und Schemaentwicklung benötigt. Wenn einer der beiden Pfade verloren geht, kann es zu erneuter Verarbeitung, ausgelassenen Dateien oder unerwarteten Schemaänderungen kommen:
Checkpoint verloren
Ohne Checkpoint fehlt der Stand der bereits verarbeiteten Dateien. Je nach cloudFiles.includeExistingFiles folgt ein vollständiger Reload oder ein Überspringen bestehender Dateien.
Schema-Location verloren
Auto Loader leitet das Schema neu aus den Quelldateien ab. Weicht die neue Stichprobe vom bisherigen Schema ab, drohen Restart oder unerwarteter Schema-Wechsel.
Beide Pfade verloren
Die Pipeline startet komplett neu – Schema und Verarbeitungsstand werden vollständig neu aufgebaut.
Daraus ergeben sich klare Betriebsregeln: Checkpoint-Pfad und Schema-Location gehören in dauerhaft verfügbare, gegen versehentliches Löschen geschützte Pfade und in jedes Wiederanlauf- und Restore-Verfahren. Temporäre oder persönliche Speicherorte sind dafür ungeeignet. In der Regel liegen sie auf einem Unity-Catalog-Volume oder einem eigenen Cloud-Storage-Container, der pro Pipeline klar zugeordnet und über Asset Bundles ausgerollt ist.
In den Pipeline-Spezifikationen, die wir bei Data Engineering auf Databricks bauen, sind diese beiden Pfade Pflicht-Parameter der Bundle-Konfiguration und nicht nur manuelle Notebook-Parameter. So lassen sich Schema-Versionen und State pro Umgebung eindeutig und reproduzierbar festlegen.
Backfill mit Auto Loader: Historische Dateien ohne doppelte Daten laden
Beim Aufbau einer neuen Bronze-Pipeline liegen im Quellpfad oft bereits historische Dateien, zum Beispiel Monate oder Jahre, die ebenfalls nach Bronze geladen werden müssen. Dafür sollte ein eigener Backfill-Prozess vorgesehen werden, mit cloudFiles.includeExistingFiles=true, getrennt vom laufenden inkrementellen Stream.
Backfill-Job anlegen
Eigener Job mit cloudFiles.includeExistingFiles=true und eigenem Checkpoint lädt alle historischen Dateien nach Bronze. Backfill und inkrementeller Stream können dasselbe Schema nutzen.
Inkrementellen Stream separat starten
Nach dem Backfill startet der inkrementelle Stream mit einem separaten Checkpoint-Pfad und includeExistingFiles=false. Beide schreiben in dasselbe Ziel, aber mit getrenntem Dateistand.
Checkpoints getrennt halten
Nutzen Backfill und laufende Verarbeitung denselben Checkpoint, drohen doppelte oder ausgelassene Dateien – besonders wenn includeExistingFiles während des Betriebs geändert wird.
Auto Loader in der Medallion Architecture: Rolle in Bronze, Silver und Gold
Auto Loader übernimmt meist die erste Stufe der Medallion-Architektur: das Laden der Bronze-Schicht. Dort landen Quelldaten möglichst unverändert, dazu technische Metadaten (Ingestion-Zeitstempel, Quellpfad, Dateiname) und die Rescue-Spalte. Fachliche Transformationen gehören nicht in Bronze. Die Silver-Schicht entsteht erst in nachgelagerten Verarbeitungsschritten: Typisierung, Dedup, Joins, Maskierung personenbezogener Felder. Gold liefert anschließend fachlich modellierte Daten für BI, APIs oder ML. Das ist die Medallion-Architektur im Lakehouse, das verbreitete Schichtenmodell für Lakehouse-Plattformen.
Bronze, Silver, Gold — drei Schichten mit steigender Qualität.
Auto Loader übernimmt die erste Stufe: das Laden der Bronze-Schicht. Silver und Gold entstehen erst in nachgelagerten Verarbeitungsschritten.
Die Silver-Transformation läuft in der Regel mit Spark SQL, Lakeflow oder einer anderen Pipeline-Engine, nicht mit Auto Loader selbst. Wie Auto Loader mit den Folge-Schichten zusammenspielt, zeigen wir im Überblick zu Lakeflow Declarative Pipelines und im Vergleich der Lade-Muster ETL gegen ELT. Für SaaS-Quellen, APIs oder CDC-Streams, die als API- oder Event-Strom ankommen, sind andere Verfahren besser geeignet, etwa Lakeflow Connect oder spezialisierte CDC-Connectoren.
Was Auto Loader nicht löst
Kein SaaS-/REST-API-Zugriff
Auto Loader ist für Dateien gebaut. Salesforce, HubSpot, NetSuite und andere SaaS-APIs liefern keine Dateien – dafür sind verwaltete Connectoren oder eigene API-Ingestion besser geeignet.
Kein CDC aus relationalen Datenbanken
Change Data Capture aus Postgres, Oracle oder MySQL gehört in Lakeflow Connect oder einen dedizierten CDC-Connector (etwa mit Debezium).
Event-Quellen ohne Dateien
Liefert die Quelle Ereignisse direkt über ein Messaging-System, tragen Zerobus oder eine direkte Kafka-/Event-Hubs-Integration besser.
File Notification nicht automatisch günstiger
Das Setup unterscheidet sich je Cloud (AWS, Azure, GCP), kleinere Quellen profitieren oft gar nicht – Entscheidung nach konkretem Volumen und Betriebsanforderungen.
Schema-Inference abhängig von der Stichprobe
Enthalten die zuerst gelesenen Dateien nur einen Teil der Felder, drohen Schema-Mismatches, sobald spätere Dateien weitere Felder mitbringen.
Keine fachliche Datenqualitätsprüfung
Dass Dateien inkrementell und zuverlässig in Bronze landen, sagt noch nichts über ihre fachliche Qualität. Prüfungen gehören in die nachgelagerten Stufen.
Diese Grenzen sprechen für eine bewusste Wahl je Quelle. Für Cloud-Dateien bleibt Auto Loader der Default; für API- und CDC-Quellen nimmst du besser dafür gebaute Verfahren.
Fazit
Der Einsatz von Auto Loader bietet sich an, wenn neue Dateien aus Cloud-Speichern nach Bronze geladen werden und Dateierkennung, Schemaänderungen und Wiederanlauf nicht selbst gebaut werden sollen.
Besonders relevant ist das für Plattformen mit S3-, ADLS- oder GCS-Dateiquellen, bei denen die Dateizahl stetig wächst, Schema-Drift vorkommt und eine reproduzierbare Bronze-Schicht die Grundlage für Silver und Gold ist.
Bei kleinen Quellen mit stabilem Schema und niedriger Frequenz reicht COPY INTO oder ein einfacher Batch-Job. Sobald Volumen, Schema-Drift oder Wiederverarbeitung wichtiger werden, zahlt sich ein zustandsbehafteter, verwalteter Ansatz aus.
Auto Loader als Standardpfad für Cloud-Dateien nutzen: den Erkennungsmodus je nach Volumen und Latenzanforderung wählen (Directory Listing als Einstieg, File Notification bei großen Dateimengen oder niedrigen Latenzanforderungen), die Rescue-Spalte standardmäßig aktivieren, Schema-Location und Checkpoint in stabile, versionierte Pfade legen und über Asset Bundles deployen. Historische Backfills laufen als eigener Prozess mit separatem Checkpoint.
FAQ
Auto Loader ist eine zustandsbehaftete Quelle in Spark Structured Streaming, registriert als cloudFiles. Er liest inkrementell neue Files aus einem Cloud-Speicherpfad (S3, ADLS, GCS), speichert im Checkpoint, welche Dateien bereits verarbeitet wurden, und garantiert Exactly-Once-Semantik über Stream-Neustarts. Die Schema-Location speichert das erkannte Schema. Beide Pfade gehören zusammen und müssen über die Lebenszeit der Pipeline stabil bleiben.
