View a markdown version of this page

Überlegungen bei der Verwendung von Null-ETL-Integrationen mit Amazon Redshift - Amazon Redshift
Überlegungen bei der Verwendung des Verlaufsmodus im ZielÜberlegungen, wenn die Null-ETL-Integrationsquelle Aurora oder Amazon RDS istÜberlegungen, wenn die Null-ETL-Integrationsquelle DynamoDB istÜberlegungen, wenn es sich bei der Zero-ETL-Integrationsquelle um Anwendungen wie Salesforce, SAP und Zendesk handelt ServiceNowÜberlegungen bei der Wiederherstellung eines Zero-ETL-IntegrationszielsÜberlegungen zur Größenänderung eines Zero-ETL-Integrationsziels

Amazon Redshift unterstützt die Verwendung von Python-UDFs nach dem 30. Juni 2026 nicht mehr. Wir werden damit beginnen, es schrittweise durchzusetzen. Weitere Informationen zum Ende der Lebensdauer von Python und zu den Migrationsoptionen finden Sie im Blogbeitrag, der am 30. Juni 2025 veröffentlicht wurde.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Überlegungen bei der Verwendung von Null-ETL-Integrationen mit Amazon Redshift

Die folgenden Überlegungen gelten für Null-ETL-Integrationen mit Amazon Redshift.

  • Ihr Ziel-Data-Warehouse von Amazon Redshift muss die folgenden Voraussetzungen erfüllen:

    • Ausführung von Amazon Redshift Serverless oder eines bereitgestellten Clusters eines RG- oder RA3-Knotentyps.

    • Es muss verschlüsselt sein (bei Verwendung eines bereitgestellten Clusters).

    • Die Unterscheidung zwischen Groß- und Kleinschreibung muss aktiviert sein.

  • Wenn Sie eine autorisierte Integrationsquelle für ein Amazon Redshift Data Warehouse löschen, wechseln alle zugehörigen Integrationen in den Status FAILED. Alle zuvor replizierten Daten verbleiben in Ihrer Amazon-Redshift-Datenbank und können abgefragt werden.

  • Die Zieldatenbank ist schreibgeschützt. Sie können in der Zieldatenbank keine Tabellen, Ansichten oder materialisierten Ansichten erstellen. Sie können jedoch materialisierte Ansichten für andere Tabellen im Ziel-Data-Warehouse verwenden.

  • Materialisierte Ansichten werden in datenbankübergreifenden Abfragen unterstützt. Informationen zum Erstellen von materialisierten Ansichten mit Daten, die über Null-ETL-Integrationen repliziert wurden, finden Sie unter Abfragen replizierter Daten mit materialisierten Ansichten.

  • Standardmäßig können Sie im Ziel-Data-Warehouse nur Tabellen mit dem Status Synced abfragen. Um Tabellen mit einem anderen Status abzufragen, legen Sie den Datenbankparameter QUERY_ALL_STATES auf TRUE fest. Weitere Informationen zur Einstellung QUERY_ALL_STATES finden Sie unter CREATE DATABASE und ALTER DATABASE im Amazon-Redshift-Handbuch für Datenbankentwickler. Weitere Informationen zum Status Ihrer Datenbank finden Sie unter SVV_INTEGRATION_TABLE_STATE im Amazon-Redshift-Handbuch für Datenbankentwickler.

  • Amazon Redshift akzeptiert nur UTF-8 Zeichen, sodass die in Ihrer Quelle definierte Sortierung möglicherweise nicht berücksichtigt wird. Die Sortier- und Vergleichsregeln können unterschiedlich sein, was sich letztendlich auf die Abfrageergebnisse auswirken kann.

  • Zero-ETL Integrationen sind auf 50 pro Amazon Redshift Data Warehouse-Ziel begrenzt.

  • Die Tabellen in der Integrationsquelle müssen über einen Primärschlüssel verfügen. Andernfalls können Ihre Tabellen nicht zum Ziel-Data-Warehouse in Amazon Redshift repliziert werden.

    Informationen zum Hinzufügen eines Primärschlüssels zu Amazon Aurora PostgreSQL finden Sie unter Behandeln von Tabellen ohne Primärschlüssel beim Erstellen von Null-ETL-Integrationen für Amazon Aurora PostgreSQL mit Amazon Redshift im AWS -Datenbank-Blog. Informationen zum Hinzufügen eines Primärschlüssels zu Amazon Aurora MySQL oder RSD für MySQL finden Sie unter Behandeln von Tabellen ohne Primärschlüssel beim Erstellen von Null-ETL-Integrationen für Amazon Aurora MySQL oder Amazon RDS für MySQL mit Amazon Redshift im AWS -Datenbank-Blog.

  • Sie können eine Datenfilterung für Null-ETL-Integrationen von Aurora verwenden, um den Umfang der Replikation aus dem Aurora-DB-Quellcluster zum Ziel-Data Warehouse in Amazon Redshift zu definieren. Anstatt alle Daten zum Ziel zu replizieren, können Sie einen oder mehrere Filter definieren, die bestimmte Tabellen selektiv in die Replikation einbeziehen oder von ihr ausschließen. Weitere Informationen finden Sie unter Datenfilterung für Null-ETL-Integrationen von Aurora mit Amazon Redshift im Amazon-Aurora-Benutzerhandbuch.

  • Für Null-ETL-Integrationen von Aurora PostgreSQL mit Amazon Redshift unterstützt Amazon Redshift maximal 100 Datenbanken von Aurora PostgreSQL. Jede Datenbank wird unabhängig von der Quelle zum Ziel repliziert.

  • Zero-ETL Die Integration unterstützt keine Transformationen bei der Replikation der Daten aus Transaktionsdatenspeichern auf Amazon Redshift. Daten werden unverändert aus der Quelldatenbank repliziert. Sie können jedoch Transformationen auf die replizierten Daten in Amazon Redshift anwenden.

  • Zero-ETL Die Integration wird in Amazon Redshift über parallele Verbindungen ausgeführt. Sie wird mit den Anmeldeinformationen des Benutzers ausgeführt, der die Datenbank aus der Integration erstellt hat.

  • Sie können REFRESH_INTERVAL für eine Null-ETL-Integration festlegen, um die Häufigkeit der Datenreplikation zu Amazon Redshift zu steuern. Weitere Informationen finden Sie unter CREATE DATABASE und ALTER DATABASE im Amazon-Redshift-Handbuch für Datenbankentwickler.

  • Nachdem Sie eine Amazon-Redshift-Datenbank aus einer Null-ETL-Integration mit Amazon DynamoDB erstellt haben, sollte sich der Datenbankstatus von Creating in Active ändern. Dies startet die Replikation der Daten in den DynamoDB-Quelltabellen zu den Redshift-Zieltabellen, die unter dem öffentlichen Schema der Zieldatenbank (ddb_rs_customerprofiles_zetl_db) erstellt wurden.

