Datenmigration, ETL und Last für Netezza-Migrationen

Dieser Artikel ist Teil 2 einer siebenteiligen Reihe, die Anleitungen zum Migrieren von Netezza zu Azure Synapse Analytics enthält. Schwerpunktmäßig behandelt dieses Tutorial bewährte Methoden für ETL-Prozesse und Lademigration.

Überlegungen zur Datenmigration

Erste Entscheidungen für die Datenmigration von Netezza

Beim Migrieren eines Netezza-Data Warehouses müssen Sie einige grundlegende datenbezogene Fragen stellen. Beispiel:

• Sollten nicht verwendete Tabellenstrukturen migriert werden?

• Was ist der beste Migrationsansatz, um Risiken und Auswirkungen der Benutzer zu minimieren?

• Beim Migrieren von Data Marts: Bleiben Sie physisch oder gehen Sie virtuell?

In den nächsten Abschnitten werden diese Punkte im Kontext der Migration von Netezza erläutert.

Nicht verwendete Tabellen migrieren?

Es ist sinnvoll, nur Tabellen zu migrieren, die im vorhandenen System verwendet werden. Tabellen, die nicht aktiv sind, können archiviert anstatt migriert werden, sodass die Daten bei Bedarf in der Zukunft verfügbar sind. Es ist am besten, Systemmetadaten und Protokolldateien anstelle von Dokumentationen zu verwenden, um zu bestimmen, welche Tabellen verwendet werden, da die Dokumentation veraltet sein kann.

Wenn diese Option aktiviert ist, enthalten Netezza-Abfrageverlaufstabellen Informationen, die bestimmen können, wann auf eine bestimmte Tabelle zuletzt zugegriffen wurde – was wiederum verwendet werden kann, um zu entscheiden, ob eine Tabelle ein Kandidat für die Migration ist.

Hier ist eine Beispielabfrage, die nach der Verwendung einer bestimmten Tabelle innerhalb eines bestimmten Zeitfensters sucht:

SELECT FORMAT_TABLE_ACCESS (usage),
  hq.submittime
FROM "$v_hist_queries" hq
  INNER JOIN "$hist_table_access_3" hta USING
(NPSID, NPSINSTANCEID, OPID, SESSIONID)
WHERE hq.dbname = 'PROD'
AND hta.schemaname = 'ADMIN'
AND hta.tablename = 'TEST_1'
AND hq.SUBMITTIME > '01-01-2015'
AND hq.SUBMITTIME <= '08-06-2015'
AND
(
  instr(FORMAT_TABLE_ACCESS(usage),'ins') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'upd') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
)
AND status=0;

| FORMAT_TABLE_ACCESS | SUBMITTIME
----------------------+---------------------------
ins                   | 2015-06-16 18:32:25.728042
ins                   | 2015-06-16 17:46:14.337105
ins                   | 2015-06-16 17:47:14.430995
(3 rows)

Diese Abfrage verwendet die Hilfsfunktion FORMAT_TABLE_ACCESS und die Ziffer am Ende der $v_hist_table_access_3 Ansicht, um der installierten Abfrageverlaufsversion zu entsprechen.

Was ist der beste Migrationsansatz, um Risiken und Auswirkungen auf Benutzer zu minimieren?

Diese Frage kommt häufig auf, da Unternehmen möglicherweise die Auswirkungen von Änderungen auf das Data Warehouse-Datenmodell verringern möchten, um die Flexibilität zu verbessern. Unternehmen sehen oft die Möglichkeit, ihre Daten während einer ETL-Migration weiter zu modernisieren oder zu transformieren. Dieser Ansatz birgt ein höheres Risiko, da er mehrere Faktoren gleichzeitig ändert, wodurch es schwierig ist, die Ergebnisse des alten Systems mit dem neuen zu vergleichen. Änderungen am Datenmodell können sich hier auch auf eingehende oder ausgehende ETL-Aufträge zu anderen Systemen auswirken. Aufgrund dieses Risikos ist es besser, das Gesamtdesign nach der Migration des Data Warehouses zu überarbeiten.

