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

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, legen Sie das Argument enable_global_queries_execution für das Projekt, in dem die Abfrage ausgeführt wird, in dieser Region auf true fest.
Damit globale Abfragen Daten aus einer Region kopieren können, legen Sie das Argument enable_global_queries_data_access in dieser Region für das Projekt mit den Daten auf true fest.
Diese Optionen werden immer geprüft, wenn in Ihrer Abfrage auf Remote-Tabellen zugegriffen wird.
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 über 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
);
```

Wenn Sie Ansichten mit Remotetabellen erstellen und verwenden möchten, gelten dieselben Grundsätze: Für das 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“.
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 Orten 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 Orten 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 festzulegen, wo die globale Abfrage ausgeführt werden soll. Bei der Entscheidung für einen Ausführungsort für die globale Abfrage sollten Sie Folgendes berücksichtigen:

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 Abfragespeicherort 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 Abfragestandort an, um zu steuern, welche regionalen Reservierungen oder Slots die Abfrage verarbeiten.

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

Bei DML-Abfragen (INSERT-, UPDATE- und DELETE-Anweisungen) wird der Standort der Zieltabelle als Ausführungsstandort ausgewählt.
Bei Datendefinitionssprache (DDL)-Abfragen (z. B. 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 Orte 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. Im Folgenden sehen Sie eine Abstraktion des globalen Abfrageworkflows, der von BigQuery ausgeführt wird:

Legen Sie fest, wo die Abfrage ausgeführt werden muss: entweder über die Erklärung des Nutzers oder automatisch. Dieser Standort wird als primärer Standort bezeichnet. Alle anderen Standorte, 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 bestätigen, dass Daten nur bei Bedarf übertragen werden.

Beobachtbarkeit

Sie haben folgende Möglichkeiten, globale Abfragen zu beobachten 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 mit dem zusätzlichen Suffix _xregion.

Jobs REST API

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

statistics.global_query_remote_regions: Ein Array von Strings, das die Remote-Regionen darstellt, aus denen eine globale Abfrage Daten abruft. Dieses Feld wird nur für übergeordnete globale Abfragejobs in der primären Ausführungsregion ausgefüllt. Für untergeordnete globale Abfragejobs und Abfragen mit einer einzelnen Region ist das Feld leer.
statistics.parent_global_query_job: 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 der Wert 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 durch 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 Standort 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 der Logs-Senke.
PARENT_JOB_ID: die Job-ID des übergeordneten globalen Abfragejobs.

Globale Anfragen 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 ist der Name der Region, in der globale Abfragen deaktiviert werden sollen.

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

Preise

Die Kosten einer globalen Abfrage setzen sich aus 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

In den Ausführungsdetails und dem Ausführungsdiagramm einer Abfrage wird nicht die Anzahl der Byte angezeigt, die von Remote-Standorten verarbeitet und übertragen wurden. 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 im Sandbox-Modus nicht unterstützt.
Globale Abfragen werden bei Verwendung von regionalen Endpunkten 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.
Pseudospalten wie _PARTITIONTIME können nicht mit globalen Abfragen abgefragt werden.
Sie können Spalten vom Typ RANGE nicht mit globalen Abfragen abfragen.
Sie können keine Spalten mit flexiblen Spaltennamen in globalen Abfragen abfragen.
Sie können INFORMATION_SCHEMA-Ansichten in einer globalen Abfrage nicht aus einer Remote-Region abfragen.
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.
Wenn Ihre globale Abfrage auf STRUCT-Spalten verweist, werden keine Pushdowns auf Remote-Unterabfragen angewendet. Zur Leistungsoptimierung können Sie eine Ansicht in der Remote-Region erstellen, in der STRUCT-Spalten gefiltert und nur die erforderlichen Felder als einzelne Spalten zurückgegeben werden.
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.
Temporäre Tabellen, die in Remote-Regionen im Rahmen der Ausführung globaler Abfragen erstellt werden, werden nur mit vom Kunden verwalteten 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 Abfragen werden in Assured Workloads nicht unterstützt.
Eine einzelne globale Abfrage kann pro Region auf bis zu 10 Remotetabellen zugreifen.
Globale Abfragen werden in Data Studio nur unterstützt, wenn sie in einer Datenansicht enthalten sind und für die Anmeldedaten des Betrachters konfiguriert sind.