Minimieren von SQL Problemen beim Migrieren von Teradata

Bei diesem Artikel handelt es sich um Teil 5 einer siebenteiligen Reihe, die einen Leitfaden zum Migrieren von Teradata zu Azure Synapse Analytics bereitstellt. In diesem Artikel werden schwerpunktmäßig bewährte Methoden zum Minimieren von SQL-Problemen behandelt.

Übersicht

Merkmale von Teradata-Umgebungen

Teradata veröffentlichte 1984 sein Datenbankprodukt. Das Unternehmen führte massiv parallele Verarbeitungstechniken (MPP) ein, um die Datenverarbeitung in einem effizienteren Umfang zu ermöglichen als die damals verfügbaren Mainframetechnologien. Seitdem hat sich das Produkt weiterentwickelt und ist bei vielen großen Finanzinstituten sowie Telekommunikations- und Einzelhandelsunternehmen installiert. Die ursprüngliche Implementierung verwendete proprietäre Hardware mit Mainframe-Kanalverbindungen – in der Regel IBM- oder IBM-kompatible Prozessoren.

Zwar wurden in letzter Zeit Netzwerkkonnektivität und die Verfügbarkeit des Teradata-Technologiestacks in der Cloud (einschließlich Azure) angekündigt, doch die meisten bestehenden Installationen sind lokal, sodass viele Benutzer in Erwägung ziehen, einige oder alle ihrer Teradata-Daten zu Azure Synapse Analytics zu migrieren, um von den Vorteilen eines Wechsels zu einer modernen Cloudumgebung zu profitieren.

Teradata-Technologie dient häufig zur Implementierung eines Data Warehouse, das komplexe analytische Abfragen großer Datenvolumen mittels SQL unterstützt. Dimensionale Datenmodelle wie Stern- oder Schneeflockenschemas sind ebenso üblich wie die Implementierung von Data Marts für einzelne Abteilungen.

Diese Kombination aus SQL und dimensionalen Datenmodellen vereinfacht die Migration zu Azure Synapse, da die grundlegenden Konzepte und SQL-Kenntnisse übertragbar sind. Der empfohlene Ansatz ist die Migration des vorhandenen Datenmodells im Ist-Zustand, um Risiken und Zeitaufwand zu reduzieren. Selbst wenn Sie die Absicht haben, das Datenmodell zu ändern (z. B. auf ein Datentresormodell umzusteigen), sollten Sie zunächst eine Migration des Ist-Zustands durchführen und die Änderungen dann in der Cloudumgebung von Azure vornehmen, um dort die in den Genuss von Leistung, elastischer Skalierbarkeit und Kostenvorteilen zu kommen.

Obwohl die Sprache SQL standardisiert wurde, haben einzelne Anbieter in einigen Fällen proprietäre Erweiterungen implementiert. In diesem Dokument werden potenzielle SQL-Unterschiede hervorgehoben, auf die Sie bei der Migration von einer älteren Teradata-Umgebung stoßen können, und entsprechende Umgehungsmöglichkeiten aufgezeigt.

Verwenden einer Teradata-Instanz auf einer Azure-VM als Teil einer Migration

Nutzen Sie die Azure-Umgebung, wenn Sie eine Migration von einer lokalen Teradata-Umgebung durchführen. Azure bietet günstigen Cloudspeicher und elastische Skalierbarkeit, um eine Teradata-Instanz in einer VM in Azure zu erstellen, die mit der Azure Synapse-Zielumgebung zusammenarbeitet.

Bei diesem Ansatz können standardmäßige Teradata-Hilfsprogramme wie Teradata Parallel Data Transporter (oder Datenreplikationstools von Drittanbietern wie Attunity Replicate) verwendet werden, um die Teilmenge der zu migrierenden Teradata-Tabellen effizient auf die VM-Instanz zu verschieben. Anschließend können alle Migrationsaufgaben in der Azure-Umgebung ausgeführt werden. Dieser Ansatz hat mehrere Vorteile:

• Nach der ersten Replikation von Daten wird das Quellsystem von den Migrationsaufgaben nicht weiter beeinträchtigt.

• Die vertrauten Teradata-Schnittstellen, -Tools und -Hilfsprogramme sind in der Azure-Umgebung verfügbar.

• In der Azure-Umgebung gibt es keine potenziellen Probleme mehr mit der Verfügbarkeit von Netzwerkbandbreite zwischen dem lokalen Quellsystem und dem Cloudzielsystem.

• Tools wie Azure Data Factory können effizient Hilfsprogramme wie Teradata Parallel Transporter aufrufen, um Daten schnell und einfach zu migrieren.