Selbst wenn ein Datenmodell im Rahmen der allgemeinen Migration absichtlich geändert wird, empfiehlt es sich, das vorhandene Modell as-is zu Azure Synapse zu migrieren, anstatt ein erneutes Engineering auf der neuen Plattform durchführen zu müssen. Dieser Ansatz minimiert die Auswirkungen auf vorhandene Produktionssysteme und profitiert dabei von der Leistung und der flexiblen Skalierbarkeit der Azure-Plattform für einmalige Neuentwicklungsaufgaben.

Bei der Migration von Netezza eignet sich häufig das vorhandene Datenmodell bereits für as-is Migration zu Azure Synapse.

Migration von Data Marts: Sollen sie physisch bleiben oder virtuell werden?

In älteren Netezza Data Warehouse-Umgebungen ist es üblich, mehrere Data Marts zu erstellen, die strukturiert sind, um eine gute Leistung für Ad-hoc-Self-Service-Abfragen und Berichte für eine bestimmte Abteilung oder Geschäftsfunktion innerhalb einer Organisation bereitzustellen. Ein Data Mart besteht in der Regel aus einer Teilmenge des Data Warehouses und enthält aggregierte Versionen der Daten in einem Formular, mit dem Benutzer diese Daten mit schnellen Reaktionszeiten über benutzerfreundliche Abfragetools wie Microsoft Power BI, Tableau oder MicroStrategy auf einfache Weise abfragen können. Dieses Formular ist in der Regel ein dimensionales Datenmodell. Eine Verwendung von Data Marts besteht darin, Daten in einer nutzbaren Form bereitzustellen, auch wenn das zugrunde liegende Warehouse-Datenmodell anders ist, wie z. B. ein Data Vault.

Sie können separate Data Marts für einzelne Geschäftseinheiten innerhalb einer Organisation verwenden, um robuste Datensicherheitsregelungen zu implementieren, indem Sie benutzern nur den Zugriff auf bestimmte Datenmärchen ermöglichen, die für sie relevant sind, und das Entfernen, Verschleiern oder Anonymisieren vertraulicher Daten.

Wenn diese Data Marts als physische Tabellen implementiert werden, benötigen sie zusätzliche Speicherressourcen, um sie zu speichern, und zusätzliche Verarbeitung, um sie regelmäßig zu erstellen und zu aktualisieren. Außerdem sind die Daten im Mart nur so aktuell wie der letzte Aktualisierungsvorgang, und dies kann für stark veränderliche Datendashboards ungeeignet sein.

Mit der Einführung relativ kostengünstiger skalierbarer MPP-Architekturen wie Azure Synapse und der inhärenten Leistungsmerkmale solcher Architekturen kann es sein, dass Sie Data Mart-Funktionen bereitstellen können, ohne den Mart als eine Reihe physischer Tabellen instanziieren zu müssen. Dies wird erreicht, indem die Data Marts über SQL-Ansichten auf das Hauptdatenlager oder über eine Virtualisierungsebene mithilfe von Features wie Ansichten in Azure oder den Visualisierungsprodukten von Microsoft-Partnern effektiv virtualisiert werden. Dieser Ansatz vereinfacht oder beseitigt die Notwendigkeit zusätzlicher Speicher- und Aggregationsverarbeitung und reduziert die Gesamtanzahl der Datenbankobjekte, die migriert werden müssen.

Es gibt einen weiteren potenziellen Vorteil für diesen Ansatz. Durch die Implementierung der Aggregations- und Verknüpfungslogik in einer Virtualisierungsebene und durch die Darstellung externer Berichterstellungstools über eine virtualisierte Ansicht wird die zum Erstellen dieser Ansichten erforderliche Verarbeitung in das Data Warehouse "gedrückt", was im Allgemeinen der beste Ort zum Ausführen von Verknüpfungen, Aggregationen und anderen verwandten Vorgängen auf großen Datenvolumes ist.

