Konzepte für Datenbank-Konnektoren¶

Konnektorkomponenten¶

Die Snowflake Database Connectors bestehen aus einer Snowflake Native App, die vom Marketplace in Ihr Snowflake-Konto installiert wird, und einer Agenten-Anwendung, die innerhalb Ihrer Infrastruktur läuft, entweder lokal oder in der Cloud.

• Agenten stellen eine direkte Verbindung zu Ihren Quelldatenbanken her, verfolgen Aktualisierungen der Tabellen, die Sie zur Replikation ausgewählt haben, und laden Änderungen in Ihr Snowflake-Konto hoch. Agenten erfordert eine einmalige Konfiguration für die Verbindung mit Snowflake und den Datenquellen und danach nur noch ein Upgrade, wenn neue Versionen veröffentlicht werden. Darüber hinaus werden sie vollständig über die Native App gesteuert und konfiguriert.

• Native Apps steuern den Prozess der Replikation von Daten. Sie weisen die Agenten an, welche Tabellen zu verfolgen sind, empfangen die Änderungen und führen sie in Ihren Zieldatenbanken zusammen. Die meiste Interaktion werden Sie mit der Native App haben. Sie wird automatisch aktualisiert, sobald eine neue Version verfügbar ist.

Dieses Modell, bei dem ein Agent lokal läuft, ist notwendig, damit der Konnektor sicher auf Quelldatenbanken in Netzwerken zugreifen kann, die für externe Verbindungen gesperrt sind.

Eine Agenten-Instanz stellt immer eine Verbindung zu einer einzigen Native App-Instanz her, und eine Native App arbeitet immer mit einem Agenten zusammen. Wenn Sie mehrere Agenten-Instanzen betreiben müssen, z. B. zur Replikation von Quelldatenbanken aus nicht verbundenen Netzwerken, müssen Sie mehrere Instanzen der Native App installieren und konfigurieren. Wenn Sie Hilfe benötigen, wenden Sie sich an den Snowflake-Support.

Intern stützt sich der Konnektor auf einen asynchronen, ereignisgesteuerten Austausch von Befehlen. Die Native App muss auch mit dem Agenten kommunizieren und sich mit ihm abstimmen. Aus diesem Grund können Sie eine Verzögerung zwischen der Ausführung eines Befehls und der Anzeige der Auswirkungen dieses Befehls feststellen.

Datenquellen, Tabellen, Journale und Ziele¶

Wenn wir über den Datenfluss durch den Konnektor sprechen, unterscheiden wir die folgenden Stagingbereiche:

Datenquelle

Die Datenbank, die die Tabellen enthält, die der Konnektor repliziert. Je nach Datenbank-Engine kann dies entweder der gesamte Datenbank-Server oder eine der Datenbanken sein, die innerhalb des Servers gehostet werden.

Eine einzelne Instanz des Konnektors kann von mehreren Datenquellen replizieren, solange der Agent eine direkte Verbindung zu allen Quellen herstellen kann.

Quelltabelle

Eine bestimmte Tabelle in der Quelldatenbank, die vom Konnektor auf Änderungen überwacht wird, die dann in Snowflake repliziert werden. Jede Datenquelle kann mehrere Quelltabellen enthalten, die gleichzeitig von der gleichen Instanz des Konnektors repliziert werden.

Das unmittelbar übergeordnete Objekt der Quelltabelle in der Datenquelle wird zum Schema der entsprechenden Zieltabelle in Snowflake.

Journal

Eine Snowflake-Tabelle, die im Besitz der Native App des Konnektors ist und von dieser verwaltet wird. Sie empfängt und speichert alle Änderungen, die an der Quelltabelle vorgenommen werden: Einfügungen, Aktualisierungen und Löschungen. Sie ist de facto ein Änderungsprotokoll der Daten der Quelltabelle und spiegelt in ihrer Struktur wider, wie Datenbank-Engines normalerweise Änderungen an ihre Replikate weitergeben.

