Zerobus Ingest: Direkt-Ingest in Delta Lake erklärt

Zerobus Ingest ist ein 2025 von Databricks vorgestellter Direkt-Aufnahmepfad, bei dem Anwendungen ihre Ereignisse (einzelne Datensätze wie Sensor-Messwerte oder Klicks) über eine schnelle Netzwerk-Verbindung (gRPC, ein Google-Protokoll für Programm-zu-Programm-Kommunikation) direkt in Delta-Tabellen (die Standard-Tabellenform in Databricks) schreiben, ohne einen zwischengeschalteten Verteiler-Dienst wie Apache Kafka oder Amazon Kinesis. Der Dienst gehört zur Lakeflow-Connect-Familie (Databricks-Sammelname für Ingest-Werkzeuge), wird vollständig von Databricks verwaltet und ist seit 2026 auf AWS und Microsoft Azure allgemein verfügbar.

Was ist Zerobus Ingest?

Zerobus Ingest ist der Weg, mit dem eine Anwendung ihre Daten aktiv nach Databricks schickt, im Gegensatz zu Verfahren, bei denen Databricks Dateien oder Datenbanken abholt. Die sendende Anwendung bindet dazu eine kleine Programm-Bibliothek (SDK, Software Development Kit) von Databricks ein, öffnet eine dauerhafte Netzwerk-Verbindung zu einem Databricks-Endpunkt und schreibt die Datensätze unmittelbar in eine zuvor angelegte Ziel-Tabelle im Databricks-Datenkatalog (Unity Catalog, die zentrale Rechte- und Metadaten-Verwaltung von Databricks). Der namensgebende Punkt „zero bus" beschreibt genau diese Eigenschaft: Zwischen der sendenden Anwendung und der Ziel-Tabelle steht kein zusätzlicher Verteiler-Dienst.

Databricks führte Zerobus Ingest 2025 auf dem Data + AI Summit ein und stellte den Dienst 2026 general available. Zerobus ist Teil von Lakeflow Connect und tritt dort neben zwei andere Ingest-Klassen: Managed Connectors für SaaS- und Datenbankquellen (Salesforce, Workday, Postgres-CDC) sowie Auto Loader für file-basiertes Streaming aus Object Storage. Zerobus deckt den Fall aktiver Anwendungen ab, die ihre Events selbst pushen und dafür keinen eigenen Streaming-Broker aufbauen wollen.