• Der Migrationsprozess wird vollständig in der Azure-Umgebung orchestriert und gesteuert.

Verwenden von Azure Data Factory zum Implementieren einer metadatengesteuerten Migration

Automatisieren und orchestrieren Sie den Migrationsprozess, indem Sie die Möglichkeiten der Azure-Umgebung nutzen. Bei dieser Vorgehensweise werden auch die Auswirkungen auf die vorhandene Teradata-Umgebung (die möglicherweise bereits fast voll ausgelastet ist) minimiert.

Azure Data Factory ist ein cloudbasierter Datenintegrationsdienst, mit dem Sie datengesteuerte Workflows in der Cloud erstellen können, um Datenverschiebungen und Datentransformationen zu orchestrieren und zu automatisieren. Mit Data Factory können Sie datengesteuerte Workflows (sog. Pipelines) erstellen und planen, die Daten aus unterschiedlichen Datenspeichern erfassen. Die Anwendung kann diese mithilfe von Computediensten wie Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics und Azure Machine Learning verarbeiten und transformieren.

Indem Sie Metadaten zum Auflisten der zu migrierenden Datentabellen und deren Speicherort erstellen, können Sie die Möglichkeiten von Data Factory zum Verwalten und Automatisieren von Teilen des Migrationsprozesses nutzen. Sie können auch Azure Synapse Pipelines verwenden.

SQL DDL-Unterschiede zwischen Teradata und Azure Synapse

SQL DDL (Data Definition Language, Datendefinitionssprache)

Der ANSI SQL-Standard definiert die grundlegende Syntax für DDL-Befehle wie CREATE TABLE und CREATE VIEW. Diese Befehle kommen sowohl in Teradata als auch in Azure Synapse zum Einsatz, wurden aber auch erweitert, um die Definition implementierungsspezifischer Features wie Indizierung, Tabellenverteilung und Partitionierungsoptionen zu ermöglichen.

In den folgenden Abschnitten werden Teradata-spezifische Optionen erörtert, die Sie bei einer Migration zu Azure Synapse berücksichtigen sollten.

Überlegungen zu Tabellen

Bei der Migration von Tabellen zwischen unterschiedlichen Technologien werden nur die Rohdaten und ihre beschreibenden Metadaten physisch zwischen den beiden Umgebungen verschoben. Andere Datenbankelemente aus dem Quellsystem wie Indizes und Protokolldateien werden nicht direkt migriert, da diese möglicherweise nicht benötigt werden oder in der neuen Umgebung anders implementiert werden. Beispielsweise gibt es keine Entsprechung der MULTISET-Option in der CREATE TABLE-Syntax von Teradata.

Es ist wichtig zu verstehen, wo Leistungsoptimierungen, wie z. B. Indizes, in der Quellumgebung verwendet wurden. Dadurch werden Hinweise gegeben, wo in der neuen Umgebung Leistungsoptimierungen möglich sind. Wenn beispielsweise ein nicht eindeutiger sekundärer Index (Non-Unique Secondary Index, NUSI) in der Teradata-Quellumgebung erstellt wurde, könnte dies ein Hinweis darauf sein, dass ein nicht gruppierter Index in der migrierten Azure Synapse-Datenbank erstellt werden sollte. Andere native Techniken zur Leistungsoptimierung, wie z. B. Tabellenreplikation, sind möglicherweise besser geeignet als eine reine gleichartige Indexerstellung.

Nicht unterstützte Teradata-Tabellentypen

Teradata bietet Unterstützung für spezielle Tabellentypen für Zeitreihen und temporale Daten. Die Syntax und einige Funktionen für diese Tabellentypen werden in Azure Synapse nicht direkt unterstützt. Die Daten können aber mit entsprechenden Datentypen und Indizierung oder Partitionierung für die Datums-/Uhrzeitspalte in eine Standardtabelle migriert werden.

Teradata implementiert die Funktion für temporale Abfrage über das Umschreiben von Abfragen, um zusätzliche Filter in einer temporalen Abfrage hinzuzufügen und so den betreffenden Datumsbereich einzuschränken. Wenn diese Funktion derzeit in der Teradata-Quellumgebung verwendet wird und migriert werden soll, muss diese zusätzliche Filterung den entsprechenden temporalen Abfragen hinzugefügt werden.

Die Azure-Umgebung enthält auch spezifische Features für komplexe Analysen von Zeitreihendaten in großem Umfang namens Time Series Insights – dies richtet sich an IoT-Datenanalyseanwendungen und eignet sich möglicherweise für diesen Anwendungsfall.

