Freigeben über

Datenmigration, ETL und Laden für die Netezza-Migration

  • Artikel

Dieser Artikel ist Teil zwei einer siebenteiligen Reihe, die Anleitungen zur Migration 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-Datenspeichers sollten Sie sich einige grundlegende Fragen stellen. Beispiel:

  • Sollen nicht verwendete Tabellenstrukturen migriert werden?

  • Mit welchem Migrationsansatz lassen sich Risiken und Auswirkungen für Benutzer am besten minimieren?

  • Soll beim Migrieren von Data Marts eine physische Implementierung (wie bisher) oder lieber eine virtuelle Implementierung verwendet werden?

In den folgenden Abschnitten werden diese Punkte im Kontext der Migration von Netezza erörtert.

Migrieren nicht verwendeter Tabellen?

Tipp

In Legacy-Systemen ist es nicht ungewöhnlich, dass Tabellen im Laufe der Zeit redundant werden – diese müssen in den meisten Fällen nicht migriert werden.

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

Wenn diese Funktion aktiviert ist, enthalten die Netezza-Abfrageverlaufstabellen Informationen, anhand derer festgestellt werden kann, wann auf eine bestimmte Tabelle zuletzt zugegriffen wurde. Damit kann entschieden werden, ob eine Tabelle für eine Migration in Frage kommt.

Mit der folgenden Beispielabfrage wird nach der Verwendung einer bestimmten Tabelle innerhalb eines bestimmten Zeitfensters gesucht:

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)

Bei dieser Abfrage wird die Hilfsprogrammfunktion FORMAT_TABLE_ACCESS und die Ziffer am Ende der Sicht $v_hist_table_access_3 verwendet, um die installierte Abfrageverlaufsversion abzugleichen.

Mit welchem Migrationsansatz lassen sich Risiken und Auswirkungen für Benutzer*innen am besten minimieren?

Diese Frage wird häufig gestellt, da Unternehmen möglicherweise die Auswirkungen von Änderungen auf das Data Warehouse-Datenmodell verringern möchten, um die Agilität zu verbessern. Unternehmen sehen oft eine Möglichkeit, ihre Daten während einer ETL-Migration weiter zu modernisieren oder umzuwandeln. Dieser Ansatz trägt ein höheres Risiko, da mehrere Faktoren gleichzeitig geändert werden, was einen Vergleich der Ergebnisse des alten Systems mit denen des neuen erschwert. Änderungen am Datenmodell an dieser Stelle können sich auch auf vor- oder nachgelagerte ETL-Jobs für andere Systeme auswirken. Aufgrund dieses Risikos ist es besser, nach der Data-Warehouse-Migration eine Neugestaltung in diesem Umfang vorzunehmen.

Auch wenn ein Datenmodell im Rahmen der Gesamtmigration absichtlich geändert wird, empfiehlt es sich, das vorhandene Modell unverändert zu Azure Synapse zu migrieren, anstatt eine Neuentwicklung auf der neuen Plattform vorzunehmen. Dieser Ansatz minimiert die Auswirkungen auf bestehende Produktionssysteme und profitiert gleichzeitig von der Leistung und elastischen Skalierbarkeit der Azure-Plattform für einmalige Reengineering-Aufgaben.

Bei der Migration von Netezza eignet sich oft schon das vorhandene Datenmodell für die unveränderte Migration zu Azure Synapse.

Tipp

Migrieren Sie das bestehende Modell zunächst im Ist-Zustand, auch wenn eine Änderung des Datenmodells in Zukunft geplant ist.

Beim Migrieren von Data Marts weiterhin eine physische Implementierung verwenden oder zu einer virtuellen Implementierung wechseln?

Tipp

Durch die Virtualisierung von Daten Marts können Speicher- und Verarbeitungsressourcen gespart werden.