Die wichtigsten Treiber für die Auswahl einer virtuellen Data Mart-Implementierung über einen physischen Data Mart sind:

• Mehr Flexibilität: Ein virtueller Data Mart ist einfacher zu ändern als physische Tabellen und die zugehörigen ETL-Prozesse.

• Geringere Gesamtbetriebskosten: Eine virtualisierte Implementierung erfordert weniger Datenspeicher und Kopien von Daten.

• Eliminierung von ETL-Aufträgen zum Migrieren und Vereinfachen der Data Warehouse-Architektur in einer virtualisierten Umgebung.

• Leistung: Obwohl physische Data Marts historisch leistungsfähiger waren, implementieren Virtualisierungsprodukte jetzt intelligente Caching-Techniken, um dies zu verringern.

Datenmigration von Netezza

Grundlegendes zu Ihren Daten

Ein Teil der Migrationsplanung ist das Verständnis für die Menge der Daten, die migriert werden müssen, da sich dies auf Entscheidungen über den Migrationsansatz auswirken kann. Verwenden Sie Systemmetadaten, um den physischen Speicherplatz zu bestimmen, der von den "Rohdaten" innerhalb der zu migrierenden Tabellen belegt wird. In diesem Zusammenhang bedeutet "Rohdaten" den von den Datenzeilen in einer Tabelle verwendeten Speicherplatz, mit Ausnahme von Overheads wie Indizes und Komprimierung. Dies gilt insbesondere für die größten Faktentabellen, da diese in der Regel mehr als 95% der Daten umfassen.

Sie können eine genaue Zahl für die Datenmenge abrufen, die für eine bestimmte Tabelle migriert werden soll, indem Sie eine repräsentative Stichprobe der Daten ( z. B. eine Million Zeilen ) in eine nicht komprimierte, durch Trennzeichen getrennte flache ASCII-Datendatei extrahieren. Verwenden Sie dann die Größe dieser Datei, um eine durchschnittliche Rohdatengröße pro Zeile dieser Tabelle abzurufen. Multiplizieren Sie schließlich diese durchschnittliche Größe mit der Gesamtzahl der Zeilen in der vollständigen Tabelle, um eine unformatierte Datengröße für die Tabelle zu erhalten. Verwenden Sie diese Rohdatengröße in Ihrer Planung.

Netezza-Datentypzuordnung

Die meisten Netezza-Datentypen verfügen über eine direkte Entsprechung in Azure Synapse. Die folgende Tabelle zeigt diese Datentypen zusammen mit dem empfohlenen Ansatz für die Zuordnung.

Verwenden Sie die Metadaten aus den Netezza-Katalogtabellen, um zu bestimmen, ob eines dieser Datentypen migriert werden muss, und lassen Sie dies in Ihrem Migrationsplan zu. Die wichtigen Metadatenansichten in Netezza für diesen Abfragetyp sind:

• _V_USER: Die Benutzeransicht gibt Informationen über die Benutzer im Netezza-System.

• _V_TABLE: Die Tabellenansicht enthält die Liste der Tabellen, die im Netezza-Leistungssystem erstellt wurden.

• _V_RELATION_COLUMN: Die Systemkatalogansicht für Relationenspalten enthält die Spalten, die in einer Tabelle verfügbar sind.

• _V_OBJECTS: Die Objektansicht listet die verschiedenen Objekte wie Tabellen, Ansicht, Funktionen usw. auf, die in Netezza verfügbar sind.

In dieser Netezza SQL-Abfrage werden beispielsweise Spalten und Spaltentypen angezeigt:

SELECT
tablename,
  attname AS COL_NAME,
  b.FORMAT_TYPE AS COL_TYPE,
  attnum AS COL_NUM
FROM _v_table a
  JOIN _v_relation_column b
  ON a.objid = b.objid
WHERE a.tablename = 'ATT_TEST'
AND a.schema = 'ADMIN'
ORDER BY attnum;