Nicht unterstützte Teradata-Datentypen

In Azure Synapse gibt es eine direkte Entsprechung für die meisten Teradata-Datentypen. In der folgenden Tabelle ist neben den Teradata-Datentypen, die in Azure Synapse nicht unterstützt werden, auch die empfohlene Zuordnung aufgeführt. In der Tabelle ist der Teradata-Spaltentyp der Typ, der im Systemkatalog gespeichert ist (z. B. in DBC.ColumnsV).

Verwenden Sie die Metadaten aus den Teradata-Katalogtabellen, um festzulegen, ob diese Datentypen migriert werden sollen, und planen Sie dies im Migrationsplan ein. Verwenden Sie beispielsweise eine SQL-Abfrage wie diese, um beliebige Vorkommen nicht unterstützter Datentypen zu finden, die Aufmerksamkeit erfordern.

SELECT
ColumnType, CASE
WHEN ColumnType = '++' THEN 'TD_ANYTYPE' 
WHEN ColumnType = 'A1' THEN 'ARRAY' WHEN 
ColumnType = 'AN' THEN 'ARRAY' WHEN 
ColumnType = 'BO' THEN 'BLOB'
WHEN ColumnType = 'CO' THEN 'CLOB'
WHEN ColumnType = 'DH' THEN 'INTERVAL DAY TO HOUR' WHEN 
ColumnType = 'DM' THEN 'INTERVAL DAY TO MINUTE' WHEN 
ColumnType = 'DS' THEN 'INTERVAL DAY TO SECOND' WHEN
ColumnType = 'DT' THEN 'DATASET'
WHEN ColumnType = 'DY' THEN 'INTERVAL DAY'
WHEN ColumnType = 'HM' THEN 'INTERVAL HOUR TO MINUTE' WHEN
ColumnType = 'HR' THEN 'INTERVAL HOUR'
WHEN ColumnType = 'HS' THEN 'INTERVAL HOUR TO SECOND' WHEN
ColumnType = 'JN' THEN 'JSON'
WHEN ColumnType = 'MI' THEN 'INTERVAL MINUTE' WHEN 
ColumnType = 'MO' THEN 'INTERVAL MONTH'
WHEN ColumnType = 'MS' THEN 'INTERVAL MINUTE TO SECOND' WHEN
ColumnType = 'PD' THEN 'PERIOD(DATE)'
WHEN ColumnType = 'PM' THEN 'PERIOD (TIMESTAMP WITH TIME ZONE)'
WHEN ColumnType = 'PS' THEN 'PERIOD(TIMESTAMP)' WHEN 
ColumnType = 'PT' THEN 'PERIOD(TIME)'
WHEN ColumnType = 'PZ' THEN 'PERIOD (TIME WITH TIME ZONE)' WHEN
ColumnType = 'SC' THEN 'INTERVAL SECOND'
WHEN ColumnType = 'SZ' THEN 'TIMESTAMP WITH TIME ZONE' WHEN
ColumnType = 'XM' THEN 'XML'
WHEN ColumnType = 'YM' THEN 'INTERVAL YEAR TO MONTH' WHEN
ColumnType = 'YR' THEN 'INTERVAL YEAR'
END AS Data_Type,
COUNT (*) AS Data_Type_Count FROM
DBC.ColumnsV
WHERE DatabaseName IN ('UserDB1', 'UserDB2', 'UserDB3') -- select databases to be migrated
GROUP BY 1,2
ORDER BY 1;

Bestimmte Drittanbieter bieten Tools und Dienste zum Automatisieren der Migration an, einschließlich der Zuordnung von Datentypen. Wenn bereits in der Teradata-Umgebung ein ETL-Tool von Drittanbietern wie Informatica oder Talend verwendet wird, können diese Tools außerdem alle erforderlichen Datentransformationen implementieren.

Generierung von DDL-Anweisungen (Data Definition Language, Datendefinitionssprache)

Bearbeiten Sie die vorhandenen Teradata-Skripts CREATE TABLE und CREATE VIEW, um bei Bedarf die entsprechenden Definitionen mit geänderten Datentypen wie zuvor beschrieben zu erstellen. In der Regel umfasst dies das Entfernen zusätzlicher Teradata-spezifischer Klauseln wie FALLBACK oder MULTISET.

Alle Informationen, die sich auf die aktuellen Definitionen von Tabellen und Sichten in der vorhandenen Teradata-Umgebung beziehen, werden jedoch in den Systemkatalogtabellen verwaltet. Dies ist die beste Quelle für diese Informationen, da sie garantiert aktuell und vollständig ist. Beachten Sie, dass die von Benutzern gepflegte Dokumentation möglicherweise nicht mit den aktuellen Tabellendefinitionen synchron ist.

