Zerobus-Ingest-Konzepte

Diese Seite beschreibt die Kernkonzepte von Zerobus Ingest in Lakeflow Connect: wie der Dienst funktioniert, seine Streams, Server und Clients sowie die unterstützten Datentypen.

Springen Sie zu einem Konzept:

• Wie Zerobus Ingest funktioniert: der End-to-End-Ablauf, vom Producer bis zur abfragbaren Tabelle.
• Server: Wofür der Zerobus Ingest-Dienst verantwortlich ist.
• Kunde: Wofür dein Produzent verantwortlich ist.
• Streams: Die Verbindung, die dein Client öffnet, um Daten zu übernehmen.
• Wie Zerobus Ingest skaliert: Warum es ohne Kapazitätsplanung skaliert.
• Tabellenanforderungen: Was dein Zieltisch und Arbeitsbereich erfüllen muss.
• Unterstützte Datentypen: die Typzuordnung von Delta zu Protobuf.

Wie Zerobus Ingest funktioniert

Ein Datenproduzent öffnet zunächst einen Stream in der Zerobus Ingest API, gibt eine Ziel-Delta-Tabelle an, erstellt eine Nachricht, die ihrem Schema entspricht, und schickt die Nachricht dann durch den geöffneten Strom. Der Dienst macht die Daten dauerhaft und bestätigt die Botschaft des Kunden. Anschließend materialisiert es die Daten in einem separaten Schritt in optimierter Form in die Delta-Tabelle. Die Bestätigung bestätigt die Haltbarkeit, nicht die Abfragbarkeit. Siehe Asynchrone Kommunikation , wie das funktioniert und was es für Ihren Kunden bedeutet.

Zerobus Ingest ist ein serverloser Dienst, der elastisch mit deiner Arbeitslast skaliert. Wie es skaliert, siehe Wie Zerobus Ingest skaliert unten.

Dieser Abschnitt behandelt außerdem, wie Sie sich mit Zerobus Ingest verbinden und welche Formen Ihre Daten annehmen können:

• API-Protokolle: Die API-Protokolle, gRPC mit SDKs, REST und OpenTelemetry sowie wann man sie verwendet.
• Nachrichtentypen: Die Datensatzformate, JSON, Protocol Buffers (protobuf) und Apache Arrow sowie wann jeder verwendet werden sollte.

Server

Der Zerobus Ingest-Dienst erstellt oder bearbeitet keine Tabellen automatisch. Benutzer müssen die Tabelle selbst erstellen. Tabellen und ihre Schemas sind die autoritativen Quellen für die Erwartungen an eingehende Daten.

Der Zerobus-Ingest-Server nimmt von Clients an ihn gesendete Daten entgegen und prüft, ob sie dem Zieltabellenschema entsprechen. Wenn der Datensatz passt, macht der Server ihn dauerhaft und erkennt ihn gegenüber dem Client an. Die Materialisierung des Datensatzes in der Delta-Tabelle, sodass er abfragbar wird, erfolgt kurz darauf als separater Schritt.

Zu den Dienstaufgaben gehören:

• Schema-Validierung der Nachricht anhand der Tabelle.
• Den Datensatz dauerhaft machen und gegenüber dem Client anerkennen. Die Bestätigung bestätigt die dauerhafte Speicherung, nicht, dass der Datensatz bereits abfragbar ist.
• Die zeitnahe Materialisierung der Daten in die Zieltabelle; ab diesem Zeitpunkt sind sie abfragbar. Für Latenzzahlen siehe Latenz.

Client

Ein Client verbindet sich mit Zerobus Ingest, sendet Datensätze und bestätigt, dass sie dauerhaft sind. Wenn Sie ein Zerobus Ingest SDK verwenden, übernimmt das SDK den Großteil davon, was hilft, Ihre Konfiguration von dem zu trennen, was das SDK automatisch tut.

Sie konfigurieren oder implementieren:

• Auswählen einer Zieltabelle.
• Öffnen eines Streams für den Zerobus-Ingest-Dienst.
• Eine schemakompatible Nachricht erstellen und sie senden.

Das SDK verwaltet automatisch:

• Nachrichtenbestätigungen. Das SDK führt die Anerkennungsschleife für Sie aus und liefert Dauerhaftigkeitsbestätigungen durch Offsets oder einen Anerkennungsrückruf. Du sperrst nur einen bestimmten Datensatz, wenn deine Anwendung das erfordert. Siehe Asynchrone Kommunikation.
• Genesung. Standardmäßig verbindet sich das SDK erneut und spielt nicht bestätigte Datensätze bei vorübergehenden Ausfällen erneut ab.
  • Du kannst die eingebaute Wiederherstellung deaktivieren und stattdessen deinen eigenen Wiederherstellungsmechanismus implementieren. Was die Wiederherstellung auslöst, die Konfigurationsoptionen und benutzerdefinierte Wiederherstellungsmuster, siehe Wiederherstellungs- und Wiederholungsmuster.

Sie müssen keine Bestätigungs- oder Wiederherstellungslogik manuell schreiben, wenn Sie ein SDK verwenden. Für benutzerdefinierte Integrationen, die kein SDK verwenden, dient das Zerobus SDK-Repository als Referenz für Integrationsstruktur und Wiederherstellungsabwicklung.