In Data Warehouse-Legacyumgebungen ist es üblich, mehrere Data Marts zu erstellen, die so strukturiert sind, dass sie eine gute Leistung für Ad-hoc-Self-Service-Abfragen und Berichte für eine bestimmte Abteilung oder Geschäftsfunktion innerhalb einer Organisation bieten. Daher besteht ein Data Mart in der Regel aus einer Teilmenge des Data Warehouse und enthält aggregierte Versionen der Daten in einer Form, die Benutzer*innen das einfache Abfragen dieser Daten mit kurzen Reaktionszeiten über benutzerfreundliche Abfragetools wie Microsoft Power BI, Tableau oder MicroStrategy ermöglicht. Bei dieser Form handelt es sich in der Regel um ein eindimensionales Datenmodell. Eine Verwendung von Data Marts besteht darin, die Daten in einer nutzbaren Form verfügbar zu machen, selbst wenn das zugrunde liegende Warehouse-Datenmodell z. B. ein Datentresor ist.

Sie können auch separate Data Marts für einzelne Geschäftsbereiche innerhalb einer Organisation verwenden, um zuverlässige Datensicherheitsregelungen zu implementieren, indem nur der Benutzerzugriff auf bestimmte, relevante Data Marts gewährt und vertrauliche Daten entfernt, verborgen oder anonymisiert werden.

Wenn diese Data Marts als physische Tabellen implementiert sind, werden zusätzliche Speicherressourcen nötig, um diese zu speichern, und zusätzliche Verarbeitungsschritte, um sie regelmäßig zu erstellen und zu aktualisieren. Zudem entspricht die Aktualität der Daten im Data Mart nur dem letzten Aktualisierungsvorgang, sodass sie daher möglicherweise für stark veränderliche Datendashboards nicht geeignet sind.

Tipp

Leistung und Skalierbarkeit von Azure Synapse ermöglichen eine Virtualisierung ohne Leistungsbeeinträchtigung.

Mit dem Aufkommen relativ kostengünstiger skalierbarer MPP-Architekturen wie Azure Synapse und den damit verbundenen Leistungsmerkmalen können Sie möglicherweise Data Mart-Funktionalität bereitstellen, ohne den Data Mart als Gruppe physischer Tabellen instanziieren zu müssen. Dies wird durch eine effektive Virtualisierung der Data Marts über SQL-Sichten auf das zentrale Data Warehouse oder über eine Virtualisierungsschicht mithilfe von Features wie Sichten in Azure oder Visualisierungsprodukten von Microsoft-Partnern erreicht. Durch diesen Ansatz wird die Notwendigkeit zusätzlicher Speicher- und Aggregationsverarbeitung minimiert oder aufgehoben und die Gesamtanzahl zu migrierender Datenbankobjekte reduziert.

Dieser Ansatz bietet einen weiteren potenziellen Vorteil. Durch Implementierung der Aggregations- und Joinlogik innerhalb einer Virtualisierungsschicht und die Darstellung externer Berichtstools über eine virtualisierte Sicht wird die zum Erstellen dieser Sichten erforderliche Verarbeitung per Push an das Data Warehouse übertragen. Dies ist in der Regel der beste Ort zum Ausführen von Joins, Aggregationen und anderen verwandten Vorgängen für große Datenvolumen.

Folgende Gründe sprechen für die Wahl einer virtuellen Data Mart-Implementierung anstelle eines physischen Data Marts:

  • Mehr Agilität: Virtuelle Data Marts können einfacher geändert werden als physische Tabellen und die zugehörigen ETL-Prozesse.

  • Geringere Gesamtkosten: In einer virtualisierten Implementierung sind weniger Datenspeicher und Datenkopien erforderlich.

  • Keine zu migrierenden ETL-Aufträge und vereinfachte Data-Warehouse-Architektur in einer virtualisierten Umgebung.

  • Leistung: Bisher waren zwar physische Data Marts leistungsfähiger, aber jetzt werden durch Virtualisierungsprodukte intelligente Zwischenspeicherungsverfahren implementiert, um dies auszugleichen.