TABLENAME | COL_NAME    | COL_TYPE             | COL_NUM
----------+-------------+----------------------+--------
ATT_TEST  | COL_INT     | INTEGER              | 1
ATT_TEST  | COL_NUMERIC | NUMERIC(10,2)        | 2
ATT_TEST  | COL_VARCHAR | CHARACTER VARYING(5) | 3
ATT_TEST  | COL_DATE    | DATE                 | 4
(4 rows)

Die Abfrage kann geändert werden, um alle Tabellen nach allen Vorkommen nicht unterstützter Datentypen zu durchsuchen.

Azure Data Factory kann verwendet werden, um Daten aus einer älteren Netezza-Umgebung zu verschieben. Weitere Informationen finden Sie unter IBM Netezza Connector.

Drittanbieter bieten Tools und Dienste zum Automatisieren der Migration, einschließlich der Zuordnung von Datentypen, wie zuvor beschrieben. Darüber hinaus können ETL-Tools von Drittanbietern wie Informatica oder Talend, die bereits in der Netezza-Umgebung verwendet werden, alle erforderlichen Datentransformationen implementieren. Im nächsten Abschnitt wird die Migration vorhandener ETL-Prozesse von Drittanbietern untersucht.

Überlegungen zur ETL-Migration

Erste Entscheidungen zur Netezza ETL-Migration

Bei der ETL/ELT-Verarbeitung können ältere Netezza-Data Warehouses benutzerdefinierte Skripts mit Netezza-Dienstprogrammen wie nzsql und nzload oder ETL-Tools von Drittanbietern wie Informatica oder Ab Initio verwenden. Manchmal verwenden Netezza Data Warehouses eine Kombination aus ETL- und ELT-Ansätzen, die sich im Laufe der Zeit weiterentwickelt haben. Bei der Planung einer Migration zu Azure Synapse müssen Sie die beste Methode zur Implementierung der erforderlichen ETL/ELT-Verarbeitung in der neuen Umgebung ermitteln und gleichzeitig die Kosten und Risiken minimieren. Weitere Informationen zur ETL- und ELT-Verarbeitung finden Sie unter ELT vs ETL-Designansatz.

In den folgenden Abschnitten werden Migrationsoptionen erläutert und Empfehlungen für verschiedene Anwendungsfälle vorgenommen. Dieses Flussdiagramm fasst einen Ansatz zusammen:

Der erste Schritt besteht darin, immer einen Bestand an ETL/ELT-Prozessen zu erstellen, die migriert werden müssen. Wie bei anderen Schritten ist es möglich, dass die standardmäßigen "integrierten" Azure-Features es unnötig machen, einige vorhandene Prozesse zu migrieren. Für Planungszwecke ist es wichtig, den Umfang der auszuführenden Migration zu verstehen.

Im vorherigen Flussdiagramm bezieht sich die Entscheidung 1 auf eine allgemeine Entscheidung darüber, ob sie zu einer vollständigen Azure-nativen Umgebung migriert werden soll. Wenn Sie zu einer vollständig azure-nativen Umgebung wechseln, empfehlen wir, die ETL-Verarbeitung mithilfe von Pipelines und Aktivitäten in Azure Data Factory oder Azure Synapse Pipelines neu zu entwickeln. Wenn Sie nicht zu einer vollständigen azure-nativen Umgebung wechseln, entscheidet 2, ob bereits ein vorhandenes ETL-Tool eines Drittanbieters verwendet wird.

Wenn ein ETL-Tool eines Drittanbieters bereits verwendet wird und insbesondere, wenn es eine große Investition in Fähigkeiten oder mehrere vorhandene Workflows und Zeitpläne gibt, die dieses Tool verwenden, dann entscheide 3, ob das Tool Azure Synapse effizient als Zielumgebung unterstützen kann. Im Idealfall enthält das Tool "native" Connectors, die Azure-Einrichtungen wie PolyBase oder COPY INTO nutzen können, um das effizienteste Laden von Daten zu erreichen. Es gibt eine Möglichkeit, einen externen Prozess, wie etwa PolyBase oder COPY INTO, aufzurufen und die entsprechenden Parameter zu übergeben. Nutzen Sie in diesem Fall vorhandene Fähigkeiten und Workflows mit Azure Synapse als neue Zielumgebung.