Jede Quelltabelle hat eine eigene Journaltabelle.

Zieltabelle

Die Snowflake-Tabelle in Ihrem Konto, in die der Konnektor die Daten repliziert. Für jede Quelltabelle gibt es eine eigene Zieltabelle. Die Spaltennamen entsprechen den Namen in der Quelltabelle, und ihre Typen sind die entsprechenden Snowflake-Typen für die Quellspalten.

Jede Zieltabelle enthält außerdem Spalten mit Informationen zur Replikation: _SNOWFLAKE_INSERTED_AT, _SNOWFLAKE_UPDATED_AT, _SNOWFLAKE_DELETED, mit den Zeitstempeln der ursprünglichen Einfügung, der letzten Aktualisierung bzw. der Löschung der jeweiligen Zeile.

In der Zieltabelle ist die Änderungsverfolgung bereits aktiviert, damit Sie Streams erstellen können. Die Native App des Konnektors behält den OWNERSHIP-Zugriff auf die Tabelle.

Snapshot Load und inkrementelles Laden¶

Die Replikation von Daten aus einer neu hinzugefügten Tabelle beginnt mit einem Snapshot Load. Der Agent führt eine einzige SELECT <Spalten>-Anweisung für die Quelltabelle aus, streamt dann alle Datensätze in eine Zwischentabelle in Snowflake und kopiert sie anschließend in die Zieltabelle. Diese Operation kann in der Quelldatenbank sehr ressourcenintensiv sein und dauert bei großen Tabellen in der Regel sehr lange. Möglicherweise müssen Sie warten, bis Sie die ersten Datensätze in der Zieltabelle sehen.

Ein Snapshot Load kann in den folgenden Szenarien auch wiederholt werden, wobei zuvor replizierte Daten ersetzt werden, um die Quelltabelle mit dem Ziel zu synchronisieren:

• Wenn die Replikation der Tabelle aufgrund von nicht unterstützten Datentypen, Größen, Fehlern im Konnektor oder anderen Problemen dauerhaft fehlschlägt.

• Wenn die Replikation angehalten wurde und das Änderungsprotokoll der Quelldatenbank nach der Wiederaufnahme keine Einträge mehr enthält seit der letzten Replikation der Tabelle.

Nachdem der erste Snapshot abgeschlossen ist, wird die Replikation der Tabelle auf Inkrementelles Laden umgestellt. Der Agent verfolgt das Änderungsprotokoll der Quelldatenbank und überträgt diese Änderungen in die entsprechende Journaltabelle, von wo aus sie später in die Zieltabelle zusammengeführt werden. Dieser Zyklus aus Lesen, Streamen und Zusammenführen kann entweder kontinuierlich oder nach einem Zeitplan durchgeführt werden. Weitere Informationen zu diesen Modi finden Sie unter Nächste Schritte und Nächste Schritte.

Lebenszyklus der Tabellenreplikation¶

Der Replikationszyklus einer neu hinzugefügten Quelltabelle beginnt mit Schema-Introspektion. Hier erkennt der Konnektor die Spalten in der Quelltabelle, ihre Namen und Typen und validiert sie dann anhand der Beschränkungen von Snowflake und des Konnektors. Wenn die Validierung fehlschlägt, schlägt dieser Stagingbereich fehl, und der Zyklus ist abgeschlossen. Nach erfolgreichem Abschluss der Schema-Introspektion erstellt der Konnektor eine leere Zieltabelle.

Der zweite Stagingbereich ist Snapshot Load, bei dem der Konnektor alle in der Quelltabelle verfügbaren Daten in die Zieltabelle kopiert. Wenn dieser Stagingbereich scheitert, wird der Zyklus ebenfalls beendet, und es werden keine weiteren Daten repliziert. Nach erfolgreichem Abschluss sind alle Daten aus der Quelltabelle in der Zieltabelle verfügbar.