Datenmigration von Netezza

Verstehen Ihrer Daten

Ein Teil der Migrationsplanung besteht darin, sich einen Überblick über das zu migrierende Datenvolumen zu verschaffen, da dadurch die Entscheidungen über den Migrationsansatz beeinflusst werden kann. Bestimmen Sie anhand von Systemmetadaten den physischen Speicherplatz, der von den „Rohdaten“ in den zu migrierenden Tabellen belegt wird. Mit „Rohdaten“ ist in diesem Zusammenhang der von den Datenzeilen in einer Tabelle belegte Platz ohne Mehrbedarf für Indizes und Komprimierung gemeint. Dies gilt insbesondere für die besonders große Faktentabellen, da diese in der Regel mehr als 95 % der Daten umfassen.

Sie können eine genaue Zahl für das Volumen der zu migrierenden Daten für eine bestimmte Tabelle ermitteln, indem Sie eine repräsentative Stichprobe der Daten – beispielsweise eine Million Zeilen – in eine nicht komprimierte, durch Trennzeichen getrennte Flatfile mit ASCII-Daten extrahieren. Anschließend ermitteln Sie anhand der Größe dieser Datei die durchschnittliche Menge der Rohdaten pro Tabellenzeile. Multiplizieren Sie schließlich diese durchschnittliche Menge mit der Gesamtanzahl der Zeilen in der ganzen Tabelle, um die Menge der Rohdaten für die Tabelle zu erhalten. Verwenden Sie diese Rohdatenmenge für Ihre Planung.

Netezza-Datentypzuordnung

Tipp

Bewerten Sie in der Vorbereitungsphase die Auswirkungen nicht unterstützter Datentypen.

In Azure Synapse gibt es eine direkte Entsprechung für die meisten Netezza-Datentypen. In der folgenden Tabelle sind diese Datentypen und die empfohlene Vorgehensweise für deren Zuordnung aufgeführt.

Netezza-Datentyp Azure Synapse-Datentyp
bigint bigint
BINARY VARYING(n) VARBINARY(n)
BOOLEAN BIT
BYTEINT TINYINT
CHARACTER VARYING(n) VARCHAR(n)
CHARACTER(n) CHAR(n)
DATE DATE(date)
DECIMAL(p,s) DECIMAL(p,s)
DOUBLE PRECISION GLEITKOMMAZAHL
FLOAT(n) FLOAT(n)
INTEGER INT
INTERVAL INTERVAL-Datentypen werden derzeit in Azure Synapse Analytics nicht direkt unterstützt, können jedoch mithilfe temporaler Funktionen wie DATEDIFF berechnet werden.
MONEY MONEY
NATIONAL CHARACTER VARYING(n) NVARCHAR(n)
NATIONAL CHARACTER(n) NCHAR(n)
NUMERIC(p,s) NUMERIC(p,s)
real REAL
SMALLINT SMALLINT
ST_GEOMETRY(n) Räumliche Datentypen wie ST_GEOMETRY werden derzeit nicht in Azure Synapse Analytics unterstützt, die Daten können allerdings als VARCHAR oder VARBINARY gespeichert werden.
TIME TIME
TIME WITH TIME ZONE DATETIMEOFFSET
timestamp DATETIME

Verwenden Sie die Metadaten aus den Netezza-Katalogtabellen, um festzulegen, ob diese Datentypen migriert werden müssen, und planen Sie dies im Migrationsplan ein. Für diese Art von Abfrage werden in Netezza hauptsächlich die folgenden Metadatenansichten verwendet:

  • _V_USER: Die Benutzeransicht stellt Informationen zu den Benutzer*innen im Netezza-System bereit.

  • _V_TABLE: In der Tabellenansicht sind die im Netezza-Leistungssystem erstellten Tabellenliste enthalten.

  • _V_RELATION_COLUMN: Die Katalogansicht des Beziehungsspaltensystems enthält die in der Tabelle verfügbaren Spalten.

  • _V_OBJECTS: In der Objektansicht werden die verschiedenen in Netezza verfügbaren Objekte wie Tabellen, Sichten, Funktionen usw. angezeigt.

