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.
• Einschränkungen: nicht unterstützte Tabellentypen, Tabellenoperationen und streamübergreifende Reihenfolge.
• Unterstützte Datentypen: die Typzuordnung von Delta zu Protobuf.

Wie Zerobus Ingest funktioniert

Ein Datenproduzent verbindet sich zunächst mit einer Zerobus Ingest API, gibt eine Ziel-Delta-Tabelle an, erstellt eine Nachricht, die ihrem Schema entspricht, und sendet dann die Nachricht. Der Dienst macht die Daten langlebig und bestätigt bei Schnittstellen, die Langlebigkeitsbestätigungen bieten, die Botschaft des Clients. Anschließend materialisiert es die Daten in einem separaten Schritt in optimierter Form in die Delta-Tabelle. Eine Langlebigkeitsbestätigung bestätigt die Langlebigkeit, nicht die Anfragebarkeit. 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, OpenTelemetry, MQTT und Kafka-kompatible APIs sowie wann jede verwendet werden soll.
• 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 langlebig und bestätigt ihn dem Client, wenn die Schnittstelle eine Langlebigkeitsbestätigung liefert. 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 langlebig speichern und, sofern die Schnittstelle eine Bestätigung der Langlebigkeit bereitstellt, diese dem Client bestätigen. 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, wenn die Schnittstelle sie unterstützt, dass sie langlebig 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, OpenTelemetry, MQTT und Kafka-kompatible APIs) und wann man jede auswählen sollte, 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:

• Die Zieltabelle muss eine verwaltete Delta-Tabelle oder eine Streaming-Tabelle sein.
• Tabellennamen dürfen nur ASCII-Buchstaben, Ziffern und Unterstriche enthalten.
• 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. Für nicht unterstützte Tabellentypen und -operationen, siehe Einschränkungen.

Einschränkungen

Zerobus Ingest hat folgende Einschränkungen:

• Zerobus Ingest schreibt nicht in externe Tabellen oder Views.
• Zerobus Ingest schreibt nicht in einen Speicher, der über einen privaten Endpunkt gesichert ist.
• Zerobus Ingest erstellt keine Zieltabellen oder ändert deren Schema. Du erstellst die Tabelle und entwickelst das Schema der Tabelle weiter. Siehe Schemaentwicklung.
• Zerobus Ingest unterstützt das erneute Erstellen einer Zieltabelle nicht.
• Zerobus Ingest unterstützt das Umbenennen oder Ersetzen einer Zieltabelle nicht, während die Datenaufnahme läuft. Siehe Zieltabelle umbenennen oder ersetzen.
• Zerobus Ingest unterstützt keine Tabellennamen, die andere Zeichen als ASCII-Buchstaben, Ziffern und Unterstriche enthalten.
• Zerobus Ingest garantiert keine Reihenfolge über verschiedene Streams hinweg. Die Reihenfolge ist nur innerhalb eines einzigen Streams garantiert. Siehe Garantierte Reihenfolge.

Für numerische Grenzen wie Durchsatz, Datensatzgröße und Partitions-Fan-out siehe Zerobus Ingest Quotas.

Eine Zieltabelle umbenennen oder ersetzen

Benennen Sie keine Zieltabelle um, löschen Sie sie nicht und erstellen Sie sie nicht neu oder ersetzen Sie eine Zieltabelle durch ein anderes Objekt, wie zum Beispiel eine Ansicht, während Streams darauf schreiben. Zerobus Ingest kann gepufferte Daten nicht in eine umbenannte oder ersetzte Tabelle leeren, sodass die betroffenen Streams keinen Fortschritt mehr machen und Datensätze, die noch nicht bestätigt sind, nicht geleert werden können. Daten, die nicht geleert werden, werden nach der Speicherzeit der gepufferten Daten gelöscht.

Schemaänderungen, wie das Hinzufügen einer Spalte mit ALTER TABLE, werden unterstützt. Siehe Schemaentwicklung.

Um eine Zieltabelle sicher umzubenennen oder zu migrieren:

1. Stoppen Sie Ihre Producer, leeren und schließen Sie dann jeden Stream, der in die Tabelle schreibt. Siehe Leeren und ordnungsgemäßes Schließen.
2. Bestätigen Sie, dass die aktuellsten Einträge in der Tabelle erscheinen.
3. Umbennen oder migrieren Sie die Tabelle.
4. Gewähren Sie dem Dienstprinzipal, der die Daten erfasst, USE CATALOG, USE SCHEMA, SELECT und MODIFY für die neue Tabelle. Siehe Erstellen eines Service-Prinzipals und Berechtigungen erteilen.
5. Aktualisieren Sie Ihre Producer, damit sie den neuen Tabellennamen verwenden, und öffnen Sie dann neue Streams. Wenn deine Producer OAuth-Tokens anfordern, die auf eine Tabelle abgegrenzt sind, fordere sie für die neue Tabelle an.

Unterstützte Datentypen

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

Avro-Typen

Wenn du Datensätze im Avro-Format aufnimmst, dekodiert Zerobus Ingest jeden Datensatz anhand des von dir bereitgestellten Avro-Schreibschemas und passt ihn an die Typen der Ziel-Delta-Tabelle an. Die folgende Tabelle zeigt, wie Avro-Typen auf Delta-Typen abgebildet werden.

Diese Abbildung folgt den Datenquellenkonventionen von Spark Avro. Für das Avro-Typsystem selbst siehe die Apache Avro-Spezifikation.

TIMESTAMP Spalten werden als UTC-Zeitpunkte geschrieben. Avro verfügt über keinen 8-Bit- oder 16-Bit-Ganzzahltyp, daher können TINYINT- und SMALLINT-Spalten nicht von Avro als Ziel verwendet werden. Avro kann auch nicht in VARIANT, VOID, INTERVAL, , GEOMETRYoder GEOGRAPHY Spalten schreiben. Ein Schema, das auf eines davon abzielt, wird beim Erstellen des Streams abgelehnt.

Avro-Schreibschemata müssen auch jeden Typ inline deklarieren; benannte Typreferenzen werden nicht unterstützt. Siehe Avro.