Greifen Sie über Sichten im Katalog wie z. B. DBC.ColumnsV auf diese Informationen zu, und generieren Sie die entsprechenden CREATE TABLE-DDL-Anweisungen für die entsprechenden Tabellen in Azure Synapse.

Es gibt Microsoft-Partner, die Tools und Dienste zur Automatisierung der Migration anbieten, einschließlich Datentypzuordnung. Wenn bereits in der Teradata-Umgebung ein ETL-Tool von Drittanbietern wie Informatica oder Talend verwendet wird, kann dieses Tool außerdem alle erforderlichen Datentransformationen implementieren.

SQL DML-Unterschiede zwischen Teradata und Azure Synapse

SQL DML (Data Manipulation Language, Datenbearbeitungssprache)

Der ANSI SQL-Standard definiert die grundlegende Syntax für DML-Befehle wie SELECT, INSERT, UPDATE und DELETE. Sowohl Teradata als auch Azure Synapse verwenden diese Befehle, aber in einigen Fällen gibt es Implementierungsunterschiede.

In den folgenden Abschnitten werden die Teradata-spezifischen DML-Befehle erläutert, die Sie bei einer Migration zu Azure Synapse berücksichtigen sollten.

Syntaxunterschiede in SQL DML

Berücksichtigen Sie bei der Migration die folgenden Syntaxunterschiede in der SQL-Datenbearbeitungssprache (Data Manipulation Language, DML) zwischen Teradata SQL und Azure Synapse (T-SQL):

• QUALIFY: Teradata unterstützt den Operator QUALIFY. Beispiel:

  SELECT col1
  FROM tab1
  WHERE col1='XYZ'
  QUALIFY ROW_NUMBER () OVER (PARTITION by
  col1 ORDER BY col1) = 1;
  

  Die Entsprechung in der Azure Synapse-Syntax lautet wie folgt:

  SELECT * FROM (
  SELECT col1, ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) rn
  FROM tab1 WHERE col1='XYZ'
  ) WHERE rn = 1;
  

• Datumsarithmetik: Azure Synapse verfügt über Operatoren wie z. B. DATEADD und DATEDIFF, die für die Felder DATE oder DATETIME verwendet werden können. Teradata unterstützt die direkte Subtraktion für Datumsangaben, wie z. B. SELECT DATE1 - DATE2 FROM....

• Geben Sie im Ordinal GROUP BY den T-SQL-Spaltennamen explizit an.

