Zerobus Ingest auf Databricks: Events direkt in Delta, ohne Broker dazwischen
Die Kernaussagen auf einen Blick.
- Zerobus Ingest schickt Events direkt nach Databricks: Producer-SDKs (Python, Java, Rust, Go, TypeScript) öffnen einen gRPC-Stream zum Workspace und schreiben die Datensätze direkt in eine Delta-Tabelle im Unity Catalog. Ein Broker wie Kafka oder Kinesis ist dafür nicht nötig.
- Anders als bei Kafka gibt es keine Broker, Topics oder Consumer-Groups. Mehrere Leser greifen direkt auf die Delta-Tabelle zu, ältere Daten lassen sich innerhalb der Aufbewahrungsfrist erneut verarbeiten.
- Vor der Entscheidung sind drei Fragen wichtig: Liest nur ein System mit oder mehrere? Reicht at-least-once mit Idempotenz oder braucht ihr echtes Replay? Und wer hält die SDKs in den sendenden Anwendungen aktuell?
- Mein Vorschlag: Zerobus prüfen, wenn Databricks die zentrale Senke der Event-Streams ist. Kafka oder Kinesis bleiben sinnvoll bei vielen unabhängigen Konsumenten, komplexer Stream-Verarbeitung oder langer Aufbewahrung im Broker.
Inhaltsverzeichnis
Nicht jede Event-Quelle braucht Kafka
Eine IoT-Flotte umfasst 50.000 Sensoren, die jeweils ein Ereignis pro Sekunde senden. Die Betriebsleitstelle soll die Daten innerhalb weniger als einer Minute in einem Genie Space auswerten können. Die Frage im Architektur-Review: Kann Zerobus die Daten ohne zusätzlichen Streaming-Broker direkt nach Databricks übertragen? Die bisherige Architektur umfasst mehrere aufeinanderfolgende Komponenten: MQTT-Broker am Edge, Confluent Cloud im Cloud-Account, Structured-Streaming-Job auf Databricks, Delta-Tabelle in Unity Catalog. Für eine einzelne Quelle entstehen damit drei technische Übergänge, mehrere Betriebsverantwortungen und getrennte Kostenpositionen.
Eine ähnliche Diskussion entsteht bei jeder neuen Event-Quelle. Anwendungstelemetrie für ein Mobile-Produkt, Click-Stream einer Web-App, Logs einer SaaS-Komponente. Jedes Mal stellt sich dieselbe Frage: Wie lassen sich die Events zuverlässig in das Lakehouse übertragen, ohne dass dafür ein eigener Pub/Sub-Stack aufgebaut werden muss? Häufig wird dabei erneut dieselbe Standardarchitektur gewählt: Kafka als Broker, Structured Streaming als Consumer, Delta als Senke.
Die Fragen aus den Architektur-Reviews bleiben gleich:
Welchen zusätzlichen Nutzen bietet ein Broker bei nur einer sendenden Quelle und einem zentralen Ziel? Warum laufen die Auto-Loader-File-Drops auf 15-Minuten-Mikro-Batches, wenn die Leitstelle Sub-Minuten-Aktualität sehen will? Rechtfertigen wenige Datenströme den Betrieb und die Lizenzierung einer vollständigen Confluent-Plattform? Warum gibt es zwischen Producer und Delta-Tabelle vier Komponenten, die alle getrennt überwacht werden müssen?
Zerobus Ingest adressiert diesen Anwendungsfall mit einem direkten Schreibpfad. Statt eines Brokers in der Mitte schreibt der Producer per gRPC direkt in eine Delta-Tabelle. Die technische Strecke reduziert sich auf die sendende Anwendung und die Delta-Zieltabelle. Dadurch verschiebt sich die Architekturentscheidung. Entscheidend ist nicht das einzelne Werkzeug, sondern die benötigte Konsumenten- und Verarbeitungsstruktur.
Was ist Zerobus Ingest auf Databricks?
Zerobus Ingest ist ein push-basierter Ingest-Pfad in Databricks. Die sendende Anwendung baut eine gRPC-Verbindung zu einem Databricks-Endpunkt auf und schreibt ihre Events direkt in eine vorgegebene Delta-Tabelle. Databricks beschreibt Zerobus Ingest als push-based Ingestion-API, die direkt in Unity-Catalog-Delta-Tabellen schreibt. Der Dienst gehört zu Lakeflow Connect und wird von Databricks verwaltet.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Ein Ingestion-Endpoint für die gesamte Plattform.
Quellen senden Events über gRPC oder REST an Zerobus. Der Service landet sie direkt in der Data Intelligence Platform, governed durch Unity Catalog, gespeichert in offenen Formaten.
Delta Lake
Parquet
IcebergDrei typische Broker-Bausteine fallen damit weg: Broker, Topics und Consumer-Groups. Stattdessen ist die Delta-Tabelle der gemeinsame Ausgangspunkt. Mehrere Leser greifen direkt darauf zu, als Streaming-Quelle, als SQL-Query oder als ML-Feature-Lookup. Ältere Tabellenstände lassen sich innerhalb des konfigurierten Time-Travel-Fensters erneut lesen.
Auch die Skalierung funktioniert anders als bei Kafka. Kafka skaliert über Partitionen und Consumer-Groups. Zerobus skaliert über zusätzliche parallele Verbindungen, ohne dass Partitionen konfiguriert werden müssen. Ein Endpoint nimmt Tausende paralleler Streams an und schreibt sie in dieselbe oder in verschiedene Zieltabellen.
Die Reihenfolge ist ebenfalls anders geregelt. Bei Kafka hängt sie an der Partition, und wer die Partitionierung ändert, betrifft damit auch die nachgelagerten Konsumenten. Bei Zerobus gilt die Reihenfolge je gRPC-Verbindung. Den Rest übernimmt der verwaltete Dienst: Er verteilt eingehende Verbindungen je nach Last, skaliert hoch und runter und beendet bestehende Verbindungen vor dem Herunterskalieren geordnet. Um die Skalierung des Ingest-Dienstes muss man sich damit kaum kümmern.
Daraus ergibt sich ein anderer Architektur-Zuschnitt. Kafka ist die zentrale Event-Plattform für viele unabhängige Konsumenten und Ziele. Zerobus ist auf ein zentrales Ziel ausgerichtet: die Delta-Tabelle in Databricks. Was man für das Fan-out an viele Ziele braucht (Broker-Cluster, Topic-Partitionen, Consumer-Groups, Schema-Registry), entfällt deshalb.
Zerobus gehört zur Lakeflow-Connect-Familie, deckt aber einen anderen Quelltyp ab als die Managed Connectors für SaaS- und CDC-Quellen. Lakeflow Connect bringt verwaltete Konnektoren für SaaS-Anwendungen und Datenbanken wie Salesforce, Workday oder Postgres-CDC. Auto Loader deckt File-Drops aus dem Object Storage ab. Zerobus ist der Pfad für Anwendungen und Dienste, die ihre Events selbst aktiv an Databricks senden und für die sich der Betrieb einer eigenen Broker-Plattform nicht lohnt.
Wie Auto Loader, Lakeflow Connect und Zerobus als drei Lade-Pfade in einem gemeinsamen Betriebsmodell zusammenspielen, zeigen wir im Überblick zur Datenaufnahme auf Databricks. Welche Bausteine die Engineering-Plattform insgesamt ausmachen und wie sie sich orchestrieren lassen, klären wir im Überblick zu Data Engineering auf Databricks.
Producer-SDK, gRPC-Endpoint und Delta-Tabelle
Eine typische produktive Architektur besteht aus drei Komponenten.
Producer-SDK in der Anwendung. Das SDK ist eine Bibliothek, die in die sendende Anwendung eingebunden wird, etwa einen Telemetriedienst, eine Mobile-App, ein IoT-Gateway oder einen Backend-Worker. Die Zerobus-SDKs gibt es für Rust, Python, Java, Go und TypeScript, alle allgemein verfügbar. Das SDK öffnet einen gRPC-Stream zum Workspace-Endpoint, sendet die Datensätze im vorgegebenen Schema und liest die Acknowledgements des Servers zurück. Der Code dafür bleibt bei einfachen Fällen schlank: Verbindung öffnen, Datensätze senden, Rückmeldungen verarbeiten.
Für die Serialisierung gibt es zwei etablierte Formate und eine Beta-Option. JSON passt zum schnellen Einstieg und zu sich schnell ändernden Strukturen: dynamisch typisiert, ohne vorab erzeugte Typdefinition, ideal für Prototypen. Protocol Buffers (proto2) sind im produktiven Betrieb meist die robustere Wahl: typsicher gegen das UC-Schema validiert und mit weniger Übertragungsvolumen. Jedes SDK bringt ein Tool mit, das die .proto-Definition direkt aus der bestehenden UC-Tabelle erzeugt. Arrow Flight (Beta) ist die dritte Option für spaltenorientierte oder in Batches übertragene Daten.
Drei Push-Schnittstellen für unterschiedliche Anwendungstypen. gRPC ist der Pfad für dauerhafte Verbindungen mit hohem Durchsatz. REST (Beta) deckt Webhook-Quellen und Serverless-Functions ab, für die eine dauerhafte gRPC-Verbindung zu aufwendig wäre. OpenTelemetry-OTLP (Beta) pusht Logs, Metrics und Traces aus Anwendungen mit bestehender OpenTelemetry-Instrumentierung direkt ins Lakehouse, vor allem relevant für Telemetrie aus KI-Anwendungen und Observability. Während der Beta ist die OTLP-Ingestion nicht abrechnungsrelevant.
Workspace-Endpoint. Pro Databricks-Workspace gibt es einen Zerobus-Endpoint. Er nimmt die Datensätze entgegen, prüft das Schema gegen die Ziel-Tabelle, schreibt in die Delta-Tabelle und schickt Acknowledgements zurück. Die Authentifizierung läuft über die üblichen Databricks-Mechanismen: OAuth-Tokens, Personal Access Tokens oder Service Principals. Für Netzwerk-Isolation steht Private Link bereit.
Delta-Senke in Unity Catalog. Die Ziel-Tabelle wird vorab in Unity Catalog mit festem Schema angelegt. Nach dem Schreiben ist sie eine ganz normale, über Unity Catalog verwaltete Delta-Tabelle: governed, lineage-fähig, per SQL abfragbar und als Streaming-Quelle lesbar. Berechtigungen, Tagging und Row-/Column-Level-Security funktionieren wie bei jeder anderen Unity-Catalog-Tabelle. Eine separate Governance-Plattform braucht der Ingest-Pfad nicht.
Im Lakehouse landet die Zerobus-Tabelle meist in der Bronze-Schicht der Medallion-Architektur. Von dort übernimmt Structured Streaming oder Lakeflow Declarative Pipelines die Transformation nach Silver und Gold. Zerobus macht nur die Aufnahme, die Transformation passiert nachgelagert. Diese Trennung gehört bewusst in die Architekturplanung.
Gegenüber einer klassischen Kafka-Pipeline entfallen Broker-Cluster, Topic-Konfiguration, Connect-Worker und die separate Schema-Registry. Bleiben müssen nur das Zielschema in Unity Catalog, der Zerobus-Endpoint und das eingebundene SDK in der sendenden Anwendung.
Welche Zerobus-Ingest-Variante passt wann?
Die Wahl zwischen den Schnittstellen (gRPC, REST, OTLP) und den Serialisierungsformaten (Protocol Buffers, JSON, Arrow Flight) sollte anhand des konkreten Anwendungsfalls getroffen werden. Entscheidend sind insbesondere die Stabilität des Schemas, die erwartete Latenz, die Betriebsumgebung der sendenden Anwendung und das Volumen pro Verbindung.
gRPC mit Protocol Buffers. Geeignet als Standard für stabile, hochvolumige Streams. Der Producer hält eine persistente Verbindung, das Schema ist typisiert gegen die Unity-Catalog-Tabelle validiert, das Übertragungsvolumen ist gering. Diese Variante eignet sich für IoT-Telemetrie, Click-Streams, Anwendungsereignisse und alle Quellen, bei denen das Zielschema bekannt und über längere Zeit stabil ist.
gRPC mit JSON. Geeignet für Prototypen, kleinere Anwendungen und Quellen, bei denen die zusätzliche Codegenerierung für Protocol Buffers den Aufwand nicht rechtfertigt. Die Serialisierung bleibt dynamisch typisiert, das Schema wird weiterhin am Endpoint gegen die Zieltabelle validiert. Für stabile Produktivworkloads ist Protocol Buffers in der Regel die robustere Wahl.
gRPC mit JSON in eine VARIANT-Spalte. Geeignet für Quellen mit häufig wechselnden oder nicht vollständig bekannten Feldern. Die Zieltabelle enthält eine VARIANT-Spalte für die Payload sowie wenige feste technische Spalten (Ereignis-ID, Zeitstempel, Quelltyp). Die strukturelle Auflösung erfolgt anschließend in Silver über variant_get() und try_cast(). Dadurch werden Datensätze mit abweichendem Schema nicht am Endpoint zurückgewiesen, sondern in Bronze aufgenommen und nachgelagert behandelt. Geeignet für SaaS-Telemetrie, Drittanbieter-Webhooks oder Quellen, deren Schema außerhalb der eigenen Kontrolle liegt. Der Preis dieser Flexibilität liegt in einer höheren Verantwortung der Silver-Schicht für Validierung, Typisierung und Qualitätsregeln.
REST (Beta). Geeignet für Webhook-Quellen, Serverless-Functions (AWS Lambda, Azure Functions, Cloud Functions) und Anwendungen, in denen sich eine dauerhafte gRPC-Verbindung nicht sinnvoll betreiben lässt. Die Latenz und der Durchsatz pro Anfrage liegen unter den gRPC-Werten. Sinnvoll vor allem für niedrigvolumige oder ereignisgesteuerte Quellen.
OpenTelemetry-OTLP (Beta). Geeignet für Anwendungen mit bestehender OpenTelemetry-Instrumentierung. Logs, Metriken und Traces können ohne Anpassung des Anwendungscodes in das Lakehouse übertragen werden. Besonders relevant für AI- und Observability-Szenarien, in denen die Telemetrie bereits über OTel-Exporter abgegriffen wird.
Arrow Flight (Beta). Geeignet für spaltenorientierte oder in Batches übertragene Daten, etwa wenn analytische Producer ohnehin Arrow-Records erzeugen. Für klassische ereignisorientierte Producer bleibt gRPC mit Protocol Buffers die einfachere Variante.
Als erste Orientierung gilt: Stabiles Schema und hoher Durchsatz sprechen für gRPC mit Protocol Buffers. Häufige Schemaänderungen oder nicht vollständig kontrollierbare Quellen sprechen für JSON in einer VARIANT-Spalte mit nachgelagerter Auflösung. Anwendungen ohne persistente Verbindung nutzen REST, bestehende OTel-Pipelines OTLP. Die Wahl der Variante sollte gemeinsam mit der Definition der Bronze-Tabelle erfolgen, da Schema, Serialisierung und Fehlerverhalten zusammenhängen.
Delivery, Idempotenz und Schema-Vorgabe bei Zerobus
Für einen zuverlässigen Betrieb sind drei technische Eigenschaften besonders relevant: Delivery, Idempotenz und Schema.
Delivery: at-least-once mit Server-Acks. Zerobus liefert at-least-once. Die Anwendung sendet Datensätze und erhält für erfolgreich angenommene Daten eine Bestätigung. Bleibt die Bestätigung aus, muss die Übertragung wiederholt werden. Das Modell ist mit anderen at-least-once-basierten Streaming-Architekturen vergleichbar. Die Transportebene garantiert keine grundsätzlich genau einmalige Verarbeitung. Wenn doppelte Datensätze in Bronze nicht akzeptabel sind, braucht es eine zusätzliche Deduplizierungslogik anhand stabiler Ereignis-IDs oder Sequenznummern.
Idempotenz: Producer-Sequenznummern. Um Wiederholungen innerhalb einer Verbindung kontrolliert behandeln zu können, schickt das SDK Sequenznummern pro Producer-Stream. Der Endpoint dedupliziert wiederholte Records innerhalb eines Streams. Doppelte Ereignisse über mehrere Verbindungen oder Anwendungsinstanzen hinweg müssen weiterhin über eine fachliche Ereignis-ID erkannt werden. Auf Tabellen-Ebene unterstützt Delta Lake den Change Data Feed mit nachvollziehbaren Änderungen pro Commit. Das ist eine mögliche Grundlage für nachgelagerte Deduplizierungs- oder Audit-Logik.
Schema vom Delta-Ziel vorgegeben. Das Schema wird durch die Delta-Zieltabelle vorgegeben. Der Producer schreibt schema-konform. Datensätze, die nicht dem erwarteten Schema entsprechen, werden am Endpoint zurückgewiesen. Das ist ein deutlicher Unterschied zu Kafka, wo Schema-Registry und Compatibility-Modi ein eigenes Konzept sind. Bei Zerobus liegt das Tabellenschema in Unity Catalog; separate Schema-Registry-Regeln sind nicht erforderlich. Schema-Evolution erfolgt an der Delta-Tabelle. Abweichungen zwischen Producer und Zielschema führen unmittelbar zu Fehlern bei der Übertragung.
Fallback für bereits angenommene Daten bei inkompatiblen Schemaänderungen. Wenn ein Breaking Change am Zielschema passiert, nachdem Zerobus die Daten bereits dauerhaft angenommen hat, aber bevor sie materialisiert wurden, schreibt der Connector die Records als Parquet-Dateien in das Storage-Verzeichnis der Tabelle, unter dem Pfad _zerobus/table_rejected_parquets/. Die Daten bleiben innerhalb der Storage-Grenze und unterliegen denselben Access-Controls wie die Tabelle selbst. Dadurch bleiben bereits angenommene Datensätze trotz einer zwischenzeitlichen Schemaänderung erhalten: Schutz vor Datenverlust während koordinierter Schemaänderungen.
Diese Beschreibung entspricht dem dokumentierten Funktionsstand zum Zeitpunkt der Veröffentlichung. Die Mechanik entwickelt sich seit der GA-Ankündigung. Vor jedem produktiven Setup gegen die aktuelle Connector-Doku prüfen, ob sich Details zu Sequenznummern, Deduplizierung und Schemaänderungen geändert haben.
Was leistet der direkte Schreibpfad?
Die zentrale Engineering-Frage in jedem Architektur-Review: Kann der Endpunkt das erwartete Datenvolumen dauerhaft verarbeiten? Databricks dokumentiert für Zerobus Ingest Datenaufnahme unter fünf Sekunden bei 100 MB/s pro Verbindung, aggregiert über 10 GB/s in eine einzelne Tabelle, mit Unterstützung für Tausende paralleler Clients.
Wie sich das unter Dauerlast verhält, hat Databricks in einem 24-Stunden-Lasttest gegen das NEOWISE-Dataset der NASA gemessen: 2.048 parallele Streams, 11,8 GB/s sustained über die volle Test-Dauer, in Summe 1,04 Billionen Records, im Schnitt 12 Millionen Rows pro Sekunde. Damit sind die dokumentierten Throughput-Zahlen über einen 24-Stunden-Test und nicht nur als kurzfristige Spitzenlast gemessen.
Für die Kapazitätsplanung ergibt sich daraus ein anderes Skalierungsmodell. Skaliert wird über die Anzahl der parallelen Verbindungen. Endpoint-Sharding und Broker-Partitionierung müssen nicht durch das Plattformteam konfiguriert werden. Für zusätzlichen Durchsatz werden weitere parallele Verbindungen aufgebaut. Der Endpoint nimmt sie an, ohne dass Broker-Tuning, Partition-Rebalancing oder Cluster-Skalierung anfallen. Bei 1-KB-Events bedeuten 10 GB pro Sekunde rund 10 Millionen Events pro Sekunde in eine Tabelle, was für viele Telemetrie-, Clickstream- und IoT-Anwendungsfälle ausreichend ist. Die IoT-Geräteflotte aus dem Einstieg mit 50.000 Sensoren à ein Event pro Sekunde liegt deutlich unter den veröffentlichten Lasttestwerten.
Neben dem Durchsatz ist die Zeit bis zur Sichtbarkeit der Daten entscheidend. Die Sichtbarkeits-Latenz liegt bei rund fünf Sekunden. Für Reaktionen innerhalb von Millisekunden oder wenigen hundert Millisekunden auf einzelne Events (Trading-Systeme, Echtzeit-Steuerung) bleiben spezialisierte Stream-Processing-Stacks die richtige Wahl. Für Sub-Minuten-Aktualität in Dashboards, Genie-Spaces oder ML-Features, was viele analytische Echtzeit-Anwendungsfälle abdeckt, reicht Zerobus ohne Streaming-Job dazwischen.
Die sendende Anwendung muss mit verzögerter Annahme und temporärer Nichtverfügbarkeit umgehen. Wenn der Endpoint langsamer wird oder kurzzeitig nicht erreichbar ist, blockt das SDK den Sende-Aufruf oder puffert lokal, je nach Konfiguration. Der Producer-Code muss damit umgehen. Die Anwendung darf den Sendevorgang nicht als garantiert erfolgreiche, asynchrone Übergabe behandeln. Das ist eine übliche Anforderung an zuverlässige Streaming-Producer und kein Zerobus-Spezifikum.
Stand-Hinweis: Throughput-Limits, Latenz-Profile und Endpoint-Skalierung haben sich seit der GA-Ankündigung mehrfach verändert. Konkrete Zahlen vor dem Produktiv-Setup gegen die aktuelle Doku prüfen.
Welcher Ingestion-Pfad passt wann?
Der Vergleich Zerobus gegen Kafka ist nicht „ein direkter Databricks-Dienst ersetzt grundsätzlich Kafka". Beide Ansätze erfüllen unterschiedliche Aufgaben innerhalb einer Streaming-Architektur.
| Aspekt | Zerobus Ingest | Kafka (Confluent / Self-Managed) | Auto Loader |
|---|---|---|---|
| Architektur-Schnitt | Producer → gRPC → Delta-Tabelle | Producer → Broker → Topic → Consumer → Sink | File-Drop → Object Storage → Auto Loader → Delta |
| Broker | nein | ja, zentrales Rückgrat | nein |
| Topics / Consumer-Groups | nein, Konsum über Delta | ja, mehrere unabhängige Konsumenten mit eigener Offset-Verwaltung | nein, Datei-Listing |
| Replay-Mechanismus | Delta Time Travel | Topic-Retention, Re-Konsum | Cloud-Storage-Versionierung |
| Stream-Joins über Streams | nein, Joins in Silver/Gold | ja, Stream-Processing über Topics | nein |
| Latenz Sichtbarkeit | Sekunden | Sekunden | Minuten (Trigger-abhängig) |
| Delivery-Profil | at-least-once, Sequenz-Idempotenz | at-least-once / exactly-once möglich | at-least-once |
| Throughput-Profil | 100 MB/s pro Verbindung, >10 GB/s pro Tabelle aggregiert | horizontal über Broker und Partitionen skalierbar | abhängig von File-Frequenz |
| Governance ab Schreibpunkt | Unity Catalog | extern (Schema Registry, ACLs) | Unity Catalog |
| Betriebskomponenten | SDK + Endpoint | Broker-Cluster, Connect, Registry, Consumer | Storage-Bucket + Stream |
| Plattformbindung | stark an Databricks gekoppelt | gering (offener Standard) | gering (Cloud-Storage) |
Apache Kafka ist als verteilte Ereignisplattform für Speicherung, Verteilung und unabhängigen Konsum von Streams ausgelegt: mit Topics, Partitionen und Consumer-Groups. Diese Funktionen gehören bewusst nicht zum engeren Einsatzbereich von Zerobus. Die Zerobus-SDK-Übersicht auf GitHub beschreibt das System als „high-throughput streaming service for direct data ingestion into Databricks Delta tables, optimized for real-time" und macht den Architektur-Schnitt explizit.
Zusätzlich sollte die Plattformabhängigkeit berücksichtigt werden. Kafka ist offener Standard, läuft on-prem, in jeder Cloud, mit jedem Consumer. Zerobus ist Databricks-spezifisch. Für eine zentrale Ereignisplattform für mehrere Zielsysteme und Clouds (gleicher Stream landet in Databricks, in einem SAP-System und in einer Drittanbieter-Plattform) bleibt Kafka die richtige Wahl. Wenn Databricks beziehungsweise das Lakehouse das zentrale Ziel ist, spart Zerobus Broker-Betrieb und Hops.
Wann Zerobus, wann Kafka oder Auto Loader?
Entscheidend ist vor allem, wie viele unabhängige Konsumenten denselben Stream benötigen. Die reine Latenz ist dabei nur eines von mehreren Kriterien.
Passt: Single-Consumer-Event-Streams. Eine Anwendung sendet Ereignisse an eine zentrale Delta-Tabelle. Wenige nachgelagerte Leser innerhalb derselben Datenplattform greifen direkt zu. App-Telemetry für ein Mobile-Produkt, das in Genie ausgewertet werden soll. IoT-Sensorik einer Geräteflotte für ein Dashboard und ein ML-Feature. Click-Streams einer Web-Property für Realtime-Personalisierung. Ein Broker würde in dieser Topologie zusätzlichen Betrieb verursachen, ohne einen unabhängigen Fan-out zu ermöglichen.
Passt: Direkte Anbindung von Anwendungen ohne bestehende Streaming-Plattform. Eine SaaS-Komponente, ein Backend-Worker oder eine Mobile-App soll Events ins Lakehouse senden, und es gibt kein bestehendes Streaming-Vertragsmodell zwischen Producer-Team und Plattform-Team. Zerobus reduziert die technische Schnittstelle auf Zielschema, Berechtigungen und Delivery-Verhalten. Producer-Team und Plattform-Team einigen sich auf das Schema, nicht auf Topics, ACLs, Schema-Registry-Modi und Connect-Konfigurationen. Der geringere Abstimmungs- und Betriebsaufwand wird vor allem im laufenden Betrieb sichtbar.
Passt: Konsolidierung mehrerer kleiner Streams. Wenn ein Plattform-Team heute drei oder vier kleine Streams über Kafka fährt, die jeweils nur einen Consumer haben, ist das ein möglicher Kandidat für eine Vereinfachung der Architektur. Die Broker-Lizenz, der Connect-Cluster und das separate Monitoring rechnen sich nicht für drei Streams.
Passt nicht: Zentrale Ereignisplattform mit mehreren unabhängigen Konsumenten. Wenn derselbe Event-Stream gleichzeitig von einem Streaming-Job, einem CRM-System, einem externen Partner und einem Reverse-ETL-Tool gelesen wird, die jeweils eigene Offsets und Verarbeitungsgeschwindigkeiten benötigen, ist Kafka die richtige Wahl. Mehrere Systeme können zwar dieselbe Delta-Tabelle lesen. Ein brokerbasiertes Consumer-Group- und Offset-Modell wird dadurch jedoch nicht ersetzt.
Passt nicht: Langfristige Wiederverarbeitung anhand unabhängiger Consumer-Offsets. Wenn ein Use-Case verlangt, dass jeder Event der letzten 30 Tage neu prozessiert werden kann (Modell-Retraining, Compliance-Audit, Reprozessing nach Schema-Änderung), liefert Kafka mit Topic-Retention das passende Modell. Auch Delta kann historische Daten innerhalb des Aufbewahrungsfensters bereitstellen. Das Betriebs- und Kostenmodell unterscheidet sich jedoch von einer gezielt dafür konfigurierten Topic-Retention.
Passt nicht: Stream-Processing-Joins. Joins zwischen zwei Streams (Order-Events × Inventory-Events in einem Streaming-Window) gehören in einen Stream-Processor: Structured Streaming, Kafka Streams oder Flink. Zerobus übernimmt lediglich die Übertragung der Ereignisse. Joins und zustandsbehaftete Verarbeitung erfolgen anschließend in einer Streaming-Engine.
Auto Loader bleibt für File-Drops. Wenn die Quelle Dateien in Object Storage ablegt (SaaS-Exporte, Batch-Drops, Partner-Übergaben), ist Auto Loader der richtige Pfad. Wie Auto Loader incremental Dateien aufnimmt und mit Zerobus für aktive Producer den Lade-Pfad teilt, zeigen wir im Detail zu Auto Loader für inkrementelles File-Ingest.
Realtime BI und ML-Features auf Zerobus-Streams
Der Nutzen von Zerobus hängt wesentlich von den nachgelagerten Verarbeitungs- und Analysepfaden ab. Eine Delta-Tabelle, die alle paar Sekunden mit frischen Events befüllt wird, kann anschließend ohne zusätzliche Broker-Senke verarbeitet oder abgefragt werden: als Streaming-Source für ein Structured-Streaming-Job, als SQL-Tabelle für ein Dashboard, als Feature-Quelle für ein ML-Modell.
Die typische Pipeline: Zerobus schreibt nach Bronze, Structured Streaming oder Lakeflow Declarative Pipelines aggregiert in Silver und Gold, und ein Genie-Space liest die Gold-Tabelle. Bei der IoT-Geräteflotte aus dem Einstieg läuft das so: 50.000 Sensoren schreiben über das Zerobus-SDK ihre Events in eine Bronze-Tabelle iot_events_raw, ein Streaming-Job aggregiert pro Minute und Gerätegruppe in iot_events_minute, der Genie-Space liest die Aggregation für die Betriebs-Leitstelle. Die Verarbeitung bleibt innerhalb eines gemeinsamen Databricks-Stacks.
Ein vergleichbares Muster lässt sich für Machine-Learning-Features verwenden. Die Zerobus-Tabelle wird zur Feature-Quelle, ein Streaming-Job berechnet fortlaufende Aggregationen über Zeitfenster und schreibt in die Feature-Store-Tabelle. Real-Time-Inferenz greift dann direkt auf die Feature-Tabelle zu.
Toyota nutzt Zerobus Ingest produktiv für Fertigungs-Telemetrie: Tausende von Sensoren auf der Fabrikfläche schreiben direkt ins Lakehouse. Sensordaten können innerhalb von Minuten für die Erkennung von Überhitzung ausgewertet werden. Joby Aviation streamt Flugzeug-Telemetrie und reduziert die Auflösungs-Latenz von Tagen auf Minuten. Beide Beispiele verwenden Databricks als zentrale Senke und stellen die Daten anschließend mehreren Lesern auf Tabellenebene bereit.
Wie Lakeflow Declarative Pipelines die Transformations-Schicht ab Bronze übernimmt und Streaming-Aggregationen deklarativ orchestriert, klären wir im Detail zu Declarative Pipelines auf Databricks.
Authentifizierung, Unity Catalog und Private Link
Zerobus verwendet die bestehenden Authentifizierungs- und Berechtigungsmechanismen von Databricks. Producer authentifizieren sich mit OAuth-Tokens, Personal Access Tokens oder Service Principals. Für produktive Setups ist der Service Principal der Standard: Keine Abhängigkeit von einem persönlichen Benutzerkonto, separat verwaltete Zugangsdaten und Rotation, eigene Berechtigungen.
Berechtigungen auf die Ziel-Tabelle laufen über Unity Catalog. Der Service Principal braucht MODIFY-Recht auf die Tabelle (oder die entsprechende Berechtigung im Schema). Damit greift dieselbe Governance, die auch für SQL-Schreibzugriffe gilt. Eine separate Berechtigungsverwaltung für den Ingestion-Dienst ist nicht erforderlich; eine separate ACL-Verwaltung wie bei Kafka ebenfalls.
Für Netzwerk-Isolation steht Private Link zur Verfügung. Der gRPC-Stream läuft dann über die Private-Link-Verbindung zwischen VPC und Databricks-Workspace, ohne dass der Datenverkehr über eine öffentliche Internetverbindung geführt werden muss. Das kann eine wichtige Voraussetzung für produktive Einsätze mit erhöhten Netzwerk- und Compliance-Anforderungen sein (Banken, Versicherungen, Gesundheits-Sektor). Zerobus Ingest ist auf AWS und Microsoft Azure allgemein verfügbar. Für Google Cloud wurde Unterstützung angekündigt. Welche Endpoint- und Netzwerk-Konfiguration konkret unterstützt wird, hängt vom Cloud-Provider und der GA-Region ab.
Wie Unity Catalog als zentrale Governance-Schicht über Ingestion, Berechtigungen und Lineage hinweg wirkt, zeigen wir im Überblick zu Unity Catalog auf Databricks.
SDK-Versionierung, Monitoring, Backfill und FinOps
Für den Betrieb muss geklärt werden, welches Team welche Komponente verantwortet. Ein Teil des Betriebsaufwands verlagert sich vom Brokerbetrieb in die sendenden Anwendungen.
SDK-Versionierung in den Producer-Apps. Das SDK ist eine normale Library-Dependency in der Producer-App. Bei einem Versions-Upgrade muss die App neu gebaut, getestet und deployt werden wie jede andere Library. Die Aktualisierung folgt dem normalen Entwicklungs- und Releaseprozess der jeweiligen Anwendung und liegt damit beim Producer-Team. Bei vielen Producer-Apps (zehn Mobile-Apps, fünf Backend-Services, drei Edge-Gateways) ist das ein realer Aufwand. Verwendete SDK-Versionen sollten zentral erfasst und überwacht werden.
Endpoint-Konfiguration als Code. Endpunkt, Berechtigungen und Netzwerkkonfiguration sollten reproduzierbar als Code verwaltet werden: über Terraform oder Asset Bundles statt ausschließlich manuell im Workspace. Das spart Migration-Aufwand bei Workspace-Wechseln und macht die Konfiguration reproduzierbar.
Monitoring für Producer, Endpunkt und Zieltabelle. Erstens am Endpoint: Throughput, Error-Rate, Acknowledgement-Latenz. Zweitens an der Delta-Tabelle: Schreibrate, File-Count, Optimize-Frequenz. Drittens in der Producer-App: gRPC-Send-Errors, Retry-Counts, lokale Puffer-Auslastung. Bei erhöhten Fehlerraten oder verzögerten Bestätigungen sieht man es an allen drei Stellen. Die Fehleranalyse sollte sowohl die Producer-Metriken als auch den Endpunkt und die Zieltabelle einbeziehen. Databricks stellt für die Nutzungs-Sicht zwei System-Tables für Zerobus Ingest bereit: eine connector-spezifische Usage-Tabelle für Throughput-Metriken und die billable-usage-Tabelle (Filter billing_origin_product = 'LAKEFLOW_CONNECT') für Kosten- und Verbrauchsauswertungen.
Backfill-Strategie für Producer-Ausfälle. Ohne lokale oder vorgelagerte Persistenz können Ereignisse während eines längeren Producer-Ausfalls nicht nachträglich übertragen werden. Für kritische Quellen sollte deshalb ein zusätzlicher Puffer- oder Backfill-Pfad vorgesehen werden: Der Producer puffert Events lokal als Files (auf dem Edge-Gerät oder im Backend-Storage), Auto Loader nimmt die Files später auf. Das ergibt ein Hybrid-Modell: Zerobus für den Live-Stream, Auto Loader für die nachträgliche Verarbeitung lokal oder im Objektspeicher gepufferter Dateien.
FinOps: Endpoint-Kosten gegen Broker-Betrieb. Da sich Preise ändern können, sollte der Vergleich auf dem jeweils aktuellen Preismodell basieren. Für die Bewertung sind insbesondere folgende Kostenblöcke relevant: Zerobus rechnet als serverloser Compute-Anteil ab, gemessen am aufgenommenen Datenvolumen (Größenordnung rund 0,05 US-Dollar pro GB, inklusive des zugrunde liegenden Compute, abhängig von Plan, Cloud und Region), plus die normalen Storage- und Compute-Kosten der Delta-Tabelle. Das steht gegen Broker-Lizenz (Confluent Cloud oder Self-Managed-Betrieb) plus Streaming-Job-Compute auf Databricks. Bei kleinen bis mittleren Streams ist Zerobus typischerweise günstiger, weil der Broker-Anteil entfällt. Bei vielen unabhängigen Konsumenten verteilt sich der Aufwand der Broker-Plattform auf mehrere Anwendungsfälle.
Grenzen von Zerobus Databricks
Zerobus löst nicht jedes Streaming-Problem. Die wichtigsten Einschränkungen:
Plattformbindung an Databricks. Die SDKs sind Databricks-spezifisch, die Ziel-Tabelle ist Delta in Unity Catalog. Unabhängige Konsumenten außerhalb von Databricks können nicht direkt am ursprünglichen Ingestion-Stream teilnehmen. Für plattformübergreifende Ereignisarchitekturen ist eine offene Broker-Plattform häufig besser geeignet.
Kein Stream-Processing in der Quelle. Zerobus übernimmt ausschließlich die Datenaufnahme. Verarbeitung passiert woanders. Joins, Aggregationen, Window-Funktionen gehören in Silver/Gold mit Structured Streaming oder Lakeflow Declarative Pipelines. Transformationen und zustandsbehaftete Verarbeitung erfordern einen nachgelagerten Streaming-Prozess.
Replay-Modell anders als bei Kafka. Delta Time Travel kann Records über ein definiertes Fenster re-prozessieren. Die Wiederverarbeitung erfolgt über Tabellenstände und Dateien, nicht über unabhängige Broker-Offsets. Benötigt jeder Konsument eigene Offsets und einen individuellen Replay-Fortschritt, ist Kafka besser geeignet.
Schemaänderungen müssen zunächst an der Zieltabelle vorgenommen und anschließend mit den Producern abgestimmt werden. Wenn der Producer ein neues Feld einführt, muss erst die Tabelle das Schema kennen. Sonst weist der Endpoint die Records zurück. Das ist genauer als Kafkas Schema-Registry-Compatibility-Modi und erfordert eine engere Koordination zwischen Plattform- und Anwendungsteam.
SDK-Sprach-Abdeckung außerhalb der Top 5. Python, Java, Rust, Go und TypeScript liegen als GA vor. Das deckt die meisten Produktiv-Stacks ab. Für weitere Programmiersprachen (C#, .NET, Kotlin oder PHP) bleibt entweder die REST-Schnittstelle (Beta) oder eine individuell entwickelte Integration auf Basis des gRPC-Protokolls.
Junges Produkt. Zerobus wurde 2025 auf dem Data + AI Summit vorgestellt und ist 2026 GA gegangen. Funktionsumfang, Limits und Betriebszusagen wurden seit der ersten Ankündigung weiterentwickelt. Vor produktiven Setups gegen die aktuelle Doku prüfen, nicht ausschließlich anhand älterer Ankündigungen oder Preview-Dokumentation.
Roadmap-Hinweis. Databricks hat im Petabyte-Scale-Blog vier geplante Features angekündigt: Kafka-Producer-API-Support, MQTT-Support, eine Rescue-Spalte und Avro-Format. Wenn die Kafka-Producer-API kommt, könnte sich der Aufwand für die Migration bestehender Producer reduzieren: Producer-Code schreibt ohne Umbau gegen Zerobus. MQTT-Support würde zusätzliche direkte Integrationsmöglichkeiten für IoT-Quellen schaffen, statt MQTT-Broker am Edge plus Confluent-Cloud-Übergang dazwischen aufzubauen. Beides ist angekündigt, ohne konkreten Liefertermin. Vor der Architektur-Entscheidung gegen den aktuellen Roadmap-Stand prüfen.
In einer Multi-Cloud-, Multi-Plattform-Welt mit echten Fan-out-Anforderungen bleibt Kafka die richtige Basis. Mit dem Lakehouse als zentraler Senke und Telemetry-, Click-Stream- oder IoT-Quellen ohne Broker-Aufwand bringt Zerobus eine spürbare Vereinfachung.
Fazit
Zerobus Ingest schreibt direkt per gRPC von der sendenden Anwendung in eine Delta-Tabelle im Unity Catalog. Broker, Topics und separate Connect-Worker braucht es dafür nicht.
Für den sinnvollen Einsatz zählen drei Fragen. Wie viele unabhängige Leser brauchen denselben Event-Stream? Zerobus passt bei einem bis wenigen Lesern ohne echtes Fan-out oder wochenlanges Replay. Reicht at-least-once? Mit Sequenz-Idempotenz deckt das die meisten Telemetrie-Fälle ab. Und sind SDK-Updates fest im Lebenszyklus der Producer-Anwendungen eingeplant, statt nachträglich?
Zerobus ist kein vollständiger Ersatz für eine unternehmensweite Streaming-Plattform mit mehreren unabhängigen Konsumenten. Es ist eine geeignete Lösung für den Fall, dass eine einzelne Telemetriequelle Daten ausschließlich nach Databricks übertragen soll.
Kafka oder Kinesis sollten dort eingesetzt bleiben, wo unabhängige Konsumenten, brokerbasierte Wiederverarbeitung oder komplexe Stream-Verarbeitung erforderlich sind. Die eingesetzten SDK-Versionen sollten je Producer-Anwendung nachvollziehbar verwaltet werden. Metriken zu Durchsatz, Fehlerraten und Bestätigungslatenz sollten von Beginn an überwacht werden.
Zerobus sollte bei Event-Streams mit Databricks als zentralem Ziel frühzeitig in die Architekturprüfung einbezogen werden.
FAQ
Zerobus Ingest ist ein push-basierter Direkt-Ingest-Pfad in Databricks. Producer-SDKs (Python, Java, Rust, Go, TypeScript) öffnen einen gRPC-Stream gegen einen Workspace-Endpoint und schreiben Event-Datensätze direkt in eine Delta-Tabelle in Unity Catalog. Es gibt weder Broker noch Topic-Konzept noch Consumer-Groups. Der Consumer-Layer ist die Delta-Tabelle selbst.
