Migration von Teradata zu BigQuery: Übersicht

Dieses Dokument hilft Ihnen beim Verständnis der Entscheidungen, die Sie treffen müssen, wenn Sie BigQuery Data Transfer Service für die Migration des Schemas und der Daten von Teradata zu BigQuery nutzen.

Das Migrieren von Schemas und Daten ist in der Regel einer von mehreren Schritten, die zum Verschieben eines Data Warehouse von einer anderen Plattform nach BigQuery erforderlich sind. Eine Beschreibung des End-to-End-Migrationsprozesses finden Sie unter Übersicht: Data Warehouses zu BigQuery migrieren.

Verwenden Sie die Batch-SQL-Übersetzung, um Ihre SQL-Skripts im Bulk zu migrieren, oder die interaktive SQL-Übersetzung, um Ad-hoc-Abfragen zu übersetzen. Teradata SQL wird von beiden SQL-Übersetzungsdiensten vollständig unterstützt.

Überblick

Sie können BigQuery Data Transfer Service in Kombination mit einem speziellen Migrations-Agent verwenden, um Ihr Schema und Ihre Daten aus Teradata zu BigQuery zu kopieren. Der Migrations-Agent stellt eine Verbindung zu Ihrem lokalen Data Warehouse her und kommuniziert mit BigQuery Data Transfer Service, um Tabellen aus Ihrem Data Warehouse nach BigQuery zu kopieren.

Die folgenden Schritte beschreiben den Workflow für den Migrationsprozess:

  1. Laden Sie den Migrations-Agent herunter.
  2. Konfigurieren Sie eine Übertragung in BigQuery Data Transfer Service.
  3. Führen Sie den Übertragungsjob aus, um das Tabellenschema und die Daten aus Ihrem Data Warehouse nach BigQuery zu kopieren.
  4. Optional. Überwachen Sie Übertragungsjobs in der Google Cloud Console.

Übertragungsjobkonfiguration

Sie können einen Übertragungsjob entsprechend Ihren Anforderungen konfigurieren. Sehen Sie sich vor dem Einrichten einer Datenübertragung von Teradata zu BigQuery die in den folgenden Abschnitten beschriebenen Konfigurationsoptionen an und entscheiden Sie, welche Einstellungen verwendet werden sollen. Abhängig von den ausgewählten Einstellungen müssen Sie möglicherweise einige Voraussetzungen erfüllen, bevor Sie den Übertragungsjob starten.

Bei den meisten Systemen, insbesondere solchen mit großen Tabellen, können Sie so die beste Leistung erzielen:

  1. Partitionieren Sie Ihre Teradata-Tabellen.
  2. Verwenden Sie Teradata Parallel Transporter (TPT) für die Extraktion.
  3. Erstellen Sie eine benutzerdefinierte Schemadatei und konfigurieren Sie Ihre BigQuery-Zielspalten für Clustering und Partitionierung.

Dadurch kann der Migrations-Agent eine partitionweise Extraktion durchführen, was am effizientesten ist.

Extraktionsmethode