Ströme

Ein Stream ist eine direkte Verbindung zwischen Ihrem Client und dem Zerobus Ingest-Server, die über eine persistente, bidirektionale gRPC-Verbindung hergestellt wird. Die SDKs verwenden Datenströme, um langlebige Verbindungen mit hohem Durchsatz zu ermöglichen.

• Datenströme werden nur in der gRPC-API mit den SDKs verwendet.
• Ein Stream führt Daten in eine einzelne Zieltabelle zusammen.
• Öffnen Sie zusätzliche Streams, um in verschiedene Tabellen zu schreiben oder den Durchsatz eines einzelnen Kunden so hoch zu skalieren, wie Ihre Arbeitsbelastung es erfordert.

Streams sind auch die Einheit für die Reihenfolge (siehe Reihenfolgegarantien) und die Einheit, über die Zerobus Ingest skaliert (siehe Wie Zerobus Ingest skaliert).

Reihenfolgegarantien

Die Bestellung ist pro Stream garantiert. Datensätze werden in der Reihenfolge in die Zieltabelle geschrieben, in der sie in die Warteschlange eines einzelnen Streams eingereiht werden. Es gibt keine globale Ordnung über die Ströme hinweg. Daraus ergeben sich mehrere Designpunkte:

• Wenn man Datensätze über mehrere Ströme verteilt (zum Beispiel Round-Robin), gibt es keine Ordnungsgarantie über diese Ströme.
• Wenn dein Anwendungsfall eine einzige Gesamtreihenfolge über viele Produzenten oder Streams hinweg erfordert, setze diese Reihenfolge in deiner Anwendung durch (zum Beispiel mit einem Zeitstempel oder einer Sequenznummer, auf die du abfragst), anstatt dich auf die Eingabereihenfolge zu verlassen.

Warum gRPC-Streaming

Da die gRPC-Verbindung eines Streams offen bleibt, vermeidet der Client den bei jeder Anfrage anfallenden Einrichtungsaufwand eines zustandslosen Protokolls und kann einen kontinuierlichen Datenstrom mit hohem Volumen über einen einzigen Kanal senden. Dies macht die SDKs zur Methode mit dem höchsten Durchsatz für die Datenerfassung. Für die anderen Schnittstellen (REST und OpenTelemetry) und wann Sie jeweils auswählen sollten, siehe API-Protokolle.

Wie Zerobus Ingest skaliert

Zerobus Ingest ist für hohe Skalierbarkeit konzipiert und erreicht diese Größenordnung, ohne dass man die Kapazität planen muss. Zwei Designentscheidungen machen dies möglich:

• Es ist serverlos. Der Dienst erhöht und reduziert die Kapazität automatisch, wenn sich die Last ändert, sodass Sie Broker nicht dimensionieren oder Partitionen bereitstellen müssen. Du kannst so viele parallele Streams öffnen und in so viele Tabellen schreiben, wie deine Arbeitsbelastung benötigt.
• Streams sind dynamische Partitionseinheiten. Anstelle einer festen Menge von Partitionen, die für eine horizontale Skalierung neu partitioniert und neu ausbalanciert werden müssen, können Streams geöffnet, geschlossen und rotiert werden. Rotierende Ströme ermöglicht es dem Service, Kapazität und Ressourcen neu auszubalancieren, wenn sich die Nachfrage verändert, sodass du skalierst, indem du mehr Streams öffnest und mehr Produzenten betreibst, während der Service den Rest aufnimmt.

Das praktische Ergebnis ist, dass ein "Hello World"-Client und eine Workload im Petabyte-Maßstab im Wesentlichen denselben Code ausführen. Der Unterschied liegt darin, wie viele Produzenten und Streams du betreibst. Dieses Design hat die Aufnahme von über 1 Billion Datensätzen in eine einzige Delta-Tabelle ermöglicht. Zum technischen Hintergrund siehe den Blogbeitrag „Ingesting the Milky Way: Petabyte-Scale with Zerobus Ingest“.

Tabellenanforderungen

Zerobus Ingest schreibt in eine Delta-Tabelle, die du erstellt und besitzt. Die Zieltabelle und der Arbeitsbereich müssen folgende Anforderungen erfüllen:

• Zerobus Ingest schreibt nur in verwaltete Delta-Tabellen. Das Schreiben in den Standardspeicher wird nicht unterstützt.
• Zerobus Ingest schreibt nicht auf Speicher, der über einen privaten Endpunkt gesichert ist.
• Zerobus Ingest unterstützt die Neuerstellung einer Zieltabelle nicht.
• Tabellennamen unterstützen nur ASCII-Buchstaben, Ziffern und Unterstrichen.
• Der Arbeitsbereich und die Zieltabelle müssen beide in einem der unterstützten Regionen liegen.

Wie Datensätze gegen das Tabellenschema validiert werden, siehe Schema-Management. Für Tabellenmerkmale wie Partitionierung und Flüssigclusterung siehe Delta-Tabellenmerkmale.

Unterstützte Datentypen

In der folgenden Tabelle sind die unterstützten Delta-Typen und die entsprechenden Protobuf-Typen für die Aufnahme aufgeführt.