Migration von Teradata zu BigQuery – Übersicht
Dieses Dokument enthält weitere Informationen, die Ihnen helfen, die Entscheidungen zu treffen, die Sie treffen müssen, wenn Sie den BigQuery Data Transfer Service für die Migration von Schema und Daten von Teradata zu BigQuery verwenden. Eine Einführung in den Teradata-Migrationsprozess finden Sie unter Einführung in die Migration von Teradata zu BigQuery.
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 allgemeinen 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.
Übersicht
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:
- Laden Sie den Migrations-Agent herunter.
- Konfigurieren Sie eine Übertragung in BigQuery Data Transfer Service.
- Führen Sie den Übertragungsjob aus, um das Tabellenschema und die Daten aus Ihrem Data Warehouse nach BigQuery zu kopieren.
- 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:
- Partitionieren Sie Ihre Teradata-Tabellen.
- Verwenden Sie Teradata Parallel Transporter (TPT) für die Extraktion.
- 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
Sie können das Schema auf verschiedene Arten definieren. BigQuery Data Transfer Service bietet eine automatische Schemaerkennung und Datentypzuordnung während einer Datenübertragung von Teradata zu BigQuery. Sie können auch die Übersetzungs-Engine verwenden, um die Zuordnung des Datentyps abzurufen, oder stattdessen eine benutzerdefinierte Schemadatei angeben.
Standardmäßige Schemaerkennung
Wenn Sie keine Schemakonfiguration angeben, erkennt der BigQuery Data Transfer Service das Schema Ihrer Teradata-Quelltabelle automatisch und führt während der Datenübertragung eine Datentypzuordnung zu den entsprechenden BigQuery-Datentypen durch. Weitere Informationen zur Standardzuordnung von Datentypen finden Sie unter Datentypen.
Ausgabe der Übersetzungs-Engine für Schema verwenden
Der BigQuery Data Transfer Service verwendet die Ausgabe der BigQuery-Übersetzungs-Engine für die Schemazuordnung während der Migration von Teradata-Tabellen zu BigQuery. Damit Sie diese Option nutzen können, müssen die folgenden Voraussetzungen erfüllt sein:
- Metadaten für die Übersetzung generieren. Führen Sie das Dumper-Tool aus, um Metadaten für die Übersetzung zu generieren, die den Teradata-Quellrichtlinien entsprechen. Weitere Informationen finden Sie unter Metadaten für Übersetzung und Bewertung generieren.
- Laden Sie die generierte Metadatendatei (z. B.
metadata.zip) in einen Cloud Storage-Bucket hoch. Dieser Bucket dient als Eingabespeicherort für die Übersetzungs-Engine. Starten Sie einen Batchübersetzungsjob, um die BigQuery Data Transfer Service-Zuordnung zu erstellen, die das Schema für die BigQuery-Zieltabelle definiert. Weitere Informationen dazu finden Sie unter Batchübersetzung erstellen. Im folgenden Beispiel wird die BigQuery Data Transfer Service-Zuordnung durch Angabe von
target_types = "dts_mapping"generiert:curl -d "{ \"name\": \"teradata_2_bq_translation\", \"displayName\": \"Teradata to BigQuery Translation\", \"tasks\": { string: { \"type\": \"Teradata2BigQuery_Translation\", \"translation_details\": { \"target_base_uri\": \"gs://your_translation_output_bucket/output\", \"source_target_mapping\": { \"source_spec\": { \"base_uri\": \"gs://your_metadata_bucket/input\" } }, \"target_types\": \"metadata\", } } }, }" \ -H "Content-Type:application/json" \ -H "Authorization: Bearer YOUR_ACCESS_TOKEN" -X POST https://bigquerymigration.googleapis.com/v2alpha/projects/your_project_id/locations/your_location/workflowsSie können den Status des Batchübersetzungsjobs in der Google Cloud Console prüfen. Rufen Sie dazu BigQuery > SQL-Übersetzung auf. Nach Abschluss des Vorgangs wird die Zuordnungsdatei an einem Cloud Storage-Speicherort gespeichert, der im Flag
target_base_uriangegeben ist.Verwenden Sie zum Generieren eines Tokens den Befehl
gcloud auth print-access-tokenoder den OAuth 2.0 Playground mit dem Bereichhttps://www.googleapis.com/auth/cloud-platform.Geben Sie in der Konfiguration für die Teradata-Datenübertragung den Pfad zum Cloud Storage-Ordner an, in dem die Zuordnungsdatei aus dem vorherigen Schritt gespeichert ist. Der BigQuery Data Transfer Service verwendet diese Zuordnung, um das Schema Ihrer BigQuery-Zieltabelle zu definieren.
Benutzerdefinierte Schemadatei
Wir empfehlen, in den folgenden Situationen ein benutzerdefiniertes Schema anzugeben:
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.
Eine benutzerdefinierte Schemadatei ist eine JSON-Datei, die Datenbankobjekte beschreibt. Das Schema enthält eine Reihe von Datenbanken, die jeweils eine Reihe von Tabellen enthalten, die jeweils eine Reihe von Spalten enthalten. 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 haben die folgenden Felder:
originalType: gibt den Spaltendatentyp in Teradata antype: gibt den Zieldatentyp für die Spalte in BigQuery an.usageType: Informationen dazu, wie die Spalte vom System verwendet wird. Die folgenden Nutzungstypen werden unterstützt:DEFAULT: Mit diesem Nutzungstyp können Sie mehrere Spalten in einer Tabelle annotieren. DieserusageTypegibt an, dass die Spalte im Quellsystem nicht speziell verwendet wird. Dies ist der Standardwert.CLUSTERING: Mit diesem Nutzungstyp können Sie bis zu vier Spalten in jeder Zieltabelle annotieren. 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 FeldPARTITIONINGangegeben ist, verwendet BigQuery diese Spalten zum Erstellen einer geclusterten Tabelle.PARTITIONING: Mit diesem Nutzungstyp können Sie nur eine Spalte in jeder Zieltabelle annotieren. Diese Spalte wird in der partitionierten Tabellendefinition für das beinhaltendetables-Objekt verwendet. Sie können diesen Nutzungstyp nur mit einer Spalte verwenden, die über den DatentypTIMESTAMPoderDATEverfügt.COMMIT_TIMESTAMP: Mit diesem Nutzungstyp können Sie nur eine Spalte in jeder Zieltabelle annotieren. Verwenden Sie diesenusageType, 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 Spalten verwenden, die über den DatentypTIMESTAMPoderDATEverfügen.PRIMARY_KEY: Sie können Spalten in jeder Zieltabelle mit diesem Nutzungstyp annotieren. Mit diesem Nutzungstyp können Sie nur eine Spalte als Primärschlüssel festlegen. Bei einem zusammengesetzten Schlüssel können Sie denselben Nutzungstyp für mehrere Spalten verwenden, um die eindeutigen Einheiten einer Tabelle zu identifizieren. Diese Spalten werden zusammen mitCOMMIT_TIMESTAMPverwendet, um Zeilen zu extrahieren, die seit der letzten Übertragungsausführung erstellt oder aktualisiert wurden.
Sie können manuell eine benutzerdefinierte Schemadatei erstellen, wie im folgenden Beispiel gezeigt, oder den Migrations-Agent eine erstellen lassen, wenn Sie den Agent initialisieren.
In diesem Beispiel migriert ein Nutzer eine Teradata-Tabelle mit dem Namen orders in die tpch-Datenbank und nutzt 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, der Nutzer möchte das Schema bei der Migration zu BigQuery mit folgenden Änderungen konfigurieren:
- Benennen Sie die Spalte
O_CUSTKEYinO_CUSTOMERKEYum. O_ORDERDATEals Partitionierungsspalte identifizieren
Das folgende Beispiel zeigt ein benutzerdefiniertes Schema zum Konfigurieren dieser Einstellungen:
{
"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 vollständige Übertragungen (On-Demand-Übertragung) als auch wiederkehrende Übertragungen (inkrementelle Übertragungen). 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 vollständige Snapshot-Migration von Schemas und Daten von Teradata zu BigQuery durchzuführen.
Geplante Übertragung: Mit diesem Modus können Sie den vollständigen Snapshot durchführen und neue und geänderte Daten (inkrementelle Daten) regelmäßig von Teradata zu BigQuery migrieren. Für inkrementelle Übertragungen müssen Sie Ihr Schema anpassen, um Spalten mit einem der folgenden Anwendungsfälle zu annotieren:
- Spalten nur mit dem Nutzungstyp
COMMIT_TIMESTAMPannotieren: Bei dieser Übertragung werden neue oder geänderte Zeilen in Teradata an Daten in BigQuery angehängt. Aktualisierte Zeilen in BigQuery-Tabellen können möglicherweise doppelte Zeilen mit alten und neuen Werten enthalten. - Spalten mit dem Nutzungstyp
COMMIT_TIMESTAMPundPRIMARY_KEYannotieren: Bei dieser Übertragung werden neue Zeilen angehängt und geänderte Zeilen in der entsprechenden Zeile in BigQuery aktualisiert. Die inPRIMARY_KEYdefinierte Spalte wird verwendet, um die Eindeutigkeit der Daten in BigQuery zu gewährleisten. - Die im Schema definierte Spalte
PRIMARY_KEYmuss nicht diePRIMARY_KEYin der Teradata-Tabelle sein. Das kann eine beliebige Spalte sein, sie muss aber eindeutige Daten enthalten.
- Spalten nur mit dem Nutzungstyp
Inkrementelle Übertragungen
Bei inkrementellen Übertragungen erstellt die erste Übertragung immer einen Tabellen-Snapshot in BigQuery. Alle nachfolgenden inkrementellen Übertragungen richten sich nach den Anmerkungen, die in der benutzerdefinierten Schemadatei definiert sind (siehe unten).
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_TIMESTAMPenthält, wird die Tabelle übersprungen. - Wenn eine Tabelle eine Spalte mit dem Nutzungstyp
COMMIT_TIMESTAMPenthält, werden alle Zeilen mit einem Zeitstempel zwischen T1 und T2 extrahiert und an die vorhandene Tabelle in BigQuery angehängt. - Wenn eine Tabelle eine Spalte mit dem Nutzungstyp
COMMIT_TIMESTAMPund eine Spalte mit dem NutzungstypPRIMARY_KEYenthält, werden alle Zeilen mit einem Zeitstempel zwischen T1 und T2 extrahiert. Alle neuen Zeilen werden angehängt und geänderte Zeilen werden in der vorhandenen Tabelle in BigQuery aktualisiert.
Im Folgenden finden Sie Beispieldateien für inkrementelle Übertragungen.
Schema mit nur COMMIT_TIMESTAMP
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"DEFAULT"
],
"isRequired": true
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
Schema mit COMMIT_TIMESTAMP und einer Spalte (Id) als PRIMARY_KEY
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": true
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
Schema mit COMMIT_TIMESTAMP und zusammengesetztem Schlüssel (ID + Name) als PRIMARY_KEY
{
"databases": [
{
"name": "abc_db",
"originalName": "abc_db",
"tables": [
{
"name": "abc_table",
"originalName": "abc_table",
"columns": [
{
"name": "Id",
"originalName": "Id",
"type": "INT64",
"originalType": "integer",
"originalColumnLength": 4,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": true
},
{
"name": "Name",
"originalName": "Name",
"type": "STRING",
"originalType": "character",
"originalColumnLength": 30,
"usageType": [
"PRIMARY_KEY"
],
"isRequired": false
},
{
"name": "timestamp",
"originalName": "timestamp",
"type": "TIMESTAMP",
"originalType": "timestamp",
"originalColumnLength": 26,
"usageType": [
"COMMIT_TIMESTAMP"
],
"isRequired": false
}
]
}
]
}
]
}
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 | Der BigQuery-Tabelle werden neue Zeilen angehängt, ähnlich wie bei einem INSERT-Vorgang, wenn nur COMMIT_TIMESTAMP verwendet wird.
Zeilen werden aktualisiert, ähnlich wie bei einem UPDATE-Vorgang, wenn sowohl COMMIT_TIMESTAMP als auch PRIMARY_KEY verwendet werden. |
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
EUbefindet, kann sich der Cloud Storage-Bucket in der Regioneurope-west1innerhalb der EU befinden. - Wenn sich Ihr Dataset in einer einzelnen Region befindet, muss sich der Cloud Storage-Bucket in derselben Region befinden. Wenn sich Ihr Dataset zum Beispiel in der Region
asia-northeast1Tokio befindet, darf sich der Cloud Storage-Bucket nicht am multiregionalen StandortASIAbefinden.
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.
- Es gelten die standardmäßigen BigQuery-Kontingente und -Limits für DML-Upserts für die inkrementelle Aufnahme.
- Nach der Übertragung von Daten in BigQuery gelten die Standardpreise für das Speichern und Berechnungen in BigQuery.
- Weitere Informationen finden Sie auf der Seite Preise für Übertragungen.
Beschränkungen
- Einmalige On-Demand-Übertragungen werden vollständig unterstützt. 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-storagein 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.
- 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
- 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.
- Bei inkrementellen Übertragungen werden keine endgültigen Löschvorgänge unterstützt. Bei inkrementellen Übertragungen werden keine gelöschten Zeilen in Teradata mit BigQuery synchronisiert.
Nächste Schritte
- Schritt-für-Schritt-Anleitung zum Migrieren von Teradata zu BigQuery ansehen
- Testen Sie die Migration von Teradata zu BigQuery.