Überlegungen bei der Verwendung des Verlaufsmodus im Ziel

Die folgenden Überlegungen gelten bei der Verwendung des Verlaufsmodus in der Zieldatenbank. Weitere Informationen finden Sie unter Verlaufsmodus.

  • Wenn Sie eine Tabelle in einer Quelle entfernen, wird die Tabelle im Ziel nicht entfernt, sondern in den Status DroppedSource geändert. Sie können die Tabelle in der Amazon-Redshift-Datenbank entfernen oder umbenennen.

  • Wenn Sie eine Tabelle in einer Quelle kürzen, werden Löschungen in der Zieltabelle ausgeführt. Wenn beispielsweise alle Datensätze in der Quelle gekürzt sind, werden die entsprechenden Datensätze in der Zielspalte _record_is_active in false geändert.

  • Wenn Sie „TRUNCATE“ für das Tabellen-SQL in der Zieltabelle ausführen, werden aktive Verlaufszeilen mit einem entsprechenden Zeitstempel als inaktiv markiert.

  • Wenn eine Zeile in einer Tabelle auf inaktiv festgelegt ist, kann sie nach einer kurzen Verzögerung (etwa 10 Minuten) gelöscht werden. Um inaktive Zeilen zu löschen, stellen Sie mit dem Query Editor v2 oder einem anderen SQL-Client eine Verbindung zu Ihrer Null-ETL-Datenbank her.

  • Sie können nur inaktive Zeilen aus einer Tabelle löschen, wenn der Verlaufsmodus aktiviert ist. Ein SQL-Befehl, der dem folgenden ähnlich ist, löscht beispielsweise nur inaktive Zeilen.

    delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56'

    Dies entspricht einem SQL-Befehl wie dem folgenden.

    delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56' and _record_is_active = False

  • Wenn der Verlaufsmodus für eine Tabelle deaktiviert wird, werden alle historischen Daten zu einer Tabelle mit dem Namen <schema>.<table-name>_historical_<timestamp> gespeichert, während die ursprüngliche Tabelle mit dem Namen <schema>.<table-name> aktualisiert wird.

  • Wenn eine Tabelle mit aktiviertem Verlaufsmodus mithilfe eines Tabellenfilters von der Replikation ausgeschlossen wird, werden alle Zeilen als inaktiv festgelegt und der Status wird in DroppedSource geändert. Weitere Informationen zu Tabellenfiltern finden Sie unter Datenfilterung für Null-ETL-Integrationen von Aurora mit Amazon Redshift im Amazon-Aurora-Benutzerhandbuch.

  • Der Verlaufsmodus kann nur in true oder false für Tabellen im Status Synced geändert werden.

  • Materialisierte Ansichten für Tabellen mit aktiviertem Verlaufsmodus werden als vollständige Neuberechnung erstellt.

