Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Globale Anfragen

Mit globalen Abfragen können Sie SQL-Abfragen ausführen, die auf Daten verweisen, die in mehreren Regionen gespeichert sind. Sie können beispielsweise eine globale Abfrage ausführen, mit der eine Tabelle in us-central1 mit einer Tabelle in europe-central2 verknüpft wird. In diesem Dokument wird beschrieben, wie Sie globale Abfragen in Ihrem Projekt aktivieren und ausführen.

Hinweis

Prüfen Sie, ob globale Abfragen für Ihr Projekt aktiviert sind und ob Sie die erforderlichen Berechtigungen zum Ausführen globaler Abfragen haben.

Globale Abfragen aktivieren

Verwenden Sie die ALTER PROJECT SET OPTIONS-Anweisung oder die ALTER ORGANIZATION SET OPTIONS-Anweisung, um globale Abfragen für Ihr Projekt oder Ihre Organisation zu aktivieren und die Standardkonfiguration zu ändern.

Wenn Sie globale Abfragen in einer Region ausführen möchten, setzen Sie das Argument enable_global_queries_execution in dieser Region für das Projekt , in dem die Abfrage ausgeführt wird, auf true.
Damit globale Abfragen Daten aus einer Region kopieren können, legen Sie das enable_global_queries_data_access-Argument in dieser Region für das Projekt mit den Daten auf true fest.
Immer wenn mit Ihrer Abfrage auf Remote-Tabellen zugegriffen wird, werden diese Optionen geprüft.
Globale Abfragen können in einem Projekt ausgeführt werden und Daten aus anderen Regionen aus einem anderen Projekt abrufen.

Beispiel: Projektübergreifende Konfiguration

Im folgenden Beispiel wird gezeigt, wie Sie eine Abfrage in einem Projekt ausführen, die auf eine Tabelle in einem anderen Projekt zugreift.

Angenommen, Sie haben ein Projekt query_project, in dem Jobs in der Region us-central1 ausgeführt werden, und Sie möchten eine Abfrage ausführen, mit der auf eine Tabelle data_project.dataset.my_table in der Region europe-west1 zugegriffen wird:

SET @@location='us-central1';
SELECT
  *
FROM
  `query_project.dataset.my_table`
  JOIN `data_project.dataset.my_other_table` USING id;

Damit diese globale Abfrage erfolgreich ausgeführt werden kann, ist die folgende Konfiguration erforderlich:

Sie müssen die Ausführung globaler Abfragen im Projekt (query_project) in der Region aktivieren, in der eine globale Abfrage ausgeführt wird (us-central1):
```
ALTER PROJECT `query_project`
SET OPTIONS (
`region-us-central1.enable_global_queries_execution` = TRUE
)
```
Sie müssen das Kopieren von Daten durch globale Abfragen aus dem Projekt, das die Daten enthält (data_project), für die zugehörige Region (europe-west1) aktivieren:
```
ALTER PROJECT `data_project`
SET OPTIONS (
`region-europe-west1.enable_global_queries_data_access` = TRUE
)
```

Für das Erstellen und Verwenden von Ansichten, die externe Tabellen enthalten, gelten dieselben Grundsätze: Im Projekt, in dem die Abfragen ausgeführt werden, muss enable_global_queries_execution aktiviert sein.

Diese ALTER PROJECT-Vorgänge müssen separat ausgeführt werden, da sie sich auf unterschiedliche Projekte und Regionen beziehen. Es kann einige Minuten dauern, bis die Änderung wirksam wird.

Erforderliche Berechtigung

Zum Ausführen einer globalen Abfrage benötigen Sie die Berechtigung bigquery.jobs.createGlobalQuery. Die Rolle „BigQuery-Administrator“ ist die einzige vordefinierte Rolle, die diese Berechtigung enthält. So erteilen Sie die Berechtigung zum Ausführen globaler Abfragen, ohne die Rolle „BigQuery-Administrator“ zu gewähren:

Erstellen Sie eine benutzerdefinierte Rolle, z. B. „BigQuery global queries executor“ (Globale BigQuery-Abfragen ausführen).
Fügen Sie dieser Rolle bigquery.jobs.createGlobalQuery hinzu.
Weisen Sie diese Rolle ausgewählten Nutzern oder Dienstkonten zu.

Daten abfragen

Wenn Sie eine globale Abfrage ausführen möchten, schreiben Sie eine SQL-Abfrage so, als wären Ihre Daten an einem einzigen Ort. Wenn die von der Abfrage referenzierten Daten an mehreren Standorten gespeichert sind, versucht BigQuery, eine globale Abfrage auszuführen. Wenn Sie keinen Standort für die Ausführung der Abfrage angeben, wählt BigQuery den Standort automatisch anhand der Standorte der referenzierten Tabellen aus. Weitere Informationen finden Sie unter Standort auswählen. Daten, auf die in der Abfrage verwiesen wird und die sich nicht am ausgewählten Standort befinden, werden an diesen Standort kopiert.