Mit 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 so geändert werden, dass alle Tabellen nach Vorkommen nicht unterstützter Datentypen durchsucht werden.

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

Bestimmte Drittanbieter bieten Tools und Dienste wie die weiter oben beschriebene Zuordnung von Datentypen zum Automatisieren der Migration an. Zudem können mit ETL-Tools von Drittanbietern wie Informatica oder Talend, die in der Netezza-Umgebung bereits verwendet werden, alle erforderlichen Datentransformationen implementiert werden. Im nächsten Abschnitt wird die Migration bestehender ETL-Prozesse von Drittanbietern beschrieben.

Überlegungen zur ETL-Migration

Erste Entscheidungen im Zusammenhang mit der ETL-Migration in der Netezza-Umgebung

Tipp

Planen Sie den Ansatz für die ETL-Migration vorab, und nutzen Sie dabei gegebenenfalls Azure-Einrichtungen.

Bei der ETL/ELT-Verarbeitung können von Legacy-Data Warehouse-Datenbanken in einer Netezza-Umgebung benutzerdefinierte Skripts mithilfe von Netezza-Hilfsprogrammen wie nzsql und nzload oder mithilfe von ETL-Tools von Drittanbietern wie Informatica doer Ab Initio verwendet werden. Manchmal wird in Data Warehouse-Datenbanken in Netezza-Umgebungen eine Kombination aus ETL- und ELT-Ansätzen verwendet, die im Laufe der Zeit entwickelt wurden. Bei der Planung einer Migration zu Azure Synapse geht es darum, die beste Möglichkeit zur Implementierung der erforderlichen ETL/ELT-Verarbeitungsschritte in der neuen Umgebung zu finden, mit der gleichzeitig die damit verbundenen Kosten und Risiken minimiert werden. Weitere Informationen zur ETL- und ELT-Verarbeitung finden Sie unter ELT- und ETL-Entwurfsansatz im Vergleich.

In den folgenden Abschnitten werden Migrationsoptionen erläutert und Empfehlungen für verschiedene Anwendungsfälle gegeben. In diesem Flussdiagramm wird ein Ansatz zusammengefasst:

Das Flussdiagramm der Migrationsoptionen und -empfehlungen.

Der erste Schritt ist immer eine Bestandsaufnahme der ETL/ELT-Prozesse, die migriert werden müssen. Wie bei anderen Schritten ist es möglich, dass einige vorhandene Prozesse dank der standardmäßig „integrierten“ Azure-Features nicht migriert werden müssen. Zur Planung müssen Sie sich einen Überblick über den Umfang der durchzuführenden Migration verschaffen.

Im vorherigen Flussdiagramm bezieht sich Entscheidung 1 auf die allgemeine Entscheidung darüber, ob zu einer vollständig Azure-nativen Umgebung migriert werden soll. Bei Migration zu einer vollständig Azure-nativen Umgebung sollten Sie die ETL-Verarbeitung mithilfe von Pipelines und Aktivitäten in Azure Data Factory oder Azure Synapse-Pipelines einem Re-Engineering unterziehen. Wenn nicht zu einer vollständig Azure-nativen Umgebung migriert wird, muss im Rahmen der 2. Entscheidung ermittelt werden, ob bereits ein vorhandenes ETL-Tool eines Drittanbieters verwendet wird.

Tipp

Nutzen Sie Investitionen in vorhandene Tools von Drittanbietern, um Kosten und Risiken zu reduzieren.

