Was der Empfänger tatsächlich mit einer geteilten Tabelle macht
von Jordan Soldo und Nikhil Tallam
Viele Datenaustausch-Architekturen beginnen mit einem bekannten Muster:
Teil 1 dieses Blogs beschrieb, warum eine freigegebene Tabelle eine bessere Alternative zu einem wiederkehrenden Datei- oder API-Feed sein kann. Schauen wir uns nun an, was der Empfänger tatsächlich mit dieser Tabelle macht.
Diese Anleitung konzentriert sich auf Databricks-zu-Databricks-Freigaben (D2D). Der Empfänger verfügt über einen in Unity Catalog aktivierten Databricks-Arbeitsbereich und greift über einen freigegebenen Katalog auf die freigegebene Tabelle zu. Der Anbieter gibt die Tabelle samt Verlauf frei, sodass der Empfänger sie als Structured Streaming-Quelle nutzen kann. Auf Databricks-zu-Open-Freigaben (D2O) kommen wir später in diesem Beitrag zurück.
Eine Delta-Tabelle behält einen geordneten Verlauf jeder an ihr vorgenommenen Änderung bei. OpenSharing stellt diese Tabelle über ein offenes Protokoll bereit, ohne sie zu kopieren. Die Daten verbleiben im Speicher des Anbieters, und der Empfänger liest sie live.
Auf Empfängerseite verweisen Sie einen Structured Streaming-Reader auf die freigegebene Tabelle. Spark zeichnet in einem Prüfpunkt auf, wie weit gelesen wurde, sodass jeder Durchlauf nur die seit dem letzten Durchlauf vorgenommenen Änderungen erfasst. Das Nachverfolgen von „Neuem seit meinem letzten Aufruf“ wird zur Aufgabe der Engine, die über verwaltete Daten läuft, während Datenherkunft und Zugriffskontrolle intakt bleiben.
Nehmen wir ein Beispiel: Ein Händler verwaltet eine Live-Bestelltabelle und gibt sie für einen externen Empfänger frei, der Databricks ausführt. Anstatt nächtliche CSV-Dateien zu erhalten, kann der Empfänger die freigegebene Bestelltabelle direkt abfragen. Wenn der Empfänger eine lokale Kopie für Analysen oder nachgelagerte Workloads benötigt, kann er die Daten inkrementell in eine Delta-Tabelle materialisieren. Die Einrichtung erfolgt einmalig und ist zwischen Anbieter und Empfänger aufgeteilt.
Erstellen Sie die Quell-Tabelle mit aktiviertem Change Data Feed und veröffentlichen Sie sie dann in einer Freigabe WITH HISTORY. Der Verlauf macht die Tabelle zu einer inkrementellen Quelle. Ohne ihn erhält der Empfänger nur einen statischen Schnappschuss. Das Aktivieren von Change Data Feed (delta.enableChangeDataFeed) ist für den unten beschriebenen Haupt-Lesevorgang der Inkremente optional. Schalten Sie es nur ein, wenn Sie später den Pfad für Upserts und Löschungen nutzen möchten. Wenn Sie Databricks Runtime 19 oder höher verwenden, können Sie die Eigenschaft überspringen und sich auf den automatischen Change Data Feed verlassen, der zeilenbasierte Änderungen zum Abfragezeitpunkt für Tabellen mit aktiviertem Zeilen-Tracking berechnet und mit Databricks-zu-Databricks OpenSharing funktioniert.
Registrieren Sie den Empfänger anhand seiner Freigabe-Kennung und erteilen Sie dann die Berechtigung für die Freigabe:
Beachten Sie, dass CREATE SHARE und CREATE RECIPIENT Berechtigungen auf Metastore-Ebene erfordern und nicht nur Arbeitsbereichs-Admin-Rechte.
Die Freigabe wird nun als Anbieter in Ihrem Metastore angezeigt. Binden Sie sie als Katalog ein, und Sie können sie wie jede andere Tabelle lesen.
Da die Freigabe als shared_in eingebunden ist, wird das Lesen von Structured Streaming übernommen.
Trigger.AvailableNow verarbeitet alle aktuell verfügbaren, unzuverlässigen Daten in einem oder mehreren Micro-Batches und beendet sich dann. Damit eignet sich dies gut für geplante inkrementelle Jobs. Statt eines festen Zeitplans können Sie den Job auch mit einem Tabellen-Update-Trigger für die freigegebene Tabelle konfigurieren, sodass der Job nur dann ausgeführt wird, wenn der Anbieter neue Daten überträgt. Es wird empfohlen, den Prüfpunkt in dauerhaftem Cloud-Speicher wie UC Volumes zu speichern.
Hinweis: Dieses Beispiel liest eine freigegebene Tabelle über Delta Sharing und verwendet daher ignoreChanges. Wenn Sie direkt aus einer regulären Delta-Tabelle streamen, verwenden neuere Databricks Runtimes skipChangeCommits für die ausschließliche Verarbeitung von Anhängen.
Um zu beweisen, dass es tatsächlich inkrementell ist, führen Sie den Stream einmal gegen einen initialen Satz von Zeilen aus. Führen Sie ihn erneut aus, nachdem Sie neue Zeilen beim Anbieter haben. Der Commit-Verlauf der Ziel-Tabelle zeigt zwei Streaming-Schreibvorgänge:
Version | Vorgang | Vorgangsmetriken |
|---|---|---|
2 | STREAMING UPDATE | numRemovedFiles: 0, numOutputRows: 200, numOutputBytes: 2307, numAddedFiles: 1 |
1 | STREAMING UPDATE | numRemovedFiles: 0, numOutputRows: 1000, numOutputBytes: 4958, numAddedFiles: 1 |
0 | CREATE TABLE | {} |
Der zweite Durchlauf hat 200 Zeilen geschrieben, nicht 1200. Der Prüfpunkt hat die zuletzt gelesene Version verfolgt, sodass der Durchlauf nur die neuen Daten abgerufen hat.
ignoreChanges eignet sich für dieses inkrementelle Lademuster, kann jedoch Zeilen erneut ausgeben und überträgt keine Löschungen. Wenn nachgelagerte Verbraucher Einfügungen, Aktualisierungen und Löschungen benötigen, lesen stattdessen den Change Data Feed der freigegebenen Tabelle:
Wenn ein neuer Kunde hinzugefügt wird, muss der Anbieter keinen neuen SFTP-Endpunkt erstellen oder einen neuen Export-Job implementieren. Der Anbieter gewährt dem Empfänger Zugriff auf die Freigabe. Der Empfänger verwendet dasselbe allgemeine Muster und hält dabei seine eigenen Zieltabellen und nachgelagerten Geschäftslogiken separat. Der betriebliche Unterschied ist erheblich:
Alles Oben genannte funktioniert, weil der Empfänger Spark auf Databricks ausführt, was das streamen mit Prüfpunkt und CDF ermöglicht. Andere Empfänger (pandas, BI-Tools, Snowflake) verbinden sich über OpenSharing mit einer Anmeldeinformationsdatei anstelle einer Metastore-Freigabe-ID.
Wenn sie OSS Spark ausführen, ist der Lesevorgang derselbe spark.readStream-Code über den Delta-Sharing-Konnektor. Ohne Spark gibt es keinen kontinuierlichen Stream, sodass sie Änderungen nach Versionsbereich abrufen:
Ein nützliches erstes Projekt muss nicht jedes Freigabeszenario lösen. Beginnen Sie mit einer regulären Delta-Tabelle und einem Empfänger.
Bevor Sie den Stream implementieren, beantworten Sie diese Fragen:
Sobald diese Antworten klar sind, validieren Sie den kleinstmöglichen End-to-End-Ablauf: Erstellen Sie die Freigabe, lesen Sie einen initialen Schnappschuss, schreiben Sie eine neue Zeile, aktualisieren Sie eine Zeile, löschen Sie eine Zeile und bestätigen Sie, dass der Empfänger die erwarteten Ergebnisse sieht.
Das ist die praktische Veränderung, die OpenSharing ermöglicht. Anstatt für jeden Kunden einen neuen Transport- und Ingest-Workflow zu erstellen, können Sie einen geregelten Datenaustausch-Vertrag abschließen und jeden Empfänger die Daten über den Pfad konsumieren lassen, der zu seiner Plattform passt.
Neu bei OpenSharing? Beginne mit Was ist OpenSharing? und Freigaben für OpenSharing erstellen und richte dann den minimalen End-to-End-Ablauf von oben für eine Tabelle und einen Empfänger ein.
(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag
Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.