Die Architektur besteht aus drei Bausteinen. Erstens: ein [Zerobus-SDK](https://github.com/databricks/zerobus-sdk) in der Producer-Anwendung. GA-verfügbar sind SDKs für Python, Java, Rust, Go und TypeScript. Das SDK öffnet den gRPC-Stream, serialisiert Datensätze (Protocol Buffers als Default, JSON für dynamische Schemata, Arrow Flight als Beta-Option für spaltenorientierte Batches) und liest Server-Acknowledgements zurück. Zweitens: ein von Databricks verwalteter Workspace-Endpoint, der Datensätze annimmt, das Schema gegen die Zieltabelle prüft und Acknowledgements zurückschickt. Neben gRPC bietet der Endpoint eine REST-Schnittstelle (Beta) für Webhook-Quellen und Serverless-Funktionen sowie eine OpenTelemetry-OTLP-Schnittstelle (Beta) für Logs, Metriken und Traces. Drittens: eine Delta-Tabelle in Unity Catalog als Ziel, mit festem Schema, regulärer UC-Governance, Lineage und Zugriffsrechten.

Zwei technische Eigenschaften sind für den produktiven Einsatz zentral. Zerobus liefert at-least-once mit Server-Acknowledgements; Producer-Sequenznummern sorgen für Idempotenz innerhalb einer Verbindung, für Doubletten über mehrere Producer-Instanzen hinweg braucht es weiterhin eine fachliche Ereignis-ID. Das Schema ist durch die Delta-Zieltabelle vorgegeben. Datensätze, die nicht dazu passen, werden am Endpoint zurückgewiesen; Schema-Evolution passiert an der Tabelle, eine separate Schema Registry entfällt. Bei koordinierten Breaking Changes am Zielschema sichert Zerobus bereits akzeptierte Records unter _zerobus/table_rejected_parquets/ innerhalb der Storage-Grenze der Tabelle.

Die Skalierung folgt einem anderen Modell als bei brokerbasierten Systemen: statt Partitionen und Consumer-Groups skaliert Zerobus horizontal über die Anzahl paralleler Verbindungen. Databricks dokumentiert bis zu 100 MB/s pro Verbindung, aggregiert über 10 GB/s in eine einzelne Zieltabelle, bei einer Sichtbarkeits-Latenz von unter fünf Sekunden.

Abgrenzung zu Kafka, Auto Loader, Delta Sharing und Lakeflow Connect

Zerobus Ingest wird häufig mit anderen Ingestion- und Streaming-Bausteinen im Databricks-Umfeld vermengt. Die Trennlinien laufen entlang der Frage, was Quelle, was Transport und was Ziel ist.

Begriff	Verhältnis zu Zerobus Ingest
Kafka-basierte Ingestion	Kafka ist eine verteilte Event-Plattform mit Broker, Topics, Partitionen und Consumer-Groups; Fan-out an unabhängige Konsumenten und Replay über Topic-Retention gehören zum Kernmodell. Zerobus hat keinen Broker: Fan-out passiert auf Delta-Ebene, Replay über Delta Time Travel innerhalb der Aufbewahrungsfrist.
Auto Loader	File-basierter Streaming-Pfad, der neu abgelegte Dateien aus Object Storage inkrementell aufnimmt. Zerobus ist ein aktiver Push-Pfad ohne Zwischen-Files. Auto Loader bleibt der Weg für SaaS-Exporte, Batch-Drops und Partner-Übergaben.
Delta Sharing	Offenes Sharing-Protokoll, das bestehende Delta-Tabellen für externe Konsumenten liest. Delta Sharing ist Konsum, nicht Ingest; Zerobus schreibt neue Datensätze in eine Tabelle.
Lakeflow Connect (Managed Connectors)	Verwaltete Batch-/CDC-Konnektoren für SaaS-Anwendungen und Datenbanken. Zerobus deckt den anderen Quelltyp ab: aktive Anwendungen, die Events selbst senden. Beide Pfade gehören zur gleichen Lakeflow-Connect-Familie.
Structured Streaming	Verarbeitungsschicht auf Basis von Apache Spark, die Streams als wachsende Tabelle behandelt. Zerobus schreibt in Bronze, Structured Streaming (oder Lakeflow Declarative Pipelines) transformiert nach Silver und Gold. Zerobus nimmt auf, Structured Streaming verarbeitet.

Der wichtigste Unterschied zu Kafka ist der Architektur-Zuschnitt: Kafka ist die zentrale Event-Plattform für viele unabhängige Konsumenten und Zielsysteme, offener Standard, hersteller- und cloud-übergreifend. Zerobus ist auf ein zentrales Ziel ausgerichtet, die Delta-Tabelle in Databricks, und dementsprechend Databricks-spezifisch. Für Multi-Cloud- und Multi-Konsumenten-Topologien bleibt Kafka die passende Basis. Für Event-Streams mit dem Lakehouse als einzigem Ziel entfällt der Broker-Betrieb.

Gegenüber Auto Loader liegt der Unterschied im Quelltyp. Auto Loader wartet auf Dateien im Cloud Storage und ist damit passiv; Zerobus nimmt aktiv gepushte Events entgegen. Beide Pfade lassen sich kombinieren: Zerobus für den Live-Stream, Auto Loader als Fail-Safe für Backfill aus lokal gepufferten Dateien, wenn ein Producer temporär ausfällt.

Beispiel: IoT-Telemetrie in eine Delta-Tabelle

Ein Fertigungsunternehmen betreibt 50.000 Sensoren, die jeweils ein Ereignis pro Sekunde senden. Die Betriebs-Leitstelle soll die Daten in einem Dashboard mit weniger als einer Minute Verzögerung sehen; die zentrale Datenplattform ist Databricks.

In der Zerobus-Variante bindet der Sensor-Backend-Dienst das Python-SDK ein, öffnet einen gRPC-Stream zum Workspace-Endpoint und schreibt die Messwerte in die Bronze-Tabelle sensors.raw_events (Spalten: device_id, event_time, metric, value). Nach MODIFY-Berechtigung des Service Principals auf der Tabelle greift der übliche Databricks-Auth-Stack (OAuth-Token oder Service Principal), Private Link deckt die Netzwerk-Isolation ab. Ein Structured-Streaming-Job liest die Bronze-Tabelle als Streaming-Quelle, aggregiert pro Minute und Gerätegruppe nach sensors.metrics_1m in Silver, und der Genie-Space der Leitstelle liest die Silber-Aggregation. Aus der Architekturkette entfallen ein separater MQTT-Broker, eine Confluent-Cloud-Instanz und der zugehörige Consumer-Job. Bleibende Komponenten sind die Sensor-Anwendung, der Zerobus-Endpoint und die Delta-Tabelle.

Typischer Einsatz sind entsprechend Event-Streams mit Databricks als zentraler Senke: IoT- und Fahrzeug-Telemetrie, Klickströme aus Web- und Mobile-Anwendungen, Anwendungs-Logs und -Metriken für Observability sowie Backend-Ereignisse aus SaaS-Komponenten. Für plattformübergreifende Fan-out-Topologien oder langfristige Wiederverarbeitung anhand unabhängiger Consumer-Offsets bleibt eine broker-basierte Plattform die geeignete Wahl.