Wenn Sie ein vorhandenes ETL-Tool eines Drittanbieters beibehalten möchten, kann es Vorteile für die Ausführung dieses Tools innerhalb der Azure-Umgebung (und nicht auf einem vorhandenen lokalen ETL-Server) geben und Azure Data Factory die allgemeine Orchestrierung der vorhandenen Workflows behandeln. Ein besonderer Vorteil ist, dass weniger Daten aus Azure heruntergeladen, verarbeitet und dann wieder in Azure hochgeladen werden müssen. Entscheidung 4 ist also, ob das vorhandene Tool, das as-is ausgeführt wird, verlassen oder in die Azure-Umgebung verschieben, um Kosten-, Leistungs- und Skalierbarkeitsvorteile zu erzielen.

Erneutes Engineering vorhandener Netezza-spezifischer Skripts

Wenn einige oder alle vorhandenen Netezza Warehouse ETL/ELT-Verarbeitungen von benutzerdefinierten Skripts verarbeitet werden, die Netezza-spezifische Hilfsprogramme wie nzsql oder nzload verwenden, müssen diese Skripts für die neue Azure Synapse-Umgebung neu codiert werden. Wenn ETL-Prozesse mit gespeicherten Prozeduren in Netezza implementiert wurden, müssen diese ebenfalls neu codiert werden.

Einige Elemente des ETL-Prozesses sind einfach zu migrieren, z. B. durch einfaches Laden von Massendaten in eine Stagingtabelle aus einer externen Datei. Es kann sogar möglich sein, diese Teile des Prozesses zu automatisieren, z. B. mithilfe von PolyBase anstelle von nzload. Andere Teile des Prozesses, die beliebige komplexe SQL- und/oder gespeicherte Prozeduren enthalten, nehmen mehr Zeit in Anspruch, um den Vorgang neu zu entwickeln.

Eine Möglichkeit zum Testen von Netezza SQL für die Kompatibilität mit Azure Synapse besteht darin, einige repräsentative SQL-Anweisungen aus dem Netezza-Abfrageverlauf zu erfassen, diese Abfragen EXPLAINdann mit präfixieren und dann – vorausgesetzt, ein like-for-like-migriertes Datenmodell in Azure Synapse – diese EXPLAIN Anweisungen in Azure Synapse auszuführen. Jede inkompatible SQL generiert einen Fehler, und die Fehlerinformationen können den Maßstab der Recodierungsaufgabe bestimmen.

Microsoft-Partner bieten Tools und Dienste zum Migrieren von Netezza SQL und gespeicherten Prozeduren zu Azure Synapse an.

Verwenden von ETL-Tools von Drittanbietern

Wie im vorherigen Abschnitt beschrieben, wird in vielen Fällen bereits das vorhandene veraltete Data Warehouse-System von ETL-Produkten von Drittanbietern aufgefüllt und verwaltet. Eine Liste der Microsoft-Datenintegrationspartner für Azure Synapse finden Sie unter Datenintegrationspartner.

Laden von Daten aus Netezza

Beim Laden von Daten aus Netezza verfügbare Auswahlmöglichkeiten

Bei der Migration von Daten aus einem Netezza Data Warehouse gibt es einige grundlegende Fragen im Zusammenhang mit dem Laden von Daten, die gelöst werden müssen. Sie müssen entscheiden, wie die Daten physisch aus der vorhandenen lokalen Netezza-Umgebung in Azure Synapse in der Cloud verschoben werden und welche Tools verwendet werden, um die Übertragung und Last durchzuführen. Berücksichtigen Sie die folgenden Fragen, die in den nächsten Abschnitten erläutert werden.