Überlegungen, wenn die Null-ETL-Integrationsquelle Aurora oder Amazon RDS ist

Die folgenden Überlegungen gelten für Null-ETL-Integrationen von Aurora und Amazon RDS mit Amazon Redshift.

Informationen zu Aurora-Quellen finden Sie auch unter Einschränkungen im Amazon-Aurora-Benutzerhandbuch.

Informationen zu Amazon-RDS-Quellen finden Sie auch unter Einschränkungen im Amazon-RDS-Benutzerhandbuch.

Überlegungen, wenn die Null-ETL-Integrationsquelle DynamoDB ist

Die folgenden Überlegungen gelten für Null-ETL-Integrationen in DynamoDB mit Amazon Redshift.

  • Tabellennamen aus DynamoDB mit mehr als 127 Zeichen werden nicht unterstützt.

  • Die Daten aus einer Null-ETL-Integration für DynamoDB werden einer Spalte mit dem Datentyp SUPER in Amazon Redshift zugeordnet.

  • Spaltennamen für den Partitions- oder Sortierschlüssel mit mehr als 127 Zeichen werden nicht unterstützt.

  • Eine Null-ETL-Integration für DynamoDB kann jeweils nur einer Amazon Redshift-Datenbank zugeordnet werden.

  • Die maximale Präzision und Skalierung für Partitions- und Sortierschlüssel beträgt (38,18). Numerische Datentypen in DynamoDB unterstützen eine maximale Präzision von bis zu 38. Amazon Redshift unterstützt auch eine maximale Genauigkeit von 38, aber die Standard-Dezimalzahl bei precision/scale Amazon Redshift ist (38,10). Das bedeutet, dass skalierte Werte möglicherweise gekürzt werden.

  • Für eine erfolgreiche Null-ETL-Integration darf ein einzelnes Attribut (bestehend aus Name+Wert) in einem DynamoDB-Element nicht größer als 64 KB sein.

  • Bei Aktivierung exportiert die Null-ETL-Integration die vollständige DynamoDB-Tabelle, um die Amazon-Redshift-Datenbank zu füllen. Die für diesen ersten Vorgang benötigte Zeit hängt von der DynamoDB-Tabellengröße ab. Die Null-ETL-Integration repliziert anschließend inkrementell Updates von DynamoDB zu Amazon Redshift mithilfe inkrementeller DynamoDB-Exporte. Das bedeutet, dass die replizierten DynamoDB-Daten in Amazon Redshift automatisch auf dem aktuellen Stand gehalten werden.

    Derzeit beträgt die Mindestlatenz für die Null-ETL-Integration für DynamoDB 15 Minuten. Sie können sie weiter erhöhen, indem Sie für eine Null-ETL-Integration einen Wert ungleich null für REFRESH_INTERVAL festlegen. Weitere Informationen finden Sie unter CREATE DATABASE und ALTER DATABASE im Amazon-Redshift-Handbuch für Datenbankentwickler.

