Einführung in Microsoft SQL Server-Datenübertragungen
Mit dem BigQuery Data Transfer Service für Microsoft SQL Server-Connector können Sie Daten aus Microsoft SQL Server in BigQuery laden. Der Connector unterstützt Microsoft SQL Server-Instanzen, die in Ihrer lokalen Umgebung, in Cloud SQL und bei anderen öffentlichen Cloud-Anbietern wie Amazon Web Services (AWS) und Microsoft Azure gehostet werden. In diesem Dokument finden Sie eine Übersicht über die Optionen für die Datenaufnahme für Ihre Microsoft SQL Server-Übertragung sowie Informationen zur Datentypzuordnung und zu den Preisen.
Informationen zum Planen einer Microsoft SQL Server-Übertragung finden Sie unter Microsoft SQL Server-Daten in BigQuery laden.
Optionen für die Datenaufnahme
In den folgenden Abschnitten finden Sie Informationen zu den Optionen für die Datenaufnahme, wenn Sie eine Microsoft SQL Server-Datenübertragung einrichten.
TLS-Konfiguration
Der Microsoft SQL Server-Connector unterstützt die Konfiguration für die Transportschichtsicherheit (Transport Layer Security, TLS), um Ihre Datenübertragungen in BigQuery zu verschlüsseln. Der Microsoft SQL Server-Connector unterstützt die folgenden TLS-Konfigurationen:
Der Modus Daten verschlüsseln und Zertifizierungsstelle sowie Hostname überprüfen. In diesem Modus wird der Server mit TLS über das TCPS-Protokoll vollständig validiert. Alle Daten werden während der Übertragung verschlüsselt und es wird überprüft, ob das Zertifikat des Datenbankservers von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde. In diesem Modus wird auch geprüft, ob der Hostname, mit dem Sie eine Verbindung herstellen, genau mit dem allgemeinen Namen (Common Name, CN) oder einem alternativen Antragstellernamen (Subject Alternative Name, SAN) im Zertifikat des Servers übereinstimmt. Dieser Modus verhindert, dass Angreifer ein gültiges Zertifikat für eine andere Domain verwenden, um sich als Ihr Datenbankserver auszugeben.
Wenn Ihr Hostname nicht mit dem CN oder SAN des Zertifikats übereinstimmt, schlägt die Verbindung fehl. Sie müssen eine DNS-Auflösung konfigurieren, die mit dem Zertifikat übereinstimmt, oder einen anderen Sicherheitsmodus verwenden. Verwenden Sie diesen Modus für die sicherste Option, um Man-in-the-Middle-Angriffe zu verhindern.
Der Modus Daten verschlüsseln und nur Zertifizierungsstelle überprüfen. In diesem Modus werden alle Daten mit TLS über das TCPS-Protokoll verschlüsselt und es wird überprüft, ob das Zertifikat des Servers von einer Zertifizierungsstelle signiert wurde, der der Client vertraut. Der Hostname des Servers wird jedoch nicht überprüft. In diesem Modus wird eine Verbindung hergestellt, solange das Zertifikat gültig ist und von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde, unabhängig davon, ob der Hostname im Zertifikat mit dem Hostnamen übereinstimmt, mit dem Sie eine Verbindung herstellen.
Verwenden Sie diesen Modus, wenn Sie sicherstellen möchten, dass Sie eine Verbindung zu einem Server herstellen, dessen Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde, der Hostname aber nicht überprüft werden kann oder Sie keine Kontrolle über die Hostname-Konfiguration haben.
Der Modus Nur Verschlüsselung. In diesem Modus werden alle Daten verschlüsselt, die zwischen dem Client und dem Server übertragen werden. Es wird keine Zertifikats- oder Hostname-Validierung durchgeführt.
Dieser Modus bietet ein gewisses Maß an Sicherheit, da die Daten bei der Übertragung geschützt werden. Er kann jedoch anfällig für Man-in-the-Middle-Angriffe sein.
Verwenden Sie diesen Modus, wenn Sie sicherstellen müssen, dass alle Daten verschlüsselt sind, die Identität des Servers aber nicht überprüfen können oder möchten. Wir empfehlen, diesen Modus bei der Arbeit mit privaten VPCs zu verwenden.
Der Modus Keine Verschlüsselung oder Überprüfung. In diesem Modus werden keine Daten verschlüsselt und es wird keine Zertifikats- oder Hostname-Überprüfung durchgeführt. Alle Daten werden als Nur-Text gesendet.
Wir empfehlen, diesen Modus nicht in einer Umgebung zu verwenden, in der sensible Daten verarbeitet werden. Wir empfehlen, diesen Modus nur zu Testzwecken in einem isolierten Netzwerk zu verwenden, in dem Sicherheit keine Rolle spielt.
Vertrauenswürdiges Serverzertifikat (PEM)
Wenn Sie den Modus Daten verschlüsseln und Zertifizierungsstelle sowie Hostname überprüfen oder Daten verschlüsseln und nur Zertifizierungsstelle überprüfen verwenden, können Sie auch ein oder mehrere PEM-codierte Zertifikate angeben. Diese Zertifikate sind in einigen Szenarien erforderlich, in denen der BigQuery Data Transfer Service die Identität Ihres Datenbankservers während der TLS-Verbindung überprüfen muss:
- Wenn Sie ein Zertifikat verwenden, das von einer privaten Zertifizierungsstelle in Ihrer Organisation signiert wurde, oder ein selbst signiertes Zertifikat, müssen Sie die vollständige Zertifikatskette oder das einzelne selbst signierte Zertifikat angeben. Dies ist für Zertifikate erforderlich, die von internen Zertifizierungsstellen verwalteter Cloud-Anbieterdienste wie Amazon Relationale Datenbank Service (RDS) ausgestellt wurden.
- Wenn Ihr Datenbankserverzertifikat von einer öffentlichen Zertifizierungsstelle signiert wurde (z. B. Let's Encrypt, DigiCert oder GlobalSign), müssen Sie kein Zertifikat angeben. Die Root-Zertifikate für diese öffentlichen Zertifizierungsstellen sind vorinstalliert und werden vom BigQuery Data Transfer Service als vertrauenswürdig eingestuft.
Sie können PEM-codierte Zertifikate im Feld Vertrauenswürdiges PEM-Zertifikat in der Übertragungskonfiguration angeben. Dabei müssen die folgenden Anforderungen erfüllt sein:
- Das Zertifikat muss eine gültige PEM-codierte Zertifikatskette sein.
- Das Zertifikat muss vollständig korrekt sein. Fehlende Zertifikate in der Kette oder falsche Inhalte führen dazu, dass die TLS-Verbindung fehlschlägt.
- Für ein einzelnes Zertifikat können Sie ein einzelnes selbst signiertes Zertifikat vom Datenbankserver angeben.
- Für eine vollständige Zertifikatskette, die von einer privaten Zertifizierungsstelle ausgestellt wurde, müssen Sie die vollständige Vertrauenskette angeben. Dazu gehören das Zertifikat vom Datenbankserver und alle CA-Zertifikate der Zwischen- und Stammzertifizierungsstellen.
Vollständige oder inkrementelle Übertragungen
Sie können angeben, wie Daten in BigQuery geladen werden, indem Sie in der Übertragungskonfiguration beim Einrichten einer Microsoft SQL Server-Übertragung entweder die Schreibeinstellung Vollständig oder Inkrementell auswählen. Inkrementelle Übertragungen werden in der Vorschau unterstützt.
Sie können eine vollständige Datenübertragung konfigurieren, um bei jeder Datenübertragung alle Daten aus Ihren Microsoft SQL Server-Datasets zu übertragen.Alternativ können Sie eine inkrementelle Datenübertragung (Vorschau) konfigurieren, um nur Daten zu übertragen, die seit der letzten Datenübertragung geändert wurden, anstatt das gesamte Dataset bei jeder Datenübertragung zu laden. Wenn Sie für Ihre Datenübertragung Inkrementell auswählen, müssen Sie entweder den Schreibmodus Anhängen oder Upsert angeben, um zu definieren, wie Daten während einer inkrementellen Datenübertragung in BigQuery geschrieben werden. In den folgenden Abschnitten werden die verfügbaren Schreibmodi beschrieben.
Schreibmodus „Anhängen“
Im Schreibmodus „Anhängen“ werden nur neue Zeilen in die Zieltabelle eingefügt. Bei dieser Option werden übertragene Daten einfach angehängt, ohne nach vorhandenen Datensätzen zu suchen. Daher kann es in der Zieltabelle zu Datenduplizierungen kommen.
Wenn Sie den Modus „Anhängen“ auswählen, müssen Sie eine Watermark-Spalte auswählen. Eine Watermark-Spalte ist erforderlich, damit der Microsoft SQL Server-Connector Änderungen in der Quelltabelle nachverfolgen kann.
Für Microsoft SQL Server-Übertragungen empfehlen wir, eine Spalte auszuwählen, die nur beim Erstellen des Datensatzes aktualisiert wird und sich bei nachfolgenden Aktualisierungen nicht ändert, z. B. die SpalteCREATED_AT.
Schreibmodus „Upsert“
Im Schreibmodus „Upsert“ wird entweder eine Zeile aktualisiert oder eine neue Zeile in die Zieltabelle eingefügt, indem nach einem Primärschlüssel gesucht wird. Sie können einen Primärschlüssel angeben, damit der Microsoft SQL Server-Connector ermitteln kann, welche Änderungen erforderlich sind, um die Zieltabelle auf dem neuesten Stand zu halten. Wenn der angegebene Primärschlüssel während einer Datenübertragung in der BigQuery-Zieltabelle vorhanden ist, aktualisiert der Microsoft SQL Server-Connector diese Zeile mit neuen Daten aus der Quelltabelle. Wenn während einer Datenübertragung kein Primärschlüssel vorhanden ist, fügt der Microsoft SQL Server-Connector eine neue Zeile ein.
Wenn Sie den Modus „Upsert“ auswählen, müssen Sie eine Watermark-Spalte und einen Primärschlüssel auswählen:
- Eine Watermark-Spalte ist erforderlich, damit der Microsoft SQL Server-Connector Änderungen in der Quelltabelle nachverfolgen kann.
- Wählen Sie eine Watermark-Spalte aus, die jedes Mal aktualisiert wird, wenn eine Zeile geändert wird. Wir empfehlen Spalten wie
UPDATED_AToderLAST_MODIFIED.
- Wählen Sie eine Watermark-Spalte aus, die jedes Mal aktualisiert wird, wenn eine Zeile geändert wird. Wir empfehlen Spalten wie
Der Primärschlüssel kann eine oder mehrere Spalten in Ihrer Tabelle sein, die der Microsoft SQL Server-Connector benötigt, um zu ermitteln, ob eine Zeile eingefügt oder aktualisiert werden muss.
Wählen Sie Spalten aus, die Nicht-Null-Werte enthalten, die in allen Zeilen der Tabelle eindeutig sind. Wir empfehlen Spalten mit vom System generierten IDs, eindeutigen Referenzcodes (z. B. automatisch inkrementierende IDs) oder unveränderlichen zeitbasierten Sequenz-IDs.
Um potenziellen Datenverlust oder Datenbeschädigung zu verhindern, müssen die von Ihnen ausgewählten Primärschlüsselspalten eindeutige Werte haben. Wenn Sie Zweifel an der Eindeutigkeit der ausgewählten Primärschlüsselspalte haben, empfehlen wir stattdessen den Schreibmodus „Anhängen“.
Verhalten bei der inkrementellen Aufnahme
Wenn Sie Änderungen am Tabellenschema in Ihrer Datenquelle vornehmen, werden inkrementelle Datenübertragungen aus diesen Tabellen in BigQuery auf folgende Weise berücksichtigt:
| Änderungen an der Datenquelle | Verhalten bei der inkrementellen Aufnahme |
|---|---|
| Neue Spalte hinzufügen | Der BigQuery-Zieltabelle wird eine neue Spalte hinzugefügt. Alle vorherigen Einträge für diese Spalte haben Nullwerte. |
| Spalte löschen | Die gelöschte Spalte bleibt in der BigQuery Zieltabelle. Neue Einträge in dieser gelöschten Spalte werden mit Nullwerten gefüllt. |
| Datentyp in einer Spalte ändern | Der Connector unterstützt nur
Datentypkonvertierungen, die von der DDL-Anweisung ALTER COLUMN unterstützt werden.
Jede andere Datentypkonvertierung führt dazu, dass die Datenübertragung fehlschlägt.
Wenn Probleme auftreten, empfehlen wir, eine neue Übertragungs konfiguration zu erstellen. |
| Spalte umbenennen | Die ursprüngliche Spalte bleibt unverändert in der BigQuery Zieltabelle. Der Zieltabelle wird eine neue Spalte mit dem aktualisierten Namen hinzugefügt. |
Datentypzuordnung
In der folgenden Tabelle werden Microsoft SQL Server-Datentypen den entsprechenden BigQuery-Datentypen zugeordnet:
| Microsoft SQL Server-Datentyp | BigQuery-Datentyp | Aktualisierter BigQuery-Datentyp |
|---|---|---|
tinyint |
INTEGER |
|
smallint |
INTEGER |
|
int |
INTEGER |
|
bigint |
BIGNUMERIC |
|
bit |
BOOLEAN |
|
decimal |
BIGNUMERIC |
|
numeric |
NUMERIC |
|
money |
BIGNUMERIC |
|
smallmoney |
BIGNUMERIC |
|
float |
FLOAT |
|
real |
FLOAT |
|
date |
DATE |
|
time |
TIME |
|
datetime2 |
TIMESTAMP |
DATETIME |
datetimeoffset |
TIMESTAMP |
|
datetime |
TIMESTAMP |
DATETIME |
smalldatetime |
TIMESTAMP |
DATETIME |
char |
STRING |
|
varchar |
STRING |
|
text |
STRING |
|
nchar |
STRING |
|
nvarchar |
STRING |
|
ntext |
STRING |
|
binary |
BYTES |
|
varbinary |
BYTES |
|
image |
BYTES |
|
geography |
STRING |
|
geometry |
STRING |
|
hierarchyid |
BYTES |
|
rowversion |
BYTES |
|
sql_variant |
BYTES |
|
uniqueidentifier |
STRING |
|
xml |
STRING |
|
json |
STRING |
|
vector |
STRING |
Die Datentypen json und vector werden nur in Azure unterstützt.
Der JSON-Datentyp wird in Azure SQL-Datenbanken und verwalteten Azure SQL-Instanzen unterstützt, die mit der Aktualisierungsrichtlinie „Immer aktuell“ konfiguriert sind. Der JSON-Datentyp wird in verwalteten Azure SQL-Instanzen, die mit der Aktualisierungsrichtlinie für Microsoft SQL Server 2022 konfiguriert sind, nicht unterstützt.
Microsoft SQL Server speichert JSON als NVARCHAR(MAX) und nicht als JSON-Typ. Wir empfehlen, CHECK (ISJSON(json_col) = 1) zur Validierung und JSON_VALUE() für Abfragen zu verwenden.
Microsoft SQL Server bietet keine Vektorunterstützung für den Datentyp vector. Wir empfehlen, Vektoren als JSON-Arrays in NVARCHAR(MAX) zu speichern und JSON_VALUE() zum Extrahieren zu verwenden. Die Ähnlichkeit kann manuell mit FLOAT-Berechnungen ermittelt werden.
Preise
Während sich dieses Feature in der Vorschaubefindet, fallen keine Kosten für die Übertragung von Microsoft SQL Server-Daten in BigQuery an.
Nächste Schritte
- Microsoft SQL Server-Übertragung einrichten .
- Weitere Informationen zum BigQuery Data Transfer Service.