- Artikel
Dieses Tutorial ist der 2. Teil eines siebenteiligen Leitfadens für die Migration von Teradata zu Azure Synapse Analytics. Schwerpunktmäßig behandelt dieses Tutorial bewährte Methoden für ETL-Prozesse und Lademigration.
Überlegungen zur Datenmigration
Erste Entscheidungen für die Datenmigration von Teradata
Beim Migrieren eines Teradata-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 Teradata erörtert.
Sollen nicht verwendete Tabellen migriert werden?
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, Systemmetadaten und Protokolldateien anstelle der Dokumentation zu verwenden, um festzustellen, welche Tabellen in Gebrauch sind, da die Dokumentation veraltet sein kann.
Falls aktiviert, enthalten die Teradata-Systemkatalogtabellen und -Protokolle 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.
Hier ist eine Beispielabfrage von DBC.Tables, die das Datum des letzten Zugriffs und der letzten Änderung zurückgibt:
SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName,LastAlterTimeStamp, AccessCount, LastAccessTimeStamp FROM DBC.Tables tWHERE DataBaseName = 'databasename'Wenn die Protokollierung aktiviert ist und auf den Protokollverlauf zugegriffen werden kann, stehen in der Tabelle DBQLogTbl und den zugehörigen Protokollierungstabellen weitere Informationen wie z.B. der Text der SQL-Abfrage zur Verfügung. Weitere Informationen finden Sie unter Protokollverlauf von Teradata.
Mit welchem Migrationsansatz lassen sich Risiken und Auswirkungen für Benutzer 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. Das hat den Vorteil, dass die Auswirkungen auf vorhandene Produktionssysteme minimiert und gleichzeitig die Leistung und die elastische Skalierbarkeit der Azure-Plattform für einmalige Aufgaben zum Re-Engineering genutzt werden.
Bei der Migration von Teradata empfiehlt sich die Erstellung einer Teradata-Umgebung in einer VM in Azure als Ausgangspunkt für den Migrationsprozess.
Tipp
Migrieren Sie das bestehende Modell zunächst im Ist-Zustand, auch wenn eine Änderung des Datenmodells in Zukunft geplant ist.
Verwenden einer Teradata-Instanz auf einer VM als Teil einer Migration
Ein optionaler Ansatz für die Migration einer lokalen Teradata-Umgebung besteht darin, die Azure-Umgebung zu nutzen, um eine Teradata-Instanz in einer VM in Azure zu erstellen, die mit der AzureSynapse-Zielumgebung verbunden ist. Dies ist möglich, da Azure günstigen Cloudspeicher und elastische Skalierbarkeit bietet.
Bei diesem Ansatz können standardmäßige Teradata-Hilfsprogramme wie Teradata Parallel Data Transporter (oder Datenreplikationstools von Drittanbietern wie Attunity Replicate) zum Einsatz kommen, um die Teilmenge der zu migrierenden Teradata-Tabellen effizient in die VM-Instanz zu verschieben. Anschließend können alle Migrationsaufgaben innerhalb der Azure-Umgebung erfolgen. Dieser Ansatz hat mehrere Vorteile:
Nach der ersten Replikation von Daten wird das Quellsystem von den Migrationsaufgaben nicht weiter beeinträchtigt.
Die Azure-Umgebung bietet vertraute Schnittstellen, Tools und Hilfsprogramme von Teradata.
Die Azure-Umgebung sorgt für Verfügbarkeit von Netzwerkbandbreite zwischen dem lokalen Quellsystem und dem Zielsystem in der Cloud.
Tools wie Azure Data Factory können Hilfsprogramme wie Teradata Parallel Transporter effizient aufrufen, um Daten schnell und einfach zu migrieren.
Der Migrationsprozess wird vollständig in der Azure-Umgebung orchestriert und gesteuert.
Soll beim Migrieren von Data Marts eine physische Implementierung (wie bisher) oder lieber eine virtuelle Implementierung verwendet werden?
Tipp
Durch Virtualisierung von Data Marts können Speicher- und Verarbeitungsressourcen eingespart werden.
In bisherigen Data Warehouse-Umgebungen von Teradata 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 Benutzern das einfache Abfragen dieser Daten mit kurzen Reaktionszeiten über benutzerfreundliche Abfragetools wie Microsoft PowerBI, 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 aus Teradata
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. Nutzen Sie diese Rohdatenmenge für Ihre Planung.
Überlegungen zur ETL-Migration
Erste Entscheidungen im Zusammenhang mit der ETL-Migration in der Teradata-Umgebung
Tipp
Planen Sie den Ansatz für die ETL-Migration vorab, und nutzen Sie dabei von Azure gebotene Möglichkeiten.
Zur ETL/ELT-Verarbeitung verwenden ältere Data Warehouses in Teradata ggf. benutzerdefinierte Skripts mit Teradata-Hilfsprogrammen wie BTEQ und Teradata Parallel Transporter (TPT) oder ETL-Tools von Drittanbietern wie Informatica oder Ab Initio. Mitunter wird in Data Warehouse-Datenbanken in Teradata-Umgebungen eine Kombination aus ETL- und ELT-Ansätzen verwendet, die im Laufe der Zeit weiterentwickelt wurde. Bei 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:
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 Entscheidung1 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 Sie nicht zu einer vollständig Azure-nativen Umgebung migrierten, muss im Rahmen der 2.Entscheidung ermittelt werden, ob bereits ein vorhandenes ETL-Tool eines Drittanbieters im Einsatz ist.
In der Teradata-Umgebung kann ein Teil oder die gesamte ETL-Verarbeitung durch benutzerdefinierte Skripts unter Verwendung Teradata-spezifischer Hilfsprogramme wie BTEQ und TPT erfolgen. In diesem Fall sollte Ihr Ansatz das Re-Engineering mithilfe von Data Factory vorsehen.
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 COPYINTO 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.
Re-Engineering bereits vorhandener Teradata-spezifischer Skripts
Wenn ein Teil oder die gesamte vorhandene ETL/ELT-Verarbeitung des Teradata-Warehouse über benutzerdefinierte Skripts erfolgt, die Teradata-spezifische Hilfsprogramme wie BTEQ, MLOAD oder TPT einsetzen, müssen diese Skripts für die neue Azure Synapse-Umgebung umprogrammiert werden. Wenn ETL-Prozesse mit gespeicherten Prozeduren in Teradata implementiert wurden, müssen auch diese umprogrammiert 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. Eventuell ist es sogar möglich, diese Teile des Prozesses zu automatisieren, indem beispielsweise PolyBase anstelle von Fast Load oder MLOAD verwendet wird. Wenn es sich bei den exportierten Dateien um Parquet-Dateien handelt, können Sie einen nativen Parquet-Reader verwenden, der eine schnellere Option als PolyBase darstellt. 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, Teradata SQL auf Kompatibilität mit Azure Synapse zu testen, besteht darin, einige repräsentative SQL-Anweisungen in den Teradata-Protokollen 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 Teradata SQL und gespeicherten Prozeduren in 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 Teradata
Auswahlmöglichkeiten beim Laden von Daten aus Teradata
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 Teradata-DataWarehouse 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 Teradata-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 befolgt werden kann.
Nachdem die zu migrierenden Datenbanktabellen in Azure Synapse erstellt wurden, können Sie die Daten, mit denen diese Tabellen aufgefüllt werden, aus dem Teradata-Legacysystem in die neue Umgebung verschieben. Dabei gibt es grundsätzlich zwei Ansätze:
Dateiextraktion: Extrahieren Sie die Daten aus den Teradata-Tabellen in Flatfiles, normalerweise im CSV-Format, über BTEQ, Fast Export oder Teradata Parallel Transporter (TPT). Dabei sollte nach Möglichkeit TPT verwendet werden, da diese Option den effizientesten Datendurchsatz bietet.
Bei diesem Ansatz wird Speicherplatz zum Speichern der extrahierten Datendateien benötigt. Dabei kann sich der Speicherplatz lokal in der Teradata-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 das Netzwerk umgangen 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: so z.B. 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 zum Verschieben von Dateien auf ein physisches Speichergerät, das dann zum Laden an ein Azure-Rechenzentrum versendet wird. Weitere Informationen finden Sie unter Datenübertragung.
Direktes Extrahieren und Laden über das Netzwerk: Die Azure-Zielumgebung sendet (in der Regel über einen SQL-Befehl) eine Anforderung zum Extrahieren von Daten an das Teradata-Legacysystem, um die Daten zu extrahieren. 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 Teradata-Datenbank und Azure-Umgebung. Bei sehr großen Datenmengen ist dieser Ansatz möglicherweise nicht praktikabel.
Es gibt auch einen Hybridansatz mit beiden Methoden. 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 befolgen. Für umfangreiche historische Faktentabellen können Sie den Ansatz der Dateiextraktion und -übertragung mit Azure Data Box wählen.
Orchestrierung durch Teradata oder Azure?
Zum möglichst effizienten Laden von Daten wird empfohlen, beim Umstieg auf 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. Bei diesem Ansatz werden die Möglichkeiten von Azure genutzt, um wiederverwendbare Datenladepipelines einfach zu erstellen.
Weitere Vorteile dieses Ansatzes sind geringere Auswirkungen auf das Teradata-System während des Datenladeprozesses, da der Verwaltungs- und Ladeprozess in Azure erfolgt, sowie die Möglichkeit, den Prozess durch Verwendung metadatengesteuerter Pipelines zum Laden von Daten zu automatisieren.
Welche Tools können eingesetzt werden?
Die Aufgabe der Datentransformation und -verschiebung ist die Grundfunktion aller ETL-Produkte. Wenn in der vorhandenen Teradata-Umgebung bereits eines dieser Produkte im Einsatz ist, lässt sich die Datenmigration von Teradata 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 der Azure-Cloud zu profitieren und Ressourcen im Teradata-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 Teradata zu Azure Synapse wie folgt:
Planen Sie im Vorfeld, um eine erfolgreiche Migration zu gewährleisten.
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.
Erwägen Sie den Einsatz einer Teradata-Instanz in einer Azure-VM als Ausgangspunkt zum Auslagern der Migration aus der alten Teradata-Legacyumgebung.
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 Teradata- und Azure-Umgebungen. Verwenden Sie in den einzelnen Phasen des Prozesses die jeweils geeigneten Tools.
Verwenden Sie Azure-Lösungen wie Azure Synapse-Pipelines oder Azure Data Factory, um den Migrationsprozess zu orchestrieren und zu automatisieren und gleichzeitig die Auswirkungen auf das Teradata-System zu minimieren.
Nächste Schritte
Weitere Informationen zu Sicherheit, Zugriff und Vorgängen finden Sie im nächsten Artikel in dieser Reihe: Sicherheit, Zugriff und Vorgänge für Teradata-Migrationen.
FAQs
What is the difference between ETL and ELT in Azure Synapse? ›
Extract, load, and transform (ELT) differs from ETL solely in where the transformation takes place. In the ELT pipeline, the transformation occurs in the target data store. Instead of using a separate transformation engine, the processing capabilities of the target data store are used to transform data.
Is Azure Synapse analytics an ETL tool? ›Traditional SMP dedicated SQL pools use an Extract, Transform, and Load (ETL) process for loading data. Synapse SQL, within Azure Synapse Analytics, uses distributed query processing architecture that takes advantage of the scalability and flexibility of compute and storage resources.
What is the difference between Teradata and Azure Synapse? ›Teradata provides stored procedure language to create stored procedures. Azure Synapse supports stored procedures by using T-SQL. If you migrate stored procedures to Azure Synapse, you must recode them by using T-SQL.
Is Teradata a ETL tool? ›With some very robust capabilities to Ingest, Analyze and Manage the data, Teradata checks all the boxes in terms of Integration (or ETL).
Which ETL tool is used in Azure? ›Integrate.io is one of the most reliable ETL tools for Azure Data Warehouse. It comes with over 100 out-of-the-box connectors that sync data to warehouses like Azure, as well as data lakes and other destinations.
What is the difference between Azure Synapse Analytics and stream analytics? ›Azure Synapse Analytics seamlessly supports both enterprise data warehousing and big data analytics workloads. Azure Stream Analytics is a serverless stream processing PaaS service that can scale with customer's needs.
What are the 3 components of Azure Synapse Analytics? ›What are the main components of Azure Synapse Analytics? An Azure analytics service that brings together data integration, enterprise data warehousing, and big data analytics.
What is the difference between dataflow and Synapse? ›Data flows provide an entirely visual experience with no coding required. Your data flows run on Synapse-managed execution clusters for scaled-out data processing. Azure Synapse Analytics handles all the code translation, path optimization, and execution of your data flow jobs.
How ETL is performed on Azure? ›- Prerequisites. ...
- Gather the information that you need. ...
- Create an Azure Databricks service. ...
- Create a Spark cluster in Azure Databricks. ...
- Create a file system in the Azure Data Lake Storage Gen2 account. ...
- Ingest sample data into the Azure Data Lake Storage Gen2 account. ...
- Extract data from the Azure Data Lake Storage Gen2 account.
Synapse allows you to collect, transform, and analyze data from just one platform. However, Azure Data Factory is only suitable for data engineers to streamline data collection processes with in-built processes. If you only want to connect and transform data without writing code, you should embrace Azure Data Factory.
What SQL is used in Azure Synapse? ›
Azure Synapse SQL is a big data analytic service that enables you to query and analyze your data using the T-SQL language. You can use standard ANSI-compliant dialect of SQL language used on SQL Server and Azure SQL Database for data analysis.
When to use Azure Synapse vs Azure SQL? ›Azure Synapse Analytics is specifically designed to handle large-scale analytical workloads, while Azure SQL Database is better suited for smaller analytical workloads. Azure Synapse Analytics provides built-in support for advanced analytics tools like Apache Spark and machine learning services.
Is Teradata outdated? ›Teradata Replication Services (Teradata-to Teradata-replication) was discontinued for new sales as of August 2011. Aligned with that discontinuation, no further enhancements have been made since the TRS 13.10 release.
Is Teradata still being used? ›Although it took a while for Teradata to transition to the cloud, they are making great strides to innovate and provide a great cloud offering. Teradata Vantage is still a good choice to consider for many clients already using Teradata applications.
Is Teradata same as SQL? ›Teradata systems allow the implementation of SQL to interact with the data in the database easily. It also provides its own extension.
Which cloud ETL tool is best? ›Informatica PowerCenter is one of the best ETL tools on the market. It has a wide range of connectors for cloud data warehouses and lakes, including AWS, Azure, Google Cloud, and SalesForce. Its low- and no-code tools are designed to save time and simplify workflows.
What is the best ETL tool for data science? ›- Talend.
- IBM Datacap.
- Mozenda.
- Octoparse.
- OnBase.
- Amazon Redshift.
- Google BigQuery.
- Microsoft Azure.
There are various Microsoft SQL ETL tools, including Integrate.io, Talend, Informatica PowerCenter, Fivetran, and SSIS. Not all ETL tools are created equal. You must choose the ETL tool that fits your specific needs.
What is the difference between SQL and Azure Synapse? ›Azure SQL DB provides an easy-to-maintain data storage with predictable cost structures while Azure synapse provides control and features such as pausing computational tasks in order to efficiently manage costs.
What is the difference between Azure Synapse analytics and Databricks SQL? ›Azure Synapse utilizes a 3-component architecture; Data storage, processing, and visualization in a single, unified platform. On the other hand, Databricks utilizes a lakehouse architecture that enables the best data warehouse and data lake features into one continuous platform.
What are the different types of data analytics Azure? ›
- Azure Synapse Analytics. ...
- Design AI with Apache Spark™-based analytics.
- Microsoft Purview. ...
- Hybrid data integration at enterprise scale, made easy.
- Provision cloud Hadoop, Spark, R Server, HBase, and Storm clusters.
- Azure Stream Analytics. ...
- Azure Machine Learning. ...
- Enterprise-grade analytics engine as a service.
Each entity also has three system properties that specify a partition key, a row key, and a timestamp.
What are the three main components of Azure cloud? ›Compute, Storage, and Fabric comprises the three main components of Windows Azure. Microsoft Azure Compute: Windows Azure provides a code that the hosting environment can control. Through components, it provides the calculating benefit.
What type of database is Azure Synapse? ›Azure Synapse Analytics is an unlimited information analysis service aimed at large companies that was presented as the evolution of Azure SQL Data Warehouse (SQL DW), bringing together business data storage and macro or Big Data analysis.
What is better than Synapse? ›Snowflake typically outperforms Synapse significantly with no fine-tuning, as with every cloud data platform, because it is a SaaS service while Synapse is a PaaS-based solution.
Why use dataflow instead of dataset? ›With dataflows, users can pick and choose the entities they want, but a dataset can only be reused as-is. Dataflow entities can be used as data sources in the same Power BI Desktop file as other data sources, and can serve as part of a mashup or composite model, but a dataset can only be reused as-is.
Why Synapse is better than Databricks? ›Azure Synapse vs Databricks: What is the Difference? Azure Synapse successfully integrates analytical services to bring enterprise data warehouse and big data analytics into a single platform. On the other hand, Databricks not only does big data analytics but also allows users to build complex ML products at scale.
What is the ETL architecture pattern? ›ETL architecture is a “blueprint” for how your ETL processes will execute from start to finish. It describes how data will flow from the source to target locations, as well as a list of the transformations you will execute when moving this data.
What is the difference between ETL and Azure Data Factory? ›An ETL tool extracts, transforms, and loads data. SQL Server Integration Service (SSIS) is an on-premises ETL technology intended for use in on-premises applications. Azure Data Factory is a data pipeline orchestrator based in the cloud.
What is an example of an ETL? ›A use case example of an ETL process would be a retail company that is looking to improve data management and analyse sales data from various store locations. The data could be collated to provide a complete overview of the company's operations, enabling them to reallocate resources to expand the business.
Does Azure Data Factory require coding? ›
Azure Data Factory is Azure's cloud ETL service for scale-out serverless data integration and data transformation. It offers a code-free UI for intuitive authoring and single-pane-of-glass monitoring and management.
Is Azure Synapse a SQL data warehouse? ›Azure Synapse Analytics is an analytics service that brings together enterprise data warehousing and Big Data analytics. Dedicated SQL pool (formerly SQL DW) refers to the enterprise data warehousing features that are available in Azure Synapse Analytics.
What's the difference between Azure Blob Storage and Azure Synapse analytics? ›Key Differences
Blob: General purpose object store for a wide variety of storage scenarios, including big data analytics. ADLS: Optimized storage for big data analytics workloads. Blob: Good storage retrieval performance. ADLS: Better storage retrieval performance.
Azure Synapse is primarily a Platform as a Service (PaaS) solution with free Azure Synapse Workspace development environment on top of those resources.
What is the difference between data lake and Synapse? ›A Data Lake is storage layer or centralized repository for all structured and unstructured data at any scale. In Synapse, a default or primary data lake is provisioned when you create a Synapse workspace.
What are the 2 SQL pools in Azure Synapse? ›Background on Synapse SQL Pools
There are a few ways to Query Data in Azure Synapse, you have SQL Pool and then Apache Spark Pools. There are 2 types of SQL Pool: Dedicated and Serverless. In a subsequent post I focused on Serverless SQL Pool formerly known as SQL On-Demand.
Snowflake is a serverless solution with fully independent storage and computation processing layers based on the ANSI SQL. Azure Synapse consists of built-in support for AzureML to handle machine learning workflows. A robust machine-learning environment is available at Databricks for the creation of various models.
What is the difference between Microsoft SQL Server and Azure SQL? ›SQL virtual machines offer full administrative control over the SQL Server instance and underlying OS for migration to Azure. The most significant difference from SQL Database and SQL Managed Instance is that SQL Server on Azure Virtual Machines allows full control over the database engine.
What is the difference between SQL Server and Synapse workspace? ›While a traditional SQL database is dependent on the computational resources of a single machine, a Synapse SQL Pool can distribute the processing of tables across up to 60 compute nodes depending on the service level. The more DWU's you've assigned, the more compute nodes will be used.
What is the difference between Oracle and Teradata database? ›Oracle is mainly used as an online back-end application. It manages inserts, updates, and deletes in a transaction, whereas Teradata is Data Warehousing application which maintains big data for analytics. There is no such thing as real-time transactions in Teradata.
What is the advantage of Informatica over Teradata? ›
First up, Informatica is a data integration tool, while Teradata is an MPP database with some scripting and fast data movement capabilities. Advantages of Informatica over Teradata: It functions as a metadata repository for the organization's ETL ecosystem.
Is Teradata and Informatica the same? ›Aspirants looking to foray into database management and electing Informatica training should clearly understand the difference between Informatica and Teradata. Teradata is a database, used for storing large amount of data. Whereas Informatica is an ETL tool, used for loading data and export functions.
Does Netflix use Teradata? ›Netflix used Teradata technologies to manage its vast data sets and extract insights that inform its business decisions. Teradata is a data warehousing and analytics company that provides tools for managing large-scale data processing and analytics.
Why Snowflake is better than Teradata? ›Snowflake offers better elasticity and flexibility due to its cloud-based architecture, while Teradata is a well-tuned, traditional system with more robust workload management features. Choosing between the two depends on your organization's specific needs and requirements.
Who is Teradata competition? ›We have compiled a list of solutions that reviewers voted as the best overall alternatives and competitors to Teradata Vantage, including Microsoft SQL Server, Google Cloud BigQuery, Snowflake, and IBM Db2.
Is Teradata an ETL? ›With some very robust capabilities to Ingest, Analyze and Manage the data, Teradata checks all the boxes in terms of Integration (or ETL).
Is Teradata a big data technology? ›Teradata is among the most widely used Relational database management systems (RDBMS). Teradata is ideal for big data warehousing applications. Teradata is capable of handling massive amounts of data and is extremely scalable.
What is the main difference between the ELT and ETL process? ›ETL is most appropriate for processing smaller, relational data sets which require complex transformations and have been predetermined as being relevant to the analysis goals. ELT can handle any size or type of data and is well suited for processing both structured and unstructured big data.
What is the key difference between ETL and ELT? ›ETL transforms data on a separate processing server, while ELT transforms data within the data warehouse itself. ETL does not transfer raw data into the data warehouse, while ELT sends raw data directly to the data warehouse.
What is ETL and ELT? ›ELT (extract, load, transform) and ETL (extract, transform, load) are both data integration processes that move raw data from a source system to a target database, such as a data lake or data warehouse.
Is Azure data Factory an ETL tool or ELT? ›
Azure Data Factory is a managed cloud service that's built for these complex hybrid extract-transform-load (ETL), extract-load-transform (ELT), and data integration projects.
Is ELT replacing ETL? ›Whether ELT replaces ETL depends on the use case. While ELT is adopted by businesses that work with big data, ETL is still the method of choice for businesses that process data from on-premises to the cloud.
Is Snowflake an ETL tool? ›Snowflake supports both ETL and ELT and works with a wide range of data integration tools, including Informatica, Talend, Tableau, Matillion and others.
Why is ELT preferred over ETL? ›The primary advantage of ELT over ETL relates to flexibility and ease of storing new, unstructured data. With ELT, you can save any type of information—even if you don't have the time or ability to transform and structure it first—providing immediate access to all of your information whenever you want it.
What are the different ETL categories? ›Types of ETL Tools. ETL tools can be grouped into four categories based on their infrastructure and supporting organization or vendor. These categories — enterprise-grade, open-source, cloud-based, and custom ETL tools — are defined below.
What is the difference between ETL process and ETL pipeline? ›ETL refers to a set of processes extracting data from one system, transforming it, and loading it into a target system. A data pipeline is a more generic term; it refers to any set of processing that moves data from one system to another and may or may not transform it.
What is the difference between data integration and ETL tools? ›Data integration refers to the process of combining data from different sources into a single, unified view. ETL is a specific type of data integration that involves extracting data from one or more sources, transforming it to fit the target system's needs, and loading it into the target system.
How many types of transformations are used in ETL? ›8 TYPES OF ETL DATA TRANSFORMATIONS AND HOW TO AUTOMATE THEM. Working with raw or unprocessed data often leads to poor decision-making.
What is an example of ETL and ELT? ›For example, an ELT tool may extract data from various source systems and store them in a data lake, made up of Amazon S3 or Azure Blob Storage. An ETL process can extract the data from the lake after that, transform it and load into a data warehouse for reporting.
What is the next stage after performing ETL on the data? ›The 5 steps of the ETL process are: extract, clean, transform, load, and analyze. Of the 5, extract, transform, and load are the most important process steps. Clean: Cleans data extracted from an unstructured data pool, ensuring the quality of the data prior to transformation.
How long it will take to learn Azure Data Factory? ›
Azure Data Factory Training program will have a duration of 3 months.
Which SQL is used for Azure Data Factory? ›Once in the ADF UX, you'll configure three linked service for each of the data stores we are using: Azure SQL DB, ADLS Gen2, and Azure Synapse Analytics. In Azure Data Factory linked services define the connection information to external resources.