Informationen zu Amazon-DynamoDB-Quellen finden Sie auch unter Voraussetzungen und Einschränkungen im Amazon-DynamoDB-Entwicklerhandbuch.

Überlegungen, wenn es sich bei der Zero-ETL-Integrationsquelle um Anwendungen wie Salesforce, SAP und Zendesk handelt ServiceNow

Die folgenden Überlegungen gelten für Quellanwendungen wie Salesforce ServiceNow, SAP und Zendesk mit Amazon Redshift.

  • Tabellen- und Spaltennamen aus Anwendungsquellen mit mehr als 127 Zeichen werden nicht unterstützt.

  • Die maximale Länge des Amazon-Redshift-Datentyps VARCHAR beträgt 65.535 Bytes. Wenn der Inhalt aus der Quelle dieses Limit überschreitet, wird die Replikation nicht fortgesetzt und die Tabelle wird auf den Status „Fehlgeschlagen“ festgelegt. Sie können den Datenbankparameter TRUNCATECOLUMNS auf TRUE festlegen, um die Länge des Inhalts an die Spalte anzupassen. Informationen zur Einstellung TRUNCATECOLUMNS finden Sie unter CREATE DATABASE und ALTER DATABASE im Amazon-Redshift-Handbuch für Datenbankentwickler.

    Weitere Informationen zu den Datentypunterschieden zwischen Anwendungsquellen mit Zero-ETL-Integration und Amazon Redshift-Datenbanken finden Sie unter Zero-ETL Integrationen im Entwicklerhandbuch. AWS Glue

  • Die Mindestlatenz für eine Null-ETL-Integration mit Anwendungen beträgt 1 Stunde. Sie können sie weiter erhöhen, indem Sie für eine Null-ETL-Integration einen Wert ungleich null für REFRESH_INTERVAL festlegen. Weitere Informationen finden Sie unter CREATE DATABASE und ALTER DATABASE im Amazon-Redshift-Handbuch für Datenbankentwickler.

Quellen für Zero-ETL-Integrationen mit Anwendungen finden Sie auch unter Integrationen im Entwicklerhandbuch. Zero-ETL AWS Glue

Überlegungen bei der Wiederherstellung eines Zero-ETL-Integrationsziels

Wenn Sie einen Amazon Redshift Serverless-Namespace von einem Snapshot oder Recovery-Punkt in demselben serverlosen Namespace wiederherstellen, werden Zero-ETL-Integrationen, die dem Namespace zugeordnet sind, automatisch beibehalten. Nach der Wiederherstellung wird eine vollständige Neusynchronisierung eingeleitet, um sicherzustellen, dass die Daten in der Amazon Redshift-Zieldatenbank mit der Quelle konsistent sind. Beachten Sie die folgenden Überlegungen:

  • Bei der Wiederherstellung eines Snapshots in einem anderen Namespace werden die Integrationen nicht beibehalten.

  • Nach der Wiederherstellung führt Amazon Redshift eine vollständige Neusynchronisierung für alle verwalteten Zero-ETL-Integrationen durch. Während der Neusynchronisierung kann die Leistung bei der Datenaufnahme vorübergehend reduziert werden.

  • Wenn Sie den Verlaufsmodus für die Zieldatenbank verwenden, werden die Aufzeichnungsversionen vom Zeitpunkt der Erstellung des Snapshots bis zum Abschluss der vollständigen Neusynchronisierung nicht erfasst. Nach der Resynchronisierung nimmt der Verlaufsmodus den normalen Betrieb wieder auf. Dieses Verhalten ist dasselbe wie bei jeder anderen vollständigen Resynchronisierung. Weitere Informationen finden Sie unter Verlaufsmodus.

  • Wenn nach der Erstellung des Snapshots eine Zero-ETL-Integration erstellt wurde, geht die Integration nach der Wiederherstellung in den NEEDS_ATTENTION Zustand über, da die entsprechende Datenbank im Snapshot nicht vorhanden ist. Um dieses Problem zu beheben, können Sie die Wiederherstellung anhand eines neueren Snapshots durchführen, der die Integration enthält, oder die Integration löschen.

  • Wenn eine Zero-ETL-Integration nach der Erstellung des Snapshots gelöscht wurde, wird die Integration nicht wiederhergestellt. Die Datenbank aus dem Snapshot bleibt erhalten und kann gelöscht werden.

  • Wenn Filter auf Tabellenebene nach der Erstellung des Snapshots geändert wurden, verwendet das wiederhergestellte Ziel die aktuellen Filter aus der Integration, nicht die Filter zum Zeitpunkt des Snapshots.

  • Um die Wartung von Integrationen während einer Wiederherstellung zu deaktivieren, deaktivieren Sie das Kontrollkästchen Integrationen verwalten auf der Wiederherstellungsseite in der oder, falls Sie den verwenden, legen Sie den --no-maintain-integration Parameter fest AWS-Managementkonsole, wenn Sie den API-Vorgang „Restore-From-Snapshot“ oder „https://docs.aws.amazon.com/redshift-serverless/latest/APIReference/API_RestoreFromSnapshot.htmlRestore-From-Recovery-Point“ aufrufen. AWS CLIhttps://docs.aws.amazon.com/redshift-serverless/latest/APIReference/API_RestoreFromRecoveryPoint.html Wenn Sie sich abmelden, gehen Integrationen in den Zustand nach der Wiederherstellung über. FAILED Sie können die Integrationen löschen und neu erstellen.

  • Diese Funktion gilt nur für Amazon Redshift Serverless, wenn sie im gleichen serverlosen Namespace wiederhergestellt wird. Bei Snapshot-Wiederherstellungen auf bereitgestellten Clustern werden keine Zero-ETL-Integrationen beibehalten.