Wenn bereits ein ETL-Tool eines Drittanbieters in Gebrauch ist und umfangreich in Qualifikationen investiert wurde oder dieses Tool in verschiedenen bestehenden Workflows und Zeitplänen eingesetzt wird, muss im Rahmen der 3. Entscheidung ermittelt werden, ob das Tool Azure Synapse als Zielumgebung effizient unterstützen kann. Im Idealfall enthält das Tool „native“ Connectors, die Azure-Funktionen wie PolyBase oder COPY INTO nutzen können, um ein effizientes Laden der Daten zu ermöglichen. Es gibt eine Möglichkeit zum Aufrufen eines externen Prozesses wie PolyBase oder COPY INTO und zum Übergeben der entsprechenden Parameter. Nutzen Sie in diesem Fall vorhandene Fertigkeiten und Workflows mit Azure Synapse als neuer Zielumgebung.

Wenn Sie ein vorhandenes ETL-Tool eines Drittanbieters weiterhin einsetzen möchten, sollten Sie es in der Azure-Umgebung (statt auf einem vorhandenen lokalen ETL-Server) ausführen und Azure Data Factory für die gesamte Orchestrierung der bestehenden Workflows nutzen. Dies hat vor allem den Vorteil, dass weniger Daten aus Azure heruntergeladen, verarbeitet und anschließend wieder in Azure hochgeladen werden müssen. Bei der 4. Entscheidung geht es also darum, ob das vorhandene Tool unverändert weiterverwendet oder zur Nutzung von Kosten-, Leistungs- und Skalierbarkeitsvorteilen in die Azure-Umgebung migriert werden soll.

Erneutes Entwickeln bereits vorhandener Netezza-spezifischer Skripts

Wenn ein Teil oder alle der vorhandenen ETL/ELT-Verarbeitungsschritte im Netezza-Warehouse mithilfe von benutzerdefinierten Skripts durchgeführt werden, für die Netezza-spezifische Hilfsprogramme wie nzsql oder nzload verwendet werden, müssen diese Skripts für die neue Azure Synapse-Umgebung neu programmiert werden. Wenn ETL-Prozesse mit gespeicherten Prozeduren in Netezza implementiert wurden, müssen auch diese neu programmiert werden.

Tipp

Der Bestand der zu migrierenden ETL-Aufgaben sollte Skripts und gespeicherte Prozeduren enthalten.

Einige Elemente des ETL-Prozesses können ohne großen Aufwand migriert werden, z. B. durch einfaches Massenladen von Daten in eine Stagingtabelle aus einer externen Datei. Wenn anstelle von nzload PolyBase verwendet wird, können diese Teile des Prozesses sogar möglicherweise automatisiert werden. Bei anderen Teilen des Prozesses, die beliebig komplexe SQL- und/oder andere gespeicherte Prozeduren enthalten, nimmt das Re-Engineering mehr Zeit in Anspruch.

Eine Möglichkeit, Netezza SQL auf Kompatibilität mit Azure Synapse zu testen, besteht darin, einige repräsentative SQL-Anweisungen aus dem Netezza-Abfrageverlauf zu erfassen, diesen Abfragen EXPLAIN voranzustellen und dann – unter der Annahme eines gleichartigen migrierten Datenmodells in Azure Synapse – diese EXPLAIN-Anweisungen in Azure Synapse auszuführen. Bei nicht kompatiblem SQL-Code wird ein Fehler verursacht, wobei der Umfang der Umprogrammierung anhand der Fehlerinformationen bestimmt wird.

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

Verwenden von ETL-Tools von Drittanbietern

Wie im vorherigen Abschnitt beschrieben, wird das vorhandene Data Warehouse-Legacysystem bereits von ETL-Produkten von Drittanbietern aufgefüllt und verwaltet. Eine Liste der Microsoft-Partner für Datenintegration für Azure Synapse finden Sie unter Partner für die Datenintegration.

Laden von Daten aus Netezza