• Extrahieren Sie die Daten in Dateien, oder verschieben Sie sie direkt über eine Netzwerkverbindung?

• Werden Sie den Prozess aus dem Quellsystem oder aus der Azure-Zielumgebung orchestrieren?

• Welche Tools werden Sie verwenden, um den Prozess zu automatisieren und zu verwalten?

Übertragen von Daten über Dateien oder Netzwerkverbindungen?

Nachdem die zu migrierenden Datenbanktabellen in Azure Synapse erstellt wurden, können Sie die Daten verschieben, um diese Tabellen aus dem älteren Netezza-System und in die neue Umgebung aufzufüllen. Es gibt zwei grundlegende Ansätze:

• Dateiextrakt: Extrahieren Sie die Daten aus den Netezza-Tabellen in Flache Dateien, normalerweise im CSV-Format, über nzsql mit der Option -o oder über die CREATE EXTERNAL TABLE Anweisung. Verwenden Sie nach Möglichkeit eine externe Tabelle, da sie hinsichtlich des Datendurchsatzes am effizientesten ist. Im folgenden SQL-Beispiel wird eine CSV-Datei über eine externe Tabelle erstellt:

  CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',')
  AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;
  

  Verwenden Sie eine externe Tabelle, wenn Sie Daten in ein bereitgestelltes Dateisystem auf einem lokalen Netezza-Host exportieren. Wenn Sie Daten auf einen Remotecomputer exportieren, auf dem JDBC, ODBC oder OLEDB installiert ist, ist die "remotesource odbc"-Option die USING Klausel.

  Dieser Ansatz erfordert Platz, um die extrahierten Datendateien zu landen. Der Speicherplatz kann lokal in der Netezza-Quelldatenbank (sofern ausreichend Speicher verfügbar ist) oder remote in Azure Blob Storage sein. Die beste Leistung wird erzielt, wenn eine Datei lokal geschrieben wird, da dadurch Netzwerkaufwand vermieden wird.

  Um die Speicher- und Netzwerkübertragungsanforderungen zu minimieren, empfiehlt es sich, die extrahierten Datendateien mithilfe eines Dienstprogramms wie gzip zu komprimieren.

  Nach dem Extrahieren können die Flachdateien entweder in Azure Blob Storage verschoben werden (mit der Azure Synapse-Zielinstanz verknüpft) oder direkt mit PolyBase oder COPY INTO in Azure Synapse geladen werden. Die Methode zum physischen Verschieben von Daten vom lokalen lokalen Speicher in die Azure-Cloudumgebung hängt von der Datenmenge und der verfügbaren Netzwerkbandbreite ab.

  Microsoft bietet verschiedene Optionen zum Verschieben großer Datenmengen, einschließlich AzCopy zum Verschieben von Dateien über das Netzwerk in Azure Storage, Azure ExpressRoute zum Verschieben von Massendaten über eine private Netzwerkverbindung und Azure Data Box für Dateien, die auf ein physisches Speichergerät verschoben werden, das dann zum Laden an ein Azure-Rechenzentrum ausgeliefert wird. Weitere Informationen finden Sie unter Datenübertragung.

• Direktes Extrahieren und Laden über das Netzwerk hinweg: Die Azure-Zielumgebung sendet eine Datenextraktionsanforderung, normalerweise über einen SQL-Befehl, an das ältere Netezza-System, um die Daten zu extrahieren. Die Ergebnisse werden über das Netzwerk gesendet und direkt in Azure Synapse geladen, ohne die Daten in Zwischendateien zu bringen. Der begrenzungsfaktor in diesem Szenario ist normalerweise die Bandbreite der Netzwerkverbindung zwischen der Netezza-Datenbank und der Azure-Umgebung. Bei sehr großen Datenvolumes ist dieser Ansatz möglicherweise nicht praktikabel.