BigQuery Data Transfer Service unterstützt zwei Extraktionsmethoden für die Übertragung von Daten von Teradata zu BigQuery:

  • Verwenden Sie das Tbuild-Dienstprogramm Teradata Parallel Transporter (TPT). Dies ist der empfohlene Ansatz. Die Verwendung von TPT führt in der Regel zu einer schnelleren Datenextraktion.

    In diesem Modus versucht der Migrations-Agent, Extraktionsbatches mithilfe von Zeilen zu berechnen, die nach Partitionen verteilt sind. Für jeden Batch gibt der Agent ein TPT-Extraktionsskript aus, das einen Satz von durch Trennzeichen getrennten Dateien erzeugt, und führt es aus. Anschließend werden diese Dateien in einen Cloud Storage-Bucket hochgeladen, wo sie vom Übertragungsjob verwendet werden. Sobald die Dateien in Cloud Storage hochgeladen wurden, werden sie vom Migrations-Agent aus dem lokalen Dateisystem gelöscht.

    Wenn Sie die TPT-Extraktion ohne Partitionierungsspalte verwenden, wird die gesamte Tabelle extrahiert. Wenn Sie die TPT-Extraktion mit einer Partitionierungsspalte verwenden, extrahiert der Agent Partitionssätze.

    In diesem Modus beschränkt der Migrations-Agent nicht den Speicherplatz, den die extrahierten Dateien im lokalen Dateisystem beanspruchen. Achten Sie darauf, dass das lokale Dateisystem mehr Speicherplatz hat als die Größe Ihrer größten Partition oder Ihrer größten Tabelle, je nachdem, ob Sie eine Partitionierungsspalte angeben oder nicht.

  • Extraktion mit JDBC-Treiber und FastExport-Verbindung. Wenn es Einschränkungen in Bezug auf den lokalen Speicherplatz für extrahierte Dateien gibt oder wenn es einen Grund dafür gibt, dass Sie TPT nicht verwenden können, verwenden Sie diese Extraktionsmethode.

    In diesem Modus extrahiert der Migrations-Agent Tabellen in eine Sammlung von AVRO-Dateien im lokalen Dateisystem. Anschließend werden diese Dateien in einen Cloud Storage-Bucket hochgeladen, wo sie vom Übertragungsjob verwendet werden. Sobald die Dateien in Cloud Storage hochgeladen wurden, werden sie vom Migrations-Agent aus dem lokalen Dateisystem gelöscht.

    In diesem Modus können Sie den Speicherplatz beschränken, der von den AVRO-Dateien im lokalen Dateisystem belegt wird. Wenn dieses Limit überschritten wird, wird die Extraktion pausiert, bis der Migrations-Agent Speicherplatz freigibt, indem vorhandene AVRO-Dateien hochgeladen und gelöscht werden.

Schemaerkennung

BigQuery Data Transfer Service bietet eine automatische Schemaerkennung und Datentypzuordnung während einer Datenübertragung von Teradata zu BigQuery. Optional können Sie eine benutzerdefinierte Schemadatei angeben. Wir empfehlen in den folgenden Situationen die Schemaanpassung:

  • Sie müssen wichtige Informationen zu einer Tabelle erfassen, z. B. die Partitionierung, die ansonsten bei der Migration verloren gehen würden.

    Für inkrementelle Übertragungen sollte beispielsweise eine Schemadatei angegeben werden, damit Daten aus nachfolgenden Übertragungen beim Laden in BigQuery korrekt partitioniert werden können. Ohne Schemadatei wendet BigQuery Data Transfer Service bei jeder Ausführung automatisch ein Tabellenschema an, wobei die übertragenen Quelldaten verwendet werden. Informationen zu Partitionierung, Clustering, Primärschlüssel und Änderungsverfolgung gehen dabei verloren.

  • Sie müssen Spaltennamen oder Datentypen während der Datenübertragung ändern.

Benutzerdefinierte Schemadatei

Eine benutzerdefinierte Schemadatei ist eine JSON-Datei, die Datenbankobjekte beschreibt. Das Schema enthält einen Satz von Datenbanken, die jeweils einen Satz von Tabellen enthalten, von denen jede einen Satz von Spalten enthält. Jedes Objekt hat das Feld originalName, das den Objektnamen in Teradata angibt, und das Feld name, das den Zielnamen für das Objekt in BigQuery angibt.