Auswahlmöglichkeiten beim Laden von Daten aus Netezza

Tipp

Mithilfe von Tools von Drittanbietern lässt sich der Migrationsprozess vereinfachen und automatisieren und somit das Risiko verringern.

Bei der Migration von Daten aus einem Netezza-Data-Warehouse müssen einige grundlegende Fragen im Zusammenhang mit dem Laden von Daten geklärt werden. So muss beispielsweise entschieden werden, wie die Daten physisch aus der vorhandenen lokalen Netezza-Umgebung in Azure Synapse in der Cloud verschoben und welche Tools zum Übertragen und Laden verwendet werden sollen. Beantworten Sie die folgenden Fragen, die in den nächsten Abschnitten erörtert werden.

  • Sollen die Daten in Dateien extrahiert oder direkt über eine Netzwerkverbindung verschoben werden?

  • Soll der Prozess über das Quellsystem oder die Azure-Zielumgebung orchestriert werden?

  • Welche Tools werden zum Automatisieren und Verwalten des Prozesses verwendet?

Werden Daten mittels Dateien oder einer Netzwerkverbindung übertragen?

Tipp

Verschaffen Sie sich einen Überblick über die zu migrierenden Datenvolumen und die verfügbare Netzwerkbandbreite, da diese Faktoren bestimmen, welcher Migrationsansatz verwendet werden kann.

Nachdem die zu migrierenden Datenbanktabellen in Azure Synapse erstellt wurden, können die Daten, mit denen diese Tabellen gefüllt werden, aus dem Netezza-Legacysystem in die neue Umgebung geladen werden. Dabei gibt es grundsätzlich zwei Ansätze:

  • Dateiextraktion: Die Daten werden über nzsql mit der Option „-o“ oder über die Anweisung CREATE EXTERNAL TABLE aus den Netezza-Tabellen in Flatfiles in der Regel im CSV-Format extrahiert. Dabei sollte nach Möglichkeit eine externe Tabelle verwendet werden, da diese den effizientesten Datendurchsatz bietet. Mit dem 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;

    Zum Exportieren von Daten in ein bereitgestelltes Dateisystem auf einem lokalen Netezza-Host sollte eine externe Tabelle verwendet werden. Wenn Daten in einem Remotecomputer exportiert werden, auf dem JDBC, ODBC oder OLEDB installiert ist, entspricht die „remotesource odbc“-Option der USING-Klausel.

    Bei diesem Ansatz wird Speicherplatz zum Speichern der extrahierten Datendateien benötigt. Dabei kann sich der Speicherplatz lokal in der Netezza-Quelldatenbank (sofern genügend Speicher verfügbar ist) oder remote in Azure Blob Storage befinden. Die beste Leistung wird erreicht, wenn eine Datei lokal geschrieben wird, da dadurch Netzwerkaufwand vermieden wird.

    Zur Minimierung der Speicher- und Netzwerkübertragungsanforderungen hat es sich bewährt, die extrahierten Datendateien mit einem Hilfsprogramm wie gzip zu komprimieren.

    Nach dem Extrahieren können die Flatfiles entweder (zusammen mit der Azure Synapse-Zielinstanz) in Azure Blob Storage verschoben oder mit PolyBase oder COPY INTO direkt in Azure Synapse geladen werden. Welche Methode zum physischen Verschieben von Daten aus lokalem Speicher in die Azure-Cloudumgebung verwendet wird, hängt von der Datenmenge und verfügbaren Netzwerkbandbreite ab.

    Microsoft bietet verschiedene Optionen zum Verschieben großer Datenmengen wie AzCopy zum Verschieben von Dateien im Netzwerk in Azure Storage, Azure ExpressRoute zum Verschieben von Massendaten über eine private Netzwerkverbindung und Azure Data Box zum Verschieben von Dateien auf ein physisches Speichergerät, das dann an ein Azure-Rechenzentrum zum Laden gesendet wird. Weitere Informationen finden Sie unter Übertragen von Daten.

  • Direktes Extrahieren und Laden im gesamten Netzwerk: Von der Azure-Zielumgebung wird eine Anforderung zum Extrahieren von Daten in der Regel über einen SQL-Befehl an das Netezza-Legacysystem zum Extrahieren der Daten gesendet. Die Ergebnisse werden über das Netzwerk gesendet und direkt in Azure Synapse geladen, ohne dass die Daten in Zwischendateien gespeichert werden müssen. Der begrenzende Faktor in diesem Szenario ist normalerweise die Bandbreite der Netzwerkverbindung zwischen der Netezza-Datenbank und der Azure-Umgebung. Bei sehr großen Datenmengen ist dieser Ansatz möglicherweise nicht praktikabel.

