API-Protokolle

Zerobus Ingest stellt einen Endpunkt mit mehreren API-Protokollen bereit: gRPC (über die SDKs), REST, OpenTelemetry (OTLP), MQTT und Kafka-kompatible APIs. Alle schreiben direkt in Unity Catalog Delta-Tabellen, sodass du das Protokoll auswählst, das am besten zu jedem Produzenten passt.

Das folgende Diagramm zeigt, wie Datensätze aus Quellströmen und APIs durch Auto-Skalierung und Lastverteilung zu einem horizontal skalierbaren Pool zustandsloser Zerobus-Knoten fließen. Jeder Knoten hat ein Write-Ahead-Log und einen Lakehouse-Writer, der Datensätze in eine von Unity Catalog verwaltete Delta-Tabelle batch-commitet. Die Quellbezeichnungen im Diagramm sind repräsentativ. MQTT folgt demselben Weg durch Lastverteilung, langlebige Speicherung und Tischmaterialisierung.

Zerobus Ingest-Architekturdiagramm, das Quell-APIs zeigt, die durch Lastverteilung und zustandslose Knoten in eine Delta-Tabelle fließen.

Welches Protokoll solltest du verwenden?

Protocol Am besten geeignet für: Warum?
gRPC (SDKs) Produzenten von Datenströmen mit hohem Volumen: Datenerfassung ändern, Clickstream, Protokoll- und Ereignisweiterleitungen. Dauerhafte Verbindungen liefern den höchsten dauerhaft erzielbaren Durchsatz und bewahren die Reihenfolge innerhalb jedes Streams. Verfügbar in Python, Java, Rust, Go, TypeScript und (in der Beta) C++ und C# / .NET. Siehe Write a Client.
REST Große Bestände leichter oder „gesprächiger” Clients, wie Edge- und IoT-Geräte, die selten melden. Zustandslos: Jede Anfrage ist in sich abgeschlossen, sodass Clients keine offene Verbindung aufrechterhalten. Einfacher für Geräte, die gelegentlich Daten senden. Siehe das REST-Beispiel.
OpenTelemetry (OTLP) Observability-Pipelines, die bereits Spuren, Protokolle und Metriken aussenden. Richten Sie Ihre bestehenden OpenTelemetry-SDKs oder Collectors auf den Endpunkt ohne benutzerdefinierte Integration aus. Siehe OpenTelemetry-Daten mit Zerobus Ingest erfassen.
MQTT IoT-, Edge- und Telemetrieanwendungen, die bereits MQTT v5-Nachrichten veröffentlichen. Verwenden Sie einen MQTT v5-Client erneut, um JSON-Datensätze an ein Thema zu veröffentlichen, das nach der Zieltabelle benannt ist. Siehe Verwenden von MQTT mit Zerobus Ingest.
Kafka-kompatible APIs Produzenten, die bereits das Kafka-Protokoll sprechen oder Tools, die an Kafka aussenden, wenn man diese Daten in Delta mit minimaler Codeänderung haben möchte. Wiederverwenden Sie einen bestehenden Kafka-Producer ohne Azure Databricks SDK. Richten Sie es auf den Endpunkt aus und erstellen Sie ein Thema, das nach Ihrer Zieltabelle benannt ist. Siehe Use Kafka-compatible APIs with Zerobus Ingest.

gRPC mit den SDKs

Die Zerobus-SDKs umwickeln eine persistente, bidirektionale gRPC-Verbindung, die als Stream bezeichnet wird. Da die Verbindung offen bleibt, erzielt gRPC den höchsten anhaltenden Durchsatz und ist der empfohlene Weg für kontinuierliche, hochvolumige Aufnahme. Jeder offene Strom ist eine langjährige Verbindung, sodass der Durchsatz eines Kunden mit der Anzahl der geöffneten Ströme skaliert.

