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 mehr als einer Region gespeichert sind. Sie können beispielsweise eine globale Abfrage ausführen, die eine Tabelle in us-central1 mit einer Tabelle in europe-central2 verknüpft. In diesem Dokument wird erläutert, 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

Wenn Sie globale Abfragen für Ihr Projekt oder Ihre Organisation aktivieren möchten, verwenden Sie die ALTER PROJECT SET OPTIONS-Anweisung oder die ALTER ORGANIZATION SET OPTIONS-Anweisung, um 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, das die Abfrage ausführt, auf true.
Wenn Sie globalen Abfragen erlauben möchten, Daten aus einer Region zu kopieren, setzen Sie das Argument enable_global_queries_data_access in dieser Region für das Projekt, das die Daten enthält, auf true.
Diese Optionen werden immer geprüft, wenn Ihre Abfrage auf Remote-Tabellen zugreift.
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, die auf eine Tabelle data_project.dataset.my_table in der Region europe-west1 zugreift:

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 entsprechende 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 Remote-Tabellen enthalten, gelten dieselben Prinzipien: 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 gewähren Sie die Berechtigung zum Ausführen globaler Abfragen, ohne die Rolle „BigQuery-Administrator“ zuzuweisen:

Erstellen Sie eine benutzerdefinierte Rolle, z. B. „BigQuery global queries executor“.
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 ob sich Ihre Daten an einem einzigen Standort befinden würden. Wenn die von der Abfrage referenzierten Daten an mehreren Standorten gespeichert sind, versucht BigQuery, eine globale Abfrage auszuführen. Wenn Sie den Standort für die Ausführung der Abfrage nicht 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 die Abfrage verweist und die sich nicht am ausgewählten Standort befinden, werden dorthin kopiert.

Das folgende Beispiel wird als globale Abfrage ausgeführt, die Tabellen aus zwei verschiedenen Datasets an zwei verschiedenen Standorten zusammenführt:

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

Wenn Sie konfigurieren möchten, wo die globale Abfrage ausgeführt wird, geben Sie einen Standort an. Berücksichtigen Sie bei der Entscheidung für einen Ausführungsort für die globale Abfrage Folgendes:

Datenstandort: Bei globalen Abfragen werden Daten vorübergehend von einem Standort 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: Wenn Sie die Menge der zwischen Standorten übertragenen Daten minimieren und die Kosten der Abfrage reduzieren möchten, führen Sie die Abfrage in der Region aus, in der die meisten der abgefragten Daten gespeichert sind.

Angenommen, Sie haben einen Onlineshop und speichern eine Liste Ihrer Produkte am Standort us-central1, Ihre Transaktionen jedoch in der Region us-south1. 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 Abfragestandort an, um festzulegen, welche regionalen Reservierungen oder Slots die Abfrage verarbeiten.

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

Bei DML-Abfragen (Data Modification Language, Datenänderungssprache) (INSERT-, UPDATE- und DELETE-Anweisungen) wird der Standort der Zieltabelle als Ausführungsstandort ausgewählt.
Bei DDL-Abfragen (Datendefinitionssprache) wie CREATE TABLE AS SELECT-Anweisungen wird der Standort, an dem die Ressource erstellt oder geändert wird, als Ausführungsstandort 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 verstehen

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. Im Folgenden finden Sie eine Abstraktion des globalen Abfrage-Workflows, der von BigQuery ausgeführt wird:

Legen Sie fest, wo die Abfrage ausgeführt werden muss, entweder anhand der Deklaration des Nutzers oder automatisch. Dieser Standort wird als primärer Standort bezeichnet. Alle anderen Standorte, auf die in der Abfrage verwiesen wird, sind Remote-Standorte.
Führen Sie in jeder Remote-Region eine Unterabfrage 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. Bei Unterabfrageergebnissen, die kleiner als 10 GiB sind, werden die Daten möglicherweise zur Wiederverwendung im Cache gespeichert, um die Übertragung der Daten zwischen Regionen zu vermeiden.
Führen Sie eine letzte Abfrage mit allen am primären Standort erfassten Daten aus.
Die Abfrageergebnisse zurückgeben.