Im folgenden Beispiel wird eine globale Abfrage ausgeführt, mit der Tabellen aus zwei verschiedenen Datasets zusammengeführt werden, die an zwei verschiedenen Standorten gespeichert sind:

SELECT id, tr_date, product_id, price FROM us_dataset.transactions
UNION ALL
SELECT id, tr_date, product_id, price FROM europe_dataset.transactions

Standort wählen

Geben Sie einen Standort an, um zu konfigurieren, wo die globale Abfrage ausgeführt werden soll. Berücksichtigen Sie bei der Auswahl eines Ausführungsorts für die globale Abfrage Folgendes:

Datenstandort: Bei globalen Abfragen werden Daten vorübergehend von einem Ort an einen anderen kopiert. Wenn Ihre Organisation Anforderungen an den Datenstandort hat und Sie nicht möchten, dass Ihre Daten einen bestimmten Standort verlassen, legen Sie den Abfragestandort auf diesen Standort fest.
Übertragungskosten und Leistung:Um die Menge der Daten zu minimieren, die zwischen Standorten übertragen werden, und die Kosten der Abfrage zu senken, führen Sie die Abfrage in der Region aus, in der die meisten abgefragten Daten gespeichert sind.

Angenommen, Sie haben einen Onlineshop und führen eine Liste Ihrer Produkte am Standort us-central1, Ihre Transaktionen werden jedoch in der Region us-south1 gespeichert. Wenn es mehr Transaktionen als Produkte in Ihrem Katalog gibt, sollten Sie die Abfrage in der Region us-south1 ausführen.
Reservierungen und Rechenkapazität:Geben Sie den Abfrageort an, um zu steuern, welche regionalen Reservierungen oder Slots die Abfrage verarbeiten.

Wenn Sie keinen Speicherort manuell angeben, bestimmt BigQuery den Ausführungsspeicherort automatisch anhand der folgenden Kriterien:

Bei DML-Abfragen (INSERT-, UPDATE- und DELETE-Anweisungen) wird der Standort der Zieltabelle als Ausführungsort ausgewählt.
Bei DDL-Abfragen (Data Definition Language, Datendefinitionssprache) wie CREATE TABLE AS SELECT-Anweisungen wird der Ort, an dem die Ressource erstellt oder geändert wird, als Ausführungsort ausgewählt.
Bei Abfragen mit einer angegebenen Zieltabelle wird der Speicherort der Zieltabelle als Ausführungsort ausgewählt.
Bei allen anderen Abfragen wird der Ausführungsort willkürlich als einer der Standorte der referenzierten Datasets ausgewählt.

Globale Abfragen

Damit globale Abfragen effizient und kostengünstig ausgeführt werden können, ist es wichtig, den Mechanismus hinter ihrer Ausführung zu verstehen.

Wenn Sie Daten verwenden möchten, die sich an verschiedenen Standorten befinden, müssen sie an einen Standort repliziert werden. Das Folgende ist eine Abstraktion des globalen Abfrageworkflows, der von BigQuery ausgeführt wird:

Legen Sie fest, wo die Abfrage ausgeführt werden muss: entweder gemäß der Erklärung des Nutzers oder automatisch. Dieser Speicherort wird als primärer Speicherort bezeichnet. Alle anderen Speicherorte, auf die in der Abfrage verwiesen wird, sind remote.
Führen Sie in jeder Remote-Region eine untergeordnete Abfrage aus, um die Daten zu erfassen, die zum Abschließen der Abfrage in der primären Region erforderlich sind.
Kopieren Sie diese Daten von Remote-Standorten an den primären Standort.
Speichern Sie die Daten 24 Stunden lang in temporären Tabellen am primären Standort.
Führen Sie eine letzte Abfrage mit allen am primären Standort erhobenen Daten aus.
Die Abfrageergebnisse zurückgeben

BigQuery versucht, die Menge der Daten, die zwischen Regionen übertragen werden, zu minimieren. Dazu ein Beispiel:

SET @@location = 'EU';
SELECT
  t1.col1, t2.col2
FROM
  eu_dataset.table1 t1
  JOIN us_dataset.table2 t2 using col3
WHERE
  t2.col4 = 'ABC'