Es gibt auch einen Hybridansatz, der beide Methoden verwendet. Sie können z. B. den direkten Netzwerkextraktionsansatz für kleinere Dimensionstabellen und Beispiele der größeren Faktentabellen verwenden, um schnell eine Testumgebung in Azure Synapse bereitzustellen. Bei umfangreichen historischen Faktentabellen können Sie den Dateiextraktions- und Übertragungsansatz mithilfe von Azure Data Box verwenden.

Aus Netezza oder Azure orchestrieren?

Der empfohlene Ansatz beim Wechsel zu Azure Synapse besteht darin, die Datenextraktion und das Laden aus der Azure-Umgebung mithilfe von Azure Synapse Pipelines oder Azure Data Factory sowie zugehörige Dienstprogramme wie PolyBase oder COPY INTO für das effizienteste Laden von Daten zu koordinieren. Dieser Ansatz nutzt Azure-Funktionen und bietet eine einfache Methode zum Erstellen wiederverwendbarer Datenladepipelines.

Weitere Vorteile dieses Ansatzes sind reduzierte Auswirkungen auf das Netezza-System während des Datenladevorgangs, da der Verwaltungs- und Ladevorgang in Azure ausgeführt wird, und die Möglichkeit, den Prozess mithilfe von metadatengesteuerten Datenladepipelines zu automatisieren.

Welche Tools können verwendet werden?

Die Aufgabe der Datentransformation und -bewegung ist die grundlegende Funktion aller ETL-Produkte. Wenn eines dieser Produkte bereits in der vorhandenen Netezza-Umgebung verwendet wird, kann die Verwendung des vorhandenen ETL-Tools die Datenmigration von Netezza zu Azure Synapse vereinfachen. Bei diesem Ansatz wird davon ausgegangen, dass das ETL-Tool Azure Synapse als Zielumgebung unterstützt. Weitere Informationen zu Tools, die Azure Synapse unterstützen, finden Sie unter Datenintegrationspartner.

Wenn Sie ein ETL-Tool verwenden, sollten Sie dieses Tool in der Azure-Umgebung ausführen, um von der Azure-Cloudleistung, Skalierbarkeit und -Kosten zu profitieren und Ressourcen im Netezza-Rechenzentrum freizugeben. Ein weiterer Vorteil ist eine reduzierte Datenverschiebung zwischen der Cloud und lokalen Umgebungen.

Zusammenfassung

Zusammenfassend sind unsere Empfehlungen für die Migration von Daten und zugeordneten ETL-Prozessen von Netezza zu Azure Synapse:

• Planen Sie voraus, um eine erfolgreiche Migrationsübung sicherzustellen.

• Erstellen Sie eine detaillierte Bestandsaufnahme der Daten und Prozesse, die so schnell wie möglich migriert werden sollen.

• Verwenden Sie Systemmetadaten und Protokolldateien, um ein genaues Verständnis der Daten- und Prozessverwendung zu erhalten. Verlassen Sie sich nicht auf die Dokumentation, da sie möglicherweise nicht mehr aktuell ist.

• Verstehen Sie die zu migrierenden Datenvolumes und die Netzwerkbandbreite zwischen dem lokalen Rechenzentrum und Azure Cloud-Umgebungen.

• Nutzen Sie die standardmäßigen "integrierten" Azure-Features, um die Migrationsauslastung zu minimieren.

• Identifizieren und verstehen Sie die effizientesten Tools für die Datenextraktion und das Laden in Netezza- und Azure-Umgebungen. Verwenden Sie die entsprechenden Tools in jeder Phase des Prozesses.

• Verwenden Sie Azure-Einrichtungen wie Azure Synapse-Pipelines oder Azure Data Factory, um den Migrationsprozess zu koordinieren und zu automatisieren und gleichzeitig die Auswirkungen auf das Netezza-System zu minimieren.

Nächste Schritte

Weitere Informationen zu Sicherheitszugriffsvorgängen finden Sie im nächsten Artikel dieser Reihe: Sicherheit, Zugriff und Vorgänge für Netezza-Migrationen.