Überlegungen zur Größenänderung eines Zero-ETL-Integrationsziels

Wenn Sie die Größe eines von Amazon Redshift bereitgestellten Clusters ändern, der das Ziel einer Zero-ETL-Integration ist, kann die Größenänderung dazu führen, dass die Integrationstabellen neu synchronisiert werden. Ob eine Neusynchronisierung stattfindet, hängt von der Art der Größenänderung ab:

  • Eine elastische Größenänderung, bei der nur die Anzahl der Knoten geändert wird (eine direkte Größenänderung), wirkt sich nicht auf Zero-ETL-Integrationen aus. Die Tabellen bleiben synchronisiert.

  • Eine elastische Größenänderung, die den Knotentyp ändert, führt dazu, dass alle Tabellen in Zero-ETL-Integrationen auf dem Cluster neu synchronisiert werden. Jede klassische Größenänderung löst auch eine Neusynchronisierung aus. Dies liegt daran, dass diese Operationen zur Größenänderung vorübergehend den Verteilungsstil der Tabellen ändern, während der Dienst die Daten auf die neue Clusterkonfiguration umverteilt. Weitere Informationen finden Sie unter Ändern der Größe eines Clusters.

Die folgenden Überlegungen gelten, wenn eine Größenänderung eine Neusynchronisierung auslöst:

  • Die Integration bleibt aktiv und die Neusynchronisierung beginnt automatisch, nachdem die Größenänderung abgeschlossen ist. Sie müssen selbst keine Aktion durchführen.

  • Während eine Tabelle neu synchronisiert wird, können Sie sie in Amazon Redshift nicht abfragen. Damit Tabellen während der Neusynchronisierung abfragbar bleiben, setzen Sie den QUERY_ALL_STATES Parameter in der Zieldatenbank TRUE auf, bevor Sie mit der Größenänderung beginnen. Bei der Neusynchronisierung zurückgegebene Daten sind möglicherweise veraltet, bis die Neusynchronisierung abgeschlossen ist. Weitere Informationen finden Sie unter CREATE DATABASE und ALTER DATABASE im Amazon-Redshift-Handbuch für Datenbankentwickler.

  • Die Neusynchronisierung kann je nach Größe der Quelldatenbank 20—25 Minuten oder länger dauern.

  • Sie können den Status der Integrationstabellen mithilfe der https://docs.aws.amazon.com/redshift/latest/dg/r_SVV_INTEGRATION_TABLE_STATE.html SVV_INTEGRATION_TABLE_STATE-Systemansicht überwachen. In den Tabellen wird der ResyncInitiated Status ResyncRequired OR angezeigt, bis die Neusynchronisierung abgeschlossen ist und sie zu dem Status zurückkehren. Synced