BigQuery muss nicht die gesamte Tabelle t2 aus den USA in die EU replizieren. Es reicht aus, nur die angeforderten Spalten (col2 und col3) und nur die Zeilen zu übertragen, die der Bedingung WHERE (t2.col4 = 'ABC') entsprechen. Diese Mechanismen, die als Pushdowns bezeichnet werden, hängen jedoch von der Abfragestruktur ab und manchmal kann die Menge der übertragenen Daten groß sein. Wir empfehlen, globale Abfragen mit einer kleinen Teilmenge von Daten zu testen und zu prüfen, ob Daten nur bei Bedarf übertragen werden.

Beobachtbarkeit

Sie haben folgende Möglichkeiten, globale Abfragen zu überwachen und ihre Ausführung in verschiedenen Regionen zu prüfen:

Jobverlauf

Den an die Remote-Region gesendeten Abfragetext finden Sie im Jobverlauf. Der Remote-Job hat dieselbe Job-ID wie die ursprüngliche Abfrage, jedoch mit dem zusätzlichen Suffix _xregion.

Jobs REST API

Wenn Sie die Methode jobs.get aufrufen, enthält die zurückgegebene Ressource Job die folgenden Felder im Objekt JobStatistics:

statistics.globalQueryRemoteRegions: Ein Array von Strings, das die Remote-Regionen darstellt, aus denen bei einer globalen Abfrage auf Daten zugegriffen wird. Dieses Feld wird nur für übergeordnete globale Abfragejobs in der primären Ausführungsregion ausgefüllt. Für untergeordnete globale Abfragejobs und Abfragen für einzelne Regionen ist das Feld leer.
statistics.parentGlobalQueryJob: Ein JobReference-Objekt (projectId, jobId, location), das den übergeordneten globalen Abfragejob identifiziert. Dieses Feld wird nur für untergeordnete globale Abfragejobs (Remote-Unterabfragen und regionenübergreifende Kopierjobs) ausgefüllt, die im Auftrag einer globalen Abfrage in Remote-Regionen ausgeführt werden. Für übergeordnete globale Abfragejobs und Abfragen mit einer einzelnen Region ist sie nicht festgelegt.

Audit-Logs

In Cloud-Audit-Logs enthält das Objekt BigQueryAuditMetadata die folgenden Felder im Objekt JobStats:

jobStats.globalQueryRemoteRegions: Ein Array von Strings, das die Remote-Regionen darstellt, auf die über die Abfrage zugegriffen wird. Dieses Feld wird nur für übergeordnete globale Abfragejobs in der primären Ausführungsregion ausgefüllt.
jobStats.parentGlobalQueryJobId: Die Job-ID des übergeordneten globalen Abfragejobs. Dieses Feld wird für untergeordnete Jobs ausgefüllt, die in Remote-Regionen ausgeführt werden.
jobStats.parentGlobalQueryJobLocation: Der Speicherort des übergeordneten globalen Abfragejobs. Dieses Feld wird für untergeordnete Jobs ausgefüllt, die in Remote-Regionen ausgeführt werden.

Untergeordnete Remote-Jobs für eine globale Abfrage finden

Wenn Sie alle untergeordneten Remote-Jobs finden möchten, die mit einer übergeordneten globalen Abfrage verknüpft sind, können Sie Audit-Logs mit Log Analytics oder einem exportierten Logsenken-Dataset abfragen:

SELECT
  timestamp,
  proto_payload.audit_log.resource_name AS resource_name,
  JSON_VALUE(proto_payload.audit_log.metadata.jobChange.job.jobConfig.queryConfig.query) AS query
FROM
  `PROJECT_ID.LOG_DATASET._AllLogs`
WHERE
  JSON_VALUE(proto_payload.audit_log.metadata.jobChange.job.jobStats.parentGlobalQueryJobId) = 'PARENT_JOB_ID';

Ersetzen Sie Folgendes:

PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
LOG_DATASET: Das verknüpfte BigQuery-Dataset für Log Analytics oder das Ziel-Dataset für den Logsink.
PARENT_JOB_ID: die Job-ID des übergeordneten globalen Abfragejobs.

Globale Abfragen deaktivieren

Wenn Sie globale Abfragen für Ihr Projekt oder Ihre Organisation deaktivieren möchten, verwenden Sie ALTER PROJECT SET OPTIONS statement oder ALTER ORGANIZATION SET OPTIONS statement, um die Standardkonfiguration zu ändern.

Wenn Sie globale Anfragen in einer Region deaktivieren möchten, legen Sie das Argument enable_global_queries_execution in dieser Region auf false oder NULL fest.
Wenn Sie verhindern möchten, dass bei globalen Abfragen Daten aus einer Region kopiert werden, legen Sie das Argument enable_global_queries_data_access in dieser Region auf false oder NULL fest.