BigQuery versucht, die zwischen Regionen übertragene Datenmenge 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 von den USA in die EU replizieren. Es reicht aus, nur die angeforderten Spalten (col2 und col3) und nur die Zeilen zu übertragen, die der WHERE-Bedingung (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

Wenn Sie globale Abfragen überwachen und ihre Ausführung über Regionen hinweg prüfen möchten, können Sie die folgenden Methoden verwenden:

Jobverlauf

Den Abfragetext, der an die Remote-Region gesendet wurde, 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, die die Remote-Regionen darstellen, auf die eine globale Abfrage zugreift. Dieses Feld wird nur für übergeordnete globale Abfragejobs in der primären Ausführungsregion ausgefüllt. Bei untergeordneten globalen Abfragejobs und Abfragen für eine einzelne Region ist es 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 in einer einzelnen Region ist es 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, die die Remote-Regionen darstellen, auf die die Abfrage zugreift. 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 Standort des übergeordneten globalen Abfragejobs. Dieses Feld wird für untergeordnete Jobs ausgefüllt, die in Remote-Regionen ausgeführt werden.

Remote-untergeordnete Jobs für eine globale Abfrage finden

Wenn Sie alle Remote-Unterjobs 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 mit BigQuery verknüpfte Dataset für Loganalysen oder das Ziel-Dataset der Logsenke.
PARENT_JOB_ID: die Job-ID des übergeordneten globalen Abfragejobs.

INFORMATION_SCHEMA-Ansichten

Sie können die Ansichten INFORMATION_SCHEMA.JOBS und INFORMATION_SCHEMA.JOBS_TIMELINE abfragen, um Metadaten für globale Abfragen zu prüfen. Die Spalte global_query_info enthält die folgenden Felder:

parent_job_id: Die ID des übergeordneten globalen Abfragejobs in der primären Region. Dieses Feld wird für untergeordnete Unterabfragen und Kopierjobs ausgefüllt, die in Remote-Regionen ausgeführt werden.
parent_job_location: Der Standort des übergeordneten globalen Abfragejobs.
remote_regions: Ein Array von Remote-Regionen, auf die in der Abfrage verwiesen wird. Dieses Feld wird für den übergeordneten globalen Abfragejob in der primären Region ausgefüllt.

Globale Abfragen in einer primären Region identifizieren

Wenn Sie alle globalen Abfragen finden möchten, die in einer primären Region ausgeführt wurden, und sehen möchten, auf welche Remote-Regionen verwiesen wurde, fragen Sie die Ansicht INFORMATION_SCHEMA.JOBS in der primären Region ab:

SELECT
  job_id,
  creation_time,
  query,
  total_bytes_billed,
  global_query_info.remote_regions
FROM
  `region-REGION`.INFORMATION_SCHEMA.JOBS
WHERE
  ARRAY_LENGTH(global_query_info.remote_regions) > 0;

Ersetzen Sie REGION durch die Region, in der die globale Abfrage ausgeführt wurde, z. B. us-central1.

Remote-untergeordnete Jobs für eine globale Abfrage finden

Wenn Sie alle Remote-Unterjobs finden möchten, die mit einer übergeordneten globalen Abfrage verknüpft sind, fragen Sie die Ansicht INFORMATION_SCHEMA.JOBS in der Remote-Region ab:

SELECT
  job_id,
  project_id,
  job_type,
  statement_type,
  total_bytes_billed,
  total_slot_ms
FROM
  `region-REMOTE_REGION`.INFORMATION_SCHEMA.JOBS
WHERE
  global_query_info.parent_job_id = 'PARENT_JOB_ID';

Ersetzen Sie Folgendes:

REMOTE_REGION: die Remote-Region, in der die untergeordnete Unterabfrage oder der Kopierjob ausgeführt wurde, z. B. europe-west1.
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 Abfragen in einer Region deaktivieren möchten, setzen Sie das Argument enable_global_queries_execution in dieser Region auf false oder NULL.
Wenn Sie verhindern möchten, dass globale Abfragen Daten aus einer Region kopieren, setzen Sie das Argument enable_global_queries_data_access in dieser Region auf false oder NULL.

Im folgenden Beispiel wird gezeigt, wie globale Abfragen auf Projektebene deaktiviert werden:

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 setzen sich aus den folgenden Komponenten zusammen:

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 nicht unterstützt, wenn regionale Endpunkte verwendet werden.
Globale Abfragen werden im Sandbox-Modus nicht unterstützt.
Globale Abfragen weisen aufgrund der Zeit, die für die Übertragung von Daten zwischen Regionen erforderlich ist, eine höhere Latenz auf als Abfragen in einer einzelnen Region.
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 auf bis zu 10 Remote-Tabellen pro Region zugreifen.
Temporäre Tabellen, die im Rahmen der Ausführung globaler Abfragen in Remote-Regionen erstellt werden, werden nur dann mit kundenverwalteten Verschlüsselungsschlüsseln (CMEK) verschlüsselt, wenn ein CMEK-Schlüssel, der für die Verschlüsselung der globalen Abfrageergebnisse konfiguriert wurde (entweder auf Tabellen-, Dataset- oder Projektebene), global ist. Damit temporäre Remote-Tabellen immer mit CMEK geschützt sind, legen Sie einen Standard-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 autorisiert ist, auf ein Dataset an einem anderen Standort zuzugreifen). Erstellen Sie stattdessen autorisierte Ansichten in der Region, in der sich Ihre Daten befinden, und fragen Sie die autorisierten Ansichten über globale Abfragen ab.
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.
Sie können Spalten mit flexiblen Spaltennamen nicht mit globalen Abfragen abfragen.
Wenn Ihre globale Abfrage auf STRUCT-Spalten verweist, werden keine Pushdowns auf Remote-Unterabfragen angewendet. Zur Leistungsoptimierung können Sie in der Remote-Region eine Ansicht erstellen, die STRUCT-Spalten filtert und nur die erforderlichen Felder als einzelne Spalten zurückgibt.
In den Ausführungsdetails und im Ausführungsdiagramm einer Abfrage wird die Anzahl der verarbeiteten und von Remote-Standorten übertragenen Byte nicht angezeigt. Diese Informationen werden in Kopierjobs angezeigt, die Sie in Ihrem Jobverlauf finden. Die Job-ID eines Kopierjobs, der von einer globalen Abfrage erstellt wurde, hat die Job-ID des Abfragejobs als Präfix.
Globale Abfragen werden in Data Studio nur unterstützt, wenn sie in eine Ansicht eingebunden und für die Verwendung der Anmeldedaten des Betrachters konfiguriert sind.