Die SDKs übernehmen das Verbindungsmanagement, das Offset-Tracking und die Wiederherstellung für Sie und sind in Python, Java, Rust, Go, TypeScript sowie (in der Beta) C++ und C# / .NET verfügbar. Sie bieten ein gleichwertiges Verhalten über verschiedene Sprachen hinweg, also wähle diejenige, die zu deiner Anwendung passt. Über gRPC unterstützen die SDKs JSON-, Protobuf- und Apache Arrow-Datensatzformate, und einige SDKs unterstützen auch Avro (Beta). Siehe Nachrichtentypen.

Um einen Client mit den SDKs zu schreiben, einschließlich eines Sprachbeispiels für jede Sprache, siehe Write a Client.

REST

Die REST-Schnittstelle ist zustandslos: Jede Anfrage wird von selbst abgeschlossen, ohne eine offene Verbindung zu halten. Das macht es zu einer hervorragenden Ergänzung für große Flotten leichter oder intermittierender Hersteller, zum Beispiel Edge- und IoT-Geräte, die selten Status melden, bei denen eine dauerhafte Verbindung pro Gerät unpraktisch wäre.

Die REST-Aufnahme wird durch eine Request-Rate-Quote geregelt (siehe Zerobus Ingest Quoten). Für einen Großvolumen-Hersteller bieten die SDKs über gRPC einen höheren Durchsatz als viele einzelne REST-Anfragen. Reservieren Sie REST für Produzenten, die selten senden oder keine dauerhafte Verbindung halten können.

OpenTelemetry (OTLP)

Zerobus Ingest enthält einen nativen OpenTelemetry Protocol-Endpunkt. Wenn Ihre Systeme bereits OpenTelemetry-Traces, -Logs und -Metriken erzeugen, können Sie Ihre vorhandenen OTLP-Exporter oder -Collector auf Zerobus Ingest ausrichten und diese Telemetriedaten direkt in Delta-Tabellen schreiben, die Ihnen gehören – in der Regel mit nur einer Konfigurationsänderung. Siehe OpenTelemetry-Daten mit Zerobus Ingest erfassen.

MQTT

Important

Dieses Feature befindet sich in der Betaversion.

Die MQTT-Schnittstelle akzeptiert MQTT v5-Verbindungen über TLS am Port 8883. Eine Verbindung zielt auf eine Tabelle ab, und jede Nachricht enthält ein UTF-8 JSON-Objekt. Verwenden Sie Quality of Service (QoS) Stufe 1, wenn der Producer eine dauerhafte Bestätigung benötigt. Für Setup, Authentifizierung, Einschränkungen und ein Python-Beispiel siehe Verwenden von MQTT mit Zerobus Ingest.

Kafka-kompatible APIs

Important

Die Kafka-kompatiblen APIs befinden sich in der Beta-Phase.

Zerobus Ingest bietet Kafka-kompatible Producer-APIs, sodass Sie Daten mit jedem Apache-Kafka-Producer-Client erfassen können, ohne ein Azure Databricks SDK zu benötigen. Sie verweisen mit einem vorhandenen Kafka-Producer auf den Endpunkt und produzieren in ein Thema, das nach Ihrer Zieltabelle benannt ist, und die Datensätze landen in einer Unity Catalog Delta-Tabelle. Das passt am besten, wenn man bereits einen Kafka-Produzenten oder einen Sammler oder Agenten betreibt, der an Kafka ausgibt, und diese Daten mit minimaler Codeänderung in Delta weiterleiten möchte.

Die Kafka-kompatiblen APIs implementieren die herstellerseitige Teilmenge des Kafka-Protokolls und sind nur schreibbar: Consumer-, Admin- und transaktionale APIs sind nicht verfügbar. Sie akzeptieren nur JSON-Daten. Der Durchsatz wird durch eine Request-Rate-Quote pro Arbeitsbereich geregelt und nicht durch einzelne Verbindungen. Das spezifische Kontingent finden Sie unter Zerobus-Ingest-Kontingente. Für den höchsten Durchsatz, die Bestätigungen pro Datensatz und die automatische Wiederherstellung verwenden Sie stattdessen ein Zerobus-SDK statt gRPC.

Für Einrichtung, Authentifizierung und ein Herstellerbeispiel siehe Use Kafka-compatible APIs with Zerobus Ingest.

  • Zuletzt aktualisiert um