Schließlich geht die Tabelle über zu Inkrementelles Laden, wo der Konnektor die Änderungen in der Quelltabelle verfolgt und in die Zieltabelle kopiert. Dies geschieht so lange, bis die Tabelle aus der Replikation entfernt wird. Bei einem Fehler in diesem Stagingbereich wird die Replikation der Quelltabelle dauerhaft gestoppt, bis das Problem behoben ist.

Anweisungen, wie Sie feststellen können, in welcher Replikationsphase sich Ihre Tabellen gerade befinden, finden Sie unter Überwachen des Snowflake Connector for MySQL und Überwachen des Snowflake Connector for PostgreSQL.

Datenfluss von der Quelle zum Ziel¶

Der Konnektor verschiebt Daten unterschiedlich von der Quelltabelle in die Zieltabelle, je nachdem, ob er einen Snapshot oder ein inkrementelles Laden durchführt. Weitere Informationen dazu finden Sie unter Snapshot Load und inkrementelles Laden.

Kontinuierliche vs. geplante Replikation¶

Der Standardmodus für die Replikation von neu hinzugefügten Datenquellen ist Kontinuierlich. In diesem Modus zielt der Konnektor darauf ab, Datenänderungen so schnell wie möglich zu replizieren. Dies ist der optimale Modus für Datenquellen, die sich häufig ändern, und wenn die Daten in Snowflake mit geringen Latenzzeiten verfügbar sein sollen.

Sie können die Datenquelle so ändern, dass die Replikation im Modus Geplant erfolgt, bei dem die Daten nach einem festen Zeitplan in Batches von der Quelle in die Zieltabellen kopiert werden. Dies ist der optimale Modus für Datenquellen, die sich nur selten ändern, oder wenn Sie den Credit-Verbrauch reduzieren möchten und nicht verlangen, dass die Daten in Snowflake mit geringen Latenzen verfügbar sind.

Bei der kontinuierlichen Replikation wird das inkrementelle Laden niemals als „abgeschlossen“ gemeldet. Im geplanten Modus wird das inkrementelle Laden als „abgeschlossen“ gemeldet, nachdem alle Datenbatches in die Zieltabelle zusammengeführt wurden. Ein „Batch“ im geplanten Modus besteht aus allen Änderungsprotokolleinträgen zwischen der letzten geplanten Ausführung und dem Zeitpunkt, an dem die nächste geplante Ausführung gestartet wird.

Warehouse-Typen¶

Konnektoren benötigen zwei Warehouses für den Betrieb:

• Ein Operative Warehouse, das manchmal auch als Ops-Warehouse bezeichnet wird, dient zur Ausführung der Befehls- und Steuerungsoperationen des Konnektors. Dieses Warehouse wird automatisch vom Einrichtungsassistenten erstellt, und seine optimale Größe ist XS.

• Ein Compute-Warehouse wird verwendet, um die Zusammenführungsaufgaben auszuführen, die Daten aus Journalen in Zieltabellen verschieben. Dieses Warehouse kann mithilfe des Assistenten oder manuell erstellt werden. Seine optimale Größe und Art hängen vom Umfang Ihrer Replikation ab.

Die obige Unterscheidung ist erforderlich, um sicherzustellen, dass operative Abfragen rechtzeitig ausgeführt werden, ohne dass sie zusammen mit den Abfragen, die große Datenmengen bewegen, in eine Warteschlange gestellt werden. Das bedeutet auch, dass das Operative Warehouse nicht zwischen Konnektor-Instanzen wiederverwendet werden kann und nicht mit anderen Workloads im Konto gemeinsam genutzt werden sollte.

Das Compute-Warehouse wiederum kann mit anderen Instanzen des Konnektors und Arbeitslasten gemeinsam genutzt werden. Denken Sie jedoch daran, dass die gemeinsame Nutzung dieses Warehouses zu Verzögerungen bei der Anzeige der Daten in Ihren Zieltabellen führen kann.