Spalten enthalten zusätzlich die folgenden Felder:

  • Ein originalType-Feld, das den Spaltendatentyp in Teradata angibt.
  • Ein type-Feld, das den Zieldatentyp für die Spalte in BigQuery angibt.
  • Ein usageType-Feld, um Informationen darüber zu erfassen, wie die Spalte vom System verwendet wird, z. B. beim Clustering oder bei der Partitionierung. Die folgenden Nutzungstypen werden unterstützt:

    • CLUSTERING: Mit diesem Nutzungstyp können Sie in jeder Zieltabelle bis zu vier Spalten mit Anmerkungen versehen. Die Spaltenreihenfolge für das Clustering wird anhand der Reihenfolge bestimmt, in der sie im benutzerdefinierten Schema auftauchen. Die ausgewählten Spalten müssen die Einschränkungen für das Clustering in BigQuery erfüllen. Wenn für eine Tabelle das Feld PARTITIONING angegeben ist, verwendet BigQuery diese Spalten zum Erstellen einer geclusterten Tabelle.
    • COMMIT_TIMESTAMP: Mit diesem Nutzungstyp können Sie in jeder Zieltabelle nur eine Spalte annotieren. Verwenden Sie diesen Nutzungstyp, um eine Spalte mit dem Zeitstempel der Aktualisierung für inkrementelle Aktualisierungen zu identifizieren. Diese Spalte wird zum Extrahieren von Zeilen verwendet, die seit der letzten Übertragungsausführung erstellt oder aktualisiert wurden. Sie können diesen Nutzungstyp nur mit einer Spalte verwenden, die über den Datentyp TIMESTAMP oder DATE verfügt.
    • DEFAULT: Mit diesem Nutzungstyp können Sie mehrere Spalten in einer Tabelle annotieren. Dieser Nutzungstyp gibt an, dass die Spalte im Quellsystem nicht speziell verwendet wird. Dies ist der Standardwert.
    • PARTITIONING: Mit diesem Nutzungstyp können Sie in jeder Zieltabelle nur eine Spalte annotieren. Diese Spalte wird in der partitionierten Tabellendefinition für das beinhaltende Tabellenobjekt verwendet. Sie können diesen Nutzungstyp nur mit einer Spalte verwenden, die über den Datentyp TIMESTAMP oder DATE verfügt.

Sie können basierend auf diesem Beispiel manuell eine benutzerdefinierte Schemadatei erstellen oder den Migrations-Agent eine erstellen lassen, wenn Sie den Agent initialisieren.

Beispiel

Angenommen, Sie migrieren eine Teradata-Tabelle mit dem Namen orders in die tpch-Datenbank und nutzen dabei folgende Tabellendefinition:


CREATE SET TABLE TPCH.orders ,FALLBACK ,
     NO BEFORE JOURNAL,
     NO AFTER JOURNAL,
     CHECKSUM = DEFAULT,
     DEFAULT MERGEBLOCKRATIO,
     MAP = TD_MAP1
     (
      O_ORDERKEY INTEGER NOT NULL,
      O_CUSTKEY INTEGER NOT NULL,
      O_ORDERSTATUS CHAR(1) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
      O_TOTALPRICE DECIMAL(15,2) NOT NULL,
      O_ORDERDATE DATE FORMAT 'yyyy-mm-dd' NOT NULL,
      O_ORDERPRIORITY CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
      O_CLERK CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
      O_SHIPPRIORITY INTEGER NOT NULL,
      O_COMMENT VARCHAR(79) CHARACTER SET LATIN CASESPECIFIC NOT NULL)
UNIQUE PRIMARY INDEX ( O_ORDERKEY );

Angenommen, Sie möchten das Schema bei der Migration zu BigQuery mit folgenden Änderungen konfigurieren:

  • Die Spalte O_CUSTKEY in O_CUSTOMERKEY umbenennen.
  • O_ORDERDATE als Partitionierungsspalte identifizieren.

Das benutzerdefinierte Schema zum Konfigurieren dieser Einstellungen sieht so aus:


