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.
Ü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
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 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 Feld
PARTITIONINGangegeben ist, verwendet BigQuery diese Spalten zum Erstellen einer geclusterten Tabelle. - COMMIT_TIMESTAMP: Mit diesem Nutzungstyp können Sie nur eine Spalte in jeder Zieltabelle 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
TIMESTAMPoderDATEverfü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 nur eine Spalte in jeder Zieltabelle annotieren. Diese Spalte wird in der partitioned Tabellendefinition für das beinhaltende Tabellenobjekt verwendet. Sie können diesen Nutzungstyp nur mit einer Spalte verwenden, die über den Datentyp
TIMESTAMPoderDATEverfügt. - PRIMARY_KEY: Mit diesem Nutzungstyp können Sie Spalten in jeder Zieltabelle annotieren. Verwenden Sie diesen Verwendungstyp, um entweder nur eine Spalte als Primärschlüssel zu identifizieren oder im Fall eines zusammengesetzten Schlüssels denselben Verwendungstyp für mehrere Spalten, um die eindeutigen Entitäten einer Tabelle zu identifizieren. Diese Spalten werden zusammen mit
COMMIT_TIMESTAMPverwendet, um Zeilen zu extrahieren, die seit der letzten Übertragungsausführung erstellt oder aktualisiert wurden.
- 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 Feld
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_CUSTKEYinO_CUSTOMERKEYumbenennen. O_ORDERDATEals 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 vollständige Übertragungen (On-Demand-Übertragungen) 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 ausfü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 die Daten in BigQuery angehängt. In aktualisierten Zeilen in BigQuery-Tabellen können möglicherweise doppelte Zeilen mit alten und neuen Werten vorhanden sein. - Spalten sowohl mit dem Nutzungstyp
COMMIT_TIMESTAMPals auchPRIMARY_KEYannotieren: Bei dieser Übertragung werden neue Zeilen angehängt und geänderte Zeilen werden 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 mit derPRIMARY_KEYin der Teradata-Tabelle übereinstimmen. Es 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 folgen den Anmerkungen, die in der unten beschriebenen benutzerdefinierten Schemadatei definiert 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 Übertragungen 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. Neue Zeilen werden angehängt und geänderte Zeilen werden in der vorhandenen Tabelle in BigQuery aktualisiert.
Im Folgenden finden Sie Beispielschemadateien 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 zusammengesetzten 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 hinzugefügt, ähnlich wie bei einem INSERT-Vorgang, wenn nur COMMIT_TIMESTAMP verwendet wird.
Zeilen werden ähnlich wie bei einem UPDATE-Vorgang aktualisiert, 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 "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.
- Es gelten die standardmäßigen Kontingente und Limits für DML-Upserts in BigQuery.
- Nach der Übertragung von Daten in BigQuery gelten die Standardpreise für Speicher und Rechenleistung 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-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 ist das endgültige Löschen nicht möglich. 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.