Das folgende Beispiel zeigt, wie Sie globale Abfragen auf Projektebene deaktivieren:

ALTER PROJECT PROJECT_ID
SET OPTIONS (
  `region-REGION.enable_global_queries_execution` = false,
  `region-REGION.enable_global_queries_data_access` = false
);

Ersetzen Sie Folgendes:

PROJECT_ID: Der Name des zu ändernden Projekts.
REGION: der Name der Region, in der globale Abfragen deaktiviert werden sollen

Es kann einige Minuten dauern, bis die Änderung wirksam wird.

Preise

Die Kosten für eine globale Abfrage bestehen aus den folgenden Komponenten:

Die Rechenkosten jeder Unterabfrage an Remote-Standorten basierend auf Ihrem Preismodell an diesen Standorten
Die Rechenkosten der endgültigen Abfrage in der Region, in der sie ausgeführt wird, basierend auf Ihrem Preismodell in dieser Region
Die Kosten für das Kopieren von Daten zwischen verschiedenen Standorten gemäß den Preisen für die Datenreplikation
Die Kosten für das Speichern von Daten, die aus Remote-Regionen in die primäre Region kopiert wurden (für 24 Stunden), gemäß den Speicherpreisen

Kontingente

Informationen zu Kontingenten für globale Abfragen finden Sie unter Abfragejobs.

Beschränkungen

Globale Abfragen werden in Assured Workloads nicht unterstützt.
Globale Abfragen werden bei Verwendung von regionalen Endpunkten nicht unterstützt.
Globale Abfragen werden im Sandbox-Modus nicht unterstützt.
Globale Abfragen haben eine höhere Latenz als Abfragen für einzelne Regionen, da die Übertragung von Daten zwischen Regionen Zeit in Anspruch nimmt.
Bei globalen Abfragen wird kein Cache verwendet, um die Übertragung von Daten zwischen Regionen zu vermeiden.
Globale Abfragen werden nicht atomar ausgeführt. Wenn die Datenreplikation erfolgreich ist, die Gesamtabfrage jedoch fehlschlägt, wird Ihnen die Datenreplikation trotzdem in Rechnung gestellt.
Eine einzelne globale Abfrage kann pro Region auf bis zu 10 Remotetabellen zugreifen.
Temporäre Tabellen, die in Remote-Regionen als Teil der Ausführung globaler Abfragen erstellt werden, werden nur mit kundenverwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEK) verschlüsselt, wenn ein CMEK-Schlüssel, der zum Verschlüsseln der globalen Abfrageergebnisse konfiguriert wurde (entweder auf Tabellen-, Dataset- oder Projektebene), global ist. Damit temporäre Remotetabellen immer mit CMEK geschützt sind, legen Sie einen standardmäßigen KMS-Schlüssel für das Projekt fest, in dem globale Abfragen in der Remote-Region ausgeführt werden.
Globale autorisierte Ansichten und autorisierte Routinen werden nicht unterstützt (wenn eine Ansicht oder Routine an einem Standort für den Zugriff auf ein Dataset an einem anderen Standort autorisiert ist). Erstellen Sie stattdessen autorisierte Ansichten in der Region, in der sich Ihre Daten befinden, und führen Sie globale Abfragen für die autorisierten Ansichten aus.
Materialisierte Ansichten für globale Abfragen werden nicht unterstützt.
Spalten vom Typ RANGE können nicht mit globalen Abfragen abgefragt werden.
Sie können Pseudospalten wie _PARTITIONTIME nicht mit globalen Abfragen abfragen.
Mit globalen Abfragen können Sie keine Spalten mit flexiblen Spaltennamen abfragen.
Wenn Ihre globale Abfrage auf STRUCT-Spalten verweist, werden keine Pushdowns auf Remote-Unterabfragen angewendet. Um die Leistung zu optimieren, können Sie in der Remote-Region eine Ansicht erstellen, in der STRUCT-Spalten gefiltert und nur die erforderlichen Felder als einzelne Spalten zurückgegeben werden.
In den Ausführungsdetails und dem Ausführungsdiagramm einer Abfrage wird die Anzahl der Byte, die von Remote-Standorten verarbeitet und übertragen werden, nicht angezeigt. Diese Informationen werden in Kopierjobs angezeigt, die Sie in Ihrem Jobverlauf finden. Die Job-ID eines Kopierjobs, der durch eine globale Abfrage erstellt wurde, hat die Job-ID des Abfragejobs als Präfix.
Globale Abfragen werden in Data Studio nur unterstützt, wenn sie in einer Ansicht enthalten sind und für die Verwendung von Anmeldedaten des Betrachters konfiguriert sind.