{
  "databases": [
    {
      "name": "tpch",
      "originalName": "e2e_db",
      "tables": [
        {
          "name": "orders",
          "originalName": "orders",
          "columns": [
            {
              "name": "O_ORDERKEY",
              "originalName": "O_ORDERKEY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_CUSTOMERKEY",
              "originalName": "O_CUSTKEY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_ORDERSTATUS",
              "originalName": "O_ORDERSTATUS",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 1
            },
            {
              "name": "O_TOTALPRICE",
              "originalName": "O_TOTALPRICE",
              "type": "NUMERIC",
              "originalType": "decimal",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 8
            },
            {
              "name": "O_ORDERDATE",
              "originalName": "O_ORDERDATE",
              "type": "DATE",
              "originalType": "date",
              "usageType": [
                "PARTITIONING"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_ORDERPRIORITY",
              "originalName": "O_ORDERPRIORITY",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 15
            },
            {
              "name": "O_CLERK",
              "originalName": "O_CLERK",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 15
            },
            {
              "name": "O_SHIPPRIORITY",
              "originalName": "O_SHIPPRIORITY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_COMMENT",
              "originalName": "O_COMMENT",
              "type": "STRING",
              "originalType": "varchar",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 79
            }
          ]
        }
      ]
    }
  ]
}

On-Demand- oder inkrementelle Übertragungen

Bei der Migration von Daten aus einer Teradata-Datenbankinstanz zu BigQuery unterstützt BigQuery Data Transfer Service sowohl die einmalige Datenübertragung als auch wiederkehrende, regelmäßige Übertragungen neuer und aktualisierter Zeilen ("inkrementelle Übertragungen") (Vorschau). Sie legen die Übertragung beim Einrichten einer Übertragung in den Planungsoptionen als On-Demand oder inkrementell fest.

  • On-Demand-Übertragung: Verwenden Sie diesen Modus, um die erste Migration von Schemas und Daten von Teradata zu BigQuery durchzuführen.

  • Inkrementelle Übertragung: Mit diesem Modus können Sie neue und geänderte Daten regelmäßig von Teradata zu BigQuery migrieren.

    • Bei dieser Methode müssen Sie Ihr Schema anpassen, um Spalten mit dem Nutzungstyp COMMIT_TIMESTAMP zu annotieren.
    • Beim Einrichten inkrementeller Übertragungen gelten bestimmte Bedingungen.

Inkrementelle Übertragungen

Bei inkrementellen Übertragungen erstellt die erste Übertragung immer einen Tabellen-Snapshot in BigQuery. Bei allen nachfolgenden Übertragungen werden neue und geänderte Daten in der vorhandenen Tabelle in BigQuery erfasst, übertragen und angehängt. Das bedeutet, dass für die geänderten Zeilen in BigQuery-Tabellen möglicherweise doppelte Zeilen mit alten und neuen Werten vorhanden sind.

Für jeden Übertragungsdurchlauf wird ein Zeitstempel des Übertragungsdurchlauf gespeichert. Für jede nachfolgende Übertragungsdurchlauf erhält ein Agent den Zeitstempel einer vorherigen Übertragungsdurchlauf (T1) und einen Zeitstempel für den Beginn der aktuellen Übertragungsdurchlauf (T2).

Der Migrations-Agent extrahiert Daten für jede Übertragung nach der ersten Ausführung mithilfe der folgenden Pro-Tabelle-Logik:

  • Wenn ein Tabellenobjekt in einer Schemadatei keine Spalte mit dem Nutzungstyp COMMIT_TIMESTAMP enthält, wird die Tabelle übersprungen.
  • Wenn eine Tabelle eine Spalte mit dem Nutzungstyp COMMIT_TIMESTAMP enthält, werden alle Zeilen mit einem Zeitstempel zwischen T1 und T2 extrahiert und an die vorhandene Tabelle in BigQuery angehängt.

In der folgenden Tabelle wird beschrieben, wie der Migrations-Agent DDL-Vorgänge (Datendefinitionssprache) und DML-Vorgänge (Datenbearbeitungssprache) in inkrementellen Übertragungen verarbeitet.

Teradata-Vorgang Typ Unterstützung für Teradata-zu-BigQuery
CREATE DDL In BigQuery wird ein neuer vollständiger Snapshot für die Tabelle erstellt.
DROP DDL Nicht unterstützt
ALTER (RENAME) DDL In BigQuery wird ein neuer vollständiger Snapshot für die umbenannte Tabelle erstellt. Der vorherige Snapshot wird nicht aus BigQuery gelöscht. Der Nutzer wird nicht über die umbenannte Tabelle benachrichtigt.
INSERT DML Der BigQuery-Tabelle werden neue Zeilen hinzugefügt.
UPDATE DML Zeilen werden nicht geändert. Der BigQuery-Tabelle werden neue Zeilen hinzugefügt, ähnlich wie bei einem INSERT-Vorgang. Zeilen aus vorherigen Übertragungen werden nicht aktualisiert oder gelöscht.
MERGE DML Nicht unterstützt. Siehe stattdessen INSERT, UPDATE und DELETE.
DELETE DML Nicht unterstützt

Überlegungen zum Standort

Ihr Cloud Storage-Bucket muss sich in einer Region oder in mehreren Regionen befinden, die mit der Region oder mit dem multiregionalen Standort des Ziel-Datasets in BigQuery kompatibel ist bzw. sind.

  • Wenn sich Ihr BigQuery-Dataset in einer Multiregion befindet, muss sich der Cloud Storage-Bucket mit den Daten, die Sie übertragen, am selben Standort oder an einem Standort befinden, der sich in derselben Multiregion befindet. Wenn sich Ihr BigQuery-Dataset zum Beispiel in der Multiregion "EU" befindet, kann sich der Cloud Storage-Bucket in der Region "europe-west1" innerhalb der EU befinden.
  • Wenn sich Ihr Dataset in einer Region befindet, muss sich der Cloud Storage-Bucket in derselben Region befinden. Wenn sich Ihr Dataset zum Beispiel in der Region „asia-northeast1“ in Tokio befindet, kann sich der Cloud Storage-Bucket nicht am multiregionalen Standort „ASIA“ befinden.

Ausführliche Informationen zu Übertragungen und Regionen finden Sie unter Dataset-Standorte und Übertragungen.

Preise

Die Datenübertragung mit BigQuery ist kostenlos. Durch die Nutzung dieses Dienstes können aber Kosten außerhalb von Google anfallen, z. B. für ausgehende Datenübertragungen auf der Plattform.

  • Das Extrahieren, das Hochladen in einen Cloud Storage-Bucket und das Laden von Daten in BigQuery ist ebenfalls kostenlos.
  • Die Daten werden nach dem Hochladen in BigQuery nicht automatisch aus Ihrem Cloud Storage-Bucket gelöscht. Daher sollten Sie sie selbst herauslöschen, um weitere Speicherkosten zu vermeiden. Weitere Informationen finden Sie unter Cloud Storage – Preise.
  • Es gelten alle standardmäßigen BigQuery-Kontingente und -Limits.
  • Nach der Übertragung von Daten in BigQuery gelten die Standardpreise für das Speichern und Abfragen in BigQuery.
  • Weitere Informationen finden Sie auf der Seite Preise für Übertragungen.

Beschränkungen

  • Einmalige On-Demand-Übertragungen werden vollständig unterstützt. Inkrementelle Übertragungen befinden sich in der Betaphase. DDL- und DML-Vorgänge bei inkrementellen Übertragungen werden teilweise unterstützt.
  • Während der Datenübertragung werden Daten in ein Verzeichnis im lokalen Dateisystem extrahiert. Sorgen Sie dafür, dass ausreichend Speicherplatz vorhanden ist.
    • Wenn Sie den FastExport-Extraktionsmodus verwenden, können Sie den maximal zu verwendenden Speicherplatz festlegen und das Limit vom Migrations-Agent erzwingen lassen. Legen Sie die Einstellung max-local-storage in der Konfigurationsdatei des Migrations-Agent fest, wenn Sie eine Übertragung von Teradata zu BigQuery einrichten.
    • Sorgen Sie bei Verwendung der TPT-Extraktionsmethode dafür, dass das Dateisystem über genügend freien Speicherplatz verfügt, der größer als die größte Tabellenpartition in der Teradata-Instanz sein muss.
  • BigQuery Data Transfer Service konvertiert das Schema automatisch, wenn Sie keine benutzerdefinierte Schemadatei bereitstellen, und überträgt Teradata-Daten an BigQuery. Die Daten werden von Teradata zu BigQuery-Typen zugeordnet.
  • Dateien werden nach dem Laden in BigQuery nicht automatisch aus Ihrem Cloud Storage-Bucket gelöscht. Sie sollten die Daten aus Ihrem Cloud Storage-Bucket löschen, nachdem Sie sie in BigQuery geladen haben, um zusätzliche Speicherkosten zu vermeiden. Weitere Informationen finden Sie unter Preise.
  • Die Geschwindigkeit der Extraktion hängt von Ihrer JDBC-Verbindung ab.
  • Die aus Teradata extrahierten Daten sind nicht verschlüsselt. Treffen Sie geeignete Maßnahmen, um den Zugriff auf die extrahierten Dateien im lokalen Dateisystem einzuschränken und dafür zu sorgen, dass der Cloud Storage-Bucket ordnungsgemäß gesichert ist.
  • Andere Datenbankressourcen wie gespeicherte Prozeduren, gespeicherte Abfragen, Datenansichten und benutzerdefinierte Funktionen werden nicht übertragen und fallen nicht in den Anwendungsbereich dieses Dienstes.

Nächste Schritte