Es gibt auch einen Hybridansatz, bei dem beide Methoden verwendet werden. Sie können beispielsweise den Ansatz der direkten Netzwerkextraktion für kleinere Dimensionstabellen und Stichproben größerer Faktentabellen zum schnellen Bereitstellen einer Testumgebung in Azure Synapse verwenden. Für umfangreiche historische Faktentabellen können Sie den Ansatz der Dateiextraktion und -übertragung mit Azure Data Box verwenden.

Über Netezza der Azure orchestrieren?

Zum möglichst effizienten Laden von Daten wird empfohlen, beim Verschieben zu Azure Synapse das Extrahieren und Laden der Daten aus der Azure-Umgebung mithilfe von Azure Synapse Pipelines oder Azure Data Factory und mit entsprechenden Hilfsprogrammen wie PolyBase oder COPY INTO zu orchestrieren. Dies ist eine einfache Methode zum Erstellen wiederverwendbarer Pipelines zum Laden von Dateien unter Verwendung von Azure-Funktionen.

Weitere Vorteile dieses Ansatzes sind geringere Auswirkungen auf das Netezza-System während des Datenladeprozesses, da der Verwaltungs- und Ladeprozess in Azure ausgeführt wird, sowie die Möglichkeit, den Prozess durch die Verwendung von metadatengesteuerten Pipelines zum Laden von Daten zu automatisieren.

Welche Tools können verwendet werden?

Die Aufgabe der Datentransformation und -verschiebung ist die Grundfunktion aller ETL-Produkte. Wenn in der vorhandenen Netezza-Umgebung bereits eines dieser Produkte verwendet wird, lässt sich die Datenmigration von Netezza zu Azure Synapse mithilfe eines vorhandenen ETL-Tools 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 Partner für die Datenintegration.

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

Zusammenfassung

Zusammengefasst lauten unsere Empfehlungen für die Migration von Daten und zugehörigen ETL-Prozessen von Netezza zu Azure Synapse wie folgt:

  • Planen Sie zur Gewährleistung einer erfolgreichen Migration voraus.

  • Verschaffen Sie sich einen umfassenden Überblick über die Daten und Prozesse, die so schnell wie möglich migriert werden müssen.

  • Verschaffen Sie sich anhand von Systemmetadaten und Protokolldateien einen umfassenden Überblick über die Nutzung von Daten und Prozessen. Verlassen Sie sich nicht auf die Dokumentation, da sie möglicherweise veraltet ist.

  • Verschaffen Sie sich einen Überblick über die zu migrierenden Datenmengen und die Netzwerkbandbreite zwischen dem lokalen Rechenzentrum und Azure-Cloudumgebungen.

  • Nutzen Sie standardmäßig „integrierte“ Azure-Features, um den Migrationsaufwand zu minimieren.

  • Informieren Sie sich über die effizientesten Tools zum Extrahieren und Laden von Daten in Netezza- und Azure-Umgebungen. Verwenden Sie in den einzelnen Phasen des Prozesses die jeweils geeigneten Tools.

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

Nächste Schritte

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