• LIKE ANY: Teradata unterstützt LIKE ANY-Syntax wie z. B.:

  SELECT * FROM CUSTOMER
  WHERE POSTCODE LIKE ANY
  ('CV1%', 'CV2%', 'CV3%');
  

  Die Entsprechung in der Azure Synapse-Syntax lautet:

  SELECT * FROM CUSTOMER
  WHERE
  (POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');
  

• Je nach Systemeinstellungen wird bei Zeichenvergleichen in Teradata ggf. nicht standardmäßig zwischen Groß- und Kleinschreibung unterschieden. In Azure Synapse wird bei Zeichenvergleichen stets Groß-/Kleinbuchschreibung unterschieden.

Verwenden von EXPLAIN zum Überprüfen von Legacy-SQL

Eine Möglichkeit, eine Legacyinstanz von Teradata SQL auf Kompatibilität mit Azure Synapse zu testen, besteht darin, einige repräsentative SQL-Anweisungen aus den Legacy-Systemabfrageprotokollen zu erfassen, diesen Abfragen EXPLAIN voranzustellen und (unter der Annahme eines gleichartigen migrierten Datenmodells in Azure Synapse mit denselben Tabellen- und Spaltennamen) diese EXPLAIN-Anweisungen in Azure Synapse auszuführen. Jedes inkompatible SQL löst einen Fehler aus – verwenden Sie diese Informationen, um den Umfang der Aufzeichnungsaufgabe zu bestimmen. Bei diesem Ansatz müssen keine Daten in die Azure-Umgebung geladen werden, sondern lediglich die entsprechenden Tabellen und Sichten erstellt werden.

Funktionen, gespeicherte Prozeduren, Trigger und Sequenzen

Bei der Migration von einer ausgereiften Legacy-Data Warehouse-Umgebung wie Teradata müssen häufig noch weitere Elemente als einfache Tabellen und Sichten zur neuen Zielumgebung migriert werden. Beispiele sind Funktionen, gespeicherte Prozeduren, Trigger und Sequenzen.

Machen Sie im Rahmen der Vorbereitungsphase eine Bestandsaufnahme der zu migrierenden Objekte, und bestimmen Sie die Methoden für deren Handhabung. Weisen Sie dann im Projektplan entsprechende Ressourcen zu.

Die Azure-Umgebung kann Möglichkeiten bieten, die die entweder als Funktionen oder gespeicherte Prozeduren in der Teradata-Umgebung implementierte Funktionalität ersetzen. In diesem Fall ist es oft effizienter, die in Azure integrierten Möglichkeiten zu verwenden, anstatt den Code der Teradata-Funktionen umzuprogrammieren.

Microsoft Partner bieten Tools und Dienste, die die Migration automatisieren können.

Weitere Informationen zu den einzelnen Elementen finden Sie in den folgenden Abschnitten.

Functions

Wie die meisten Datenbankprodukte unterstützt Teradata System- und benutzerdefinierte Funktionen innerhalb der SQL-Implementierung. Bei Migration auf eine andere Datenbankplattform wie Azure Synapse sind gängige Systemfunktionen verfügbar und können ohne Änderung migriert werden. Einige Systemfunktionen weisen möglicherweise eine etwas andere Syntax auf, aber die erforderlichen Änderungen können automatisiert werden. Systemfunktionen, für die es keine Entsprechung gibt, oder etwaige benutzerdefinierte Funktionen müssen möglicherweise mithilfe der in der Zielumgebung verfügbaren Sprachen umprogrammiert werden. In Azure Synapse werden benutzerdefinierte Funktionen mithilfe der weit verbreiteten Sprache „Transact-SQL“ implementiert.

Gespeicherte Prozeduren

Bei den meisten modernen Datenbankprodukten können Prozeduren in der Datenbank gespeichert werden. Teradata stellt zu diesem Zweck die SPL-Sprache bereit. Eine gespeicherte Prozedur enthält normalerweise SQL-Anweisungen und prozedurale Logik und kann Daten oder einen Status zurückgeben.

Die dedizierten SQL-Pools von Azure Synapse Analytics unterstützen auch gespeicherte Prozeduren mithilfe von T-SQL. Wenn Sie gespeicherte Prozeduren migrieren müssen, codieren Sie sie also entsprechend neu.

Auslöser

Azure Synapse unterstützt nicht die Erstellung von Triggern, aber Sie können sie in Azure Data Factory implementieren.

Sequenzen

Azure Synapse-Sequenzen werden ähnlich wie Teradata behandelt, indem IDENTITY zum Erstellen von Ersatzschlüsseln oder eine verwaltete Identität verwendet wird.

Zuordnung von Teradata zu T-SQL

Diese Tabelle zeigt die mit Azure Synapse SQL-Datentypen kompatible Zuordnung von Teradata zu T-SQL:

Zusammenfassung

Typische bestehende Legacy-Installationen von Teradata sind so implementiert, dass die Migration zu Azure Synapse problemlos erfolgen kann. Sie nutzen SQL für analytische Abfragen großer Datenvolumen und liegen in Form eines dimensionalen Datenmodells vor. Dadurch sind sie gut für die Migration zu Azure Synapse geeignet.

Um die Aufgabe der Migration des tatsächlichen SQL-Codes zu minimieren, folgen Sie diesen Empfehlungen:

• Die anfängliche Migration des Data Warehouse sollte im Ist-Zustand erfolgen, um Risiken und Zeitaufwand zu minimieren, auch wenn die endgültige Umgebung ein anderes Datenmodell, wie z. B. einen Datentresor, vorsieht.

• Erwägen Sie die Verwendung einer Teradata-Instanz in einer Azure-VM als Sprungbrett im Rahmen des Migrationsprozesses.

• Machen Sie sich mit den Unterschieden bei der Implementierung von SQL von Teradata und Azure Synapse vertraut.

• Verwenden Sie Metadaten und Abfrageprotokolle aus der vorhandenen Teradata-Implementierung, um die Auswirkungen der Unterschiede zu bewerten und einen Ansatz zur Abhilfe zu planen.

• Automatisieren Sie den Prozess so weit wie möglich, um Fehler, Risiken und Zeitaufwand für die Migration zu minimieren.

• Erwägen Sie das Hinzuziehen spezialisierter Microsoft-Partner und -Dienste, um die Migration zu optimieren.

Nächste Schritte

Weitere Informationen zu Tools von Microsoft und Drittanbietern finden Sie im nächsten Artikel dieser Reihe: Tools für die Data Warehouse-Migration von Teradata zu Azure Synapse Analytics.