Fehlerbehebung bei BigQuery-Connector-Fehlern und ‑Einschränkungen

Wenn Sie Data Studio mit BigQuery verbinden, kann es zu Zeitüberschreitungen, SQL-Syntaxlimits, Kontingentlimits oder VPC Service Controls-Fehlern kommen. In diesem Leitfaden werden häufige Probleme mit dem BigQuery-Connector beschrieben. Maximieren Sie Schritte zur Behebung, um das Problem zu untersuchen und zu beheben.

Abfrage- und SQL-Syntaxfehler

Für benutzerdefinierte SQL-Abfragen in Data Studio gelten bestimmte Einschränkungen. Wenn Ihre Abfrage diese Limits überschreitet, können Fehler auftreten.

Field is ambiguous-Join-Fehler

Wenn Ihre benutzerdefinierte Abfrage doppelte Spaltennamen enthält, wird in Diagrammen dieser Fehler angezeigt:

User Configuration Error: Field is ambiguous

Fehlermeldungstext: Nutzerkonfigurationsfehler

Ursache: Verknüpfte Tabellen (JOIN) dürfen keine doppelten Spaltennamen enthalten. Wenn Sie beispielsweise zwei Tabellen mit identischen Schemas über ein Criteria_ID-Feld verknüpfen, enthält die resultierende virtuelle Tabelle doppelte Spalten (Criteria_ID, Parent_ID, Name), was einen Mehrdeutigkeitsfehler auslöst.

Schritte zur Fehlerbehebung

Verwenden Sie das Schlüsselwort AS oder die EXCEPT-Klausel, um alle Spaltennamen eindeutig zu machen:

Option 1: Doppelte Felder explizit mit Aliasen umbenennen

SELECT *
FROM (
  SELECT
    Criteria_ID AS Criteria_ID_1,
    Parent_ID AS Parent_ID_1,
    Name AS NAME_1
  FROM
    `project.dataset.table_1` ) AS table_1
LEFT JOIN (
  SELECT
    Criteria_ID AS Criteria_ID_2,
    Parent_ID AS Parent_ID_2,
    Name AS NAME_2
  FROM
    `project.dataset.table_2` ) AS table_2
ON
  table_1.Criteria_ID_1 = table_2.Criteria_ID_2;

Option 2: Bestimmte Felder mit EXCEPT ausschließen und umbenennen

Wenn Sie nur eine kleine Anzahl von Feldern umbenennen und die restlichen beibehalten möchten, verwenden Sie EXCEPT:

SELECT * EXCEPT (city), city AS city_1 FROM `project.dataset.table_1`

Syntaxfehler in benutzerdefinierter SQL-Abfrage (mehrere Anweisungen)

Ihre benutzerdefinierte SQL-Abfrage schlägt fehl, wenn sie Variablen oder mehrere Anweisungen (DECLARE, SET) enthält.

Ursache: In Data Studio wird Ihre SQL-Abfrage innerhalb einer äußeren SELECT-Abfrage (SELECT * FROM (<your_custom_sql>)) ausgeführt. Daher muss Ihre Abfrage eine einzelne SELECT-Anweisung sein.

Die folgende Abfrage schlägt beispielsweise fehl, weil eine Variable vor der Auswahl deklariert wird:

DECLARE cost_per_tb_in_dollar FLOAT64 DEFAULT 4.2;
SELECT total_bytes_billed / (1024 * 1024) * cost_per_tb_in_dollar / (1024 * 1024) FROM `billing_table`;

Schritte zur Fehlerbehebung

Kombinieren Sie Berechnungen mithilfe von allgemeinen Tabellenausdrücken (Common Table Expressions, CTEs oder WITH-Klauseln) in einer einzigen SELECT-Anweisung:

WITH constants AS (
  SELECT 4.2 AS cost_per_tb_in_dollar
)
SELECT
  total_bytes_billed / (1024 * 1024) * c.cost_per_tb_in_dollar / (1024 * 1024) AS cost
FROM `billing_table`, constants AS c;

Leistung und Abfrage-Zeitüberschreitungen

Wenn Abfragen länger als drei bis fünf Minuten dauern, kommt es in Data Studio zu einer Zeitüberschreitung, bevor Ergebnisse empfangen werden. Es wird dann Folgendes zurückgegeben: HTTP 504 Gateway timeout.

HTTP 504 Gateway timeout-Fehler oder Fehler bei lang andauernden Abfragen

Bei benutzerdefinierten Abfragen oder komplexen Diagrammaggregationen in Data Studio kann es nach drei bis fünf Minuten zu einer Zeitüberschreitung kommen, die den Fehler HTTP 504 Gateway timeout zurückgibt.

Schritte zur Fehlerbehebung

Wenn bei Ihren Abfragen immer wieder Zeitüberschreitungen auftreten, können Sie diese Optimierungen verwenden:

  • BigQuery Storage Read API aktivieren: Aktivieren Sie die BigQuery Storage Read API, um den Datendurchsatz zu erhöhen.
  • Abfrage vereinfachen: Entfernen Sie nicht benötigte JOIN-Befehle, gruppieren Sie Daten nach größeren Zeiträumen und wählen Sie nur die erforderlichen Spalten aus.
  • BigQuery BI Engine verwenden: Reservieren Sie Kapazität mit BigQuery BI Engine für eine Leistung von weniger als einer Sekunde.
  • Datenbankansichten verwenden: Speichern Sie Ihr benutzerdefiniertes SQL als BigQuery-Ansicht oder materialisierte Ansicht und verbinden Sie Data Studio direkt mit dieser Ansicht.
  • In einer Berichtstabelle vorab aggregieren: Verwenden Sie geplante Abfragen in BigQuery, um Zusammenfassungsdatensätze in eine separate Tabelle zu schreiben, und fragen Sie die Zusammenfassungstabelle ab.

Kontingente und Tabellenbeschränkungen

Wenn Ihr Dataset Tausende von Tabellen enthält oder Millionen von Datensätzen zurückgibt, können Limitfehler auftreten:

Dataset mit mehr als 5.000 Tabellen – UI reagiert nicht mehr

Wenn Sie versuchen, über die Tabellenauswahlliste in Data Studio eine Verbindung zu einem BigQuery-Dataset herzustellen, friert die Benutzeroberfläche ein oder reagiert nicht mehr.

Ursache: Der Connector unterstützt bis zu 5.000 Tabellen pro Dataset. Wenn ein Dataset mehr als 5.000 Tabellen oder Ansichten enthält, kommt es zu einer Zeitüberschreitung und die Tabellenauswahlliste friert ein.

Schritte zur Fehlerbehebung

Verwenden Sie eine der folgenden Alternativen, um eine Verbindung herzustellen, ohne die Tabellenliste zu laden:

  • Mit einer benutzerdefinierten Abfrage verbinden: Wählen Sie BENUTZERDEFINIERTE ABFRAGE aus und schreiben Sie eine weniger komplexe SELECT-Anweisung: 
    SELECT * FROM `your_project.your_dataset.your_table`
  • Direkt über BigQuery verbinden: Suchen Sie in der BigQuery-Konsole nach Ihrer Tabelle, klicken Sie auf Exportieren oder Daten explorativ analysieren und wählen Sie Mit Looker Studio öffnen aus.
  • Dataset aufteilen oder neu organisieren: Verschieben Sie Berichtstabellen in kleinere, dedizierte Berichts-Datasets,die weniger als 5.000 Tabellen enthalten.

Maximal 2 Millionen Zeilen können zurückgegeben werden

Wenn Sie große Datasets visualisieren, wird in Ihrem Diagramm möglicherweise eine Warnung zur Datenkürzung angezeigt oder Zeilen mit mehr als 2 Millionen Datensätzen werden weggelassen.

Ursache: Der Connector gibt maximal 2 Millionen Zeilen pro Diagrammabfrage zurück. Wenn eine Abfrage mehr als 2 Millionen Datensätze umfasst, werden die Daten in Diagrammen abgeschnitten und es wird eine Warnung angezeigt.

Schritte zur Fehlerbehebung

So verhindern Sie, dass Daten abgeschnitten werden:

  • Wenden Sie Datumsfilter auf Berichtsebene an, um das Abfragevolumen einzugrenzen.
  • Nach Datum partitionierte Tabellen (`DATE`, `DATETIME`, `TIMESTAMP`) abfragen, für die Partitionsfilter erforderlich sind (Weitere Informationen).
  • Gruppieren Sie Dimensionen mit hoher Kardinalität in BigQuery, bevor Sie sie in Data Studio visualisieren.

MEDIAN- und PERCENTILE-Varianz

Wenn Sie genaue Mediane (MEDIAN) oder Perzentile (PERCENTILE) in Diagrammen berechnen, die mit BigQuery verbunden sind, kann die Ausgabe geringfügig von identischen Berechnungen abweichen, die in anderen SQL-Datenbanken oder CSV-Exporten durchgeführt werden.

Ursache: In BigQuery-Abfragen verwenden MEDIAN und PERCENTILE die ungefähre Aggregationsfunktion APPROX_QUANTILES. So können Datasets im Petabyte-Bereich schnell verarbeitet werden. Die ungefähren Ergebnisse können jedoch geringfügig von den genauen Berechnungen abweichen, die für CSV-Exporte oder andere SQL-Datenbanken durchgeführt werden.

Datentyp- und Verschlüsselungsfehler

Informationen zum Umgang mit nicht unterstützten Spaltentypen und von der Organisation erzwungenen Schlüsselverschlüsselungsrichtlinien.

CONDITION_NOT_MET-Verschlüsselungsfehler (CMEK)

Wenn Sie ein Dataset abfragen, schlägt das Diagramm fehl und gibt den folgenden Fehler zurück:

User Configuration Error: CONDITION_NOT_MET

Ursache: Wenn Data Studio einen Abfragejob ausführt, schreibt BigQuery die Abfrageergebnisse in eine temporäre Tabelle im Abrechnungsprojekt. Wenn die Organisationsrichtlinieneinschränkung constraints/gcp.restrictNonCmekServices für BigQuery im Abrechnungsprojekt erzwungen wird, benötigt BigQuery einen kundenverwalteten Verschlüsselungsschlüssel (CMEK) für alle neuen Tabellen, einschließlich temporärer Abfrageergebnistabellen. Da der Connector in Abfragejobanfragen keinen Cloud Key Management Service-Schlüssel übergibt, schlagen Abfragen mit User Configuration Error: CONDITION_NOT_MET fehl, es sei denn, es ist ein standardmäßiger Cloud KMS-Schlüssel für das Projekt konfiguriert.

Schritte zur Fehlerbehebung

Konfigurieren Sie einen Cloud KMS-Standardschlüssel für das Projekt in BigQuery, damit BigQuery temporäre Tabellen mit Abfrageergebnissen automatisch verschlüsselt:

  1. Weisen Sie dem BigQuery-Verschlüsselungsdienstkonto für das Abrechnungsprojekt die Rolle Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) für Ihren Cloud KMS-Schlüssel zu.
  2. Legen Sie einen standardmäßigen Cloud KMS-Schlüssel für das Projekt fest (region-LOCATION.default_kms_key_name) im Abrechnungsprojekt für den Standort des Datasets, das Sie abfragen. Beispiel: 
    ALTER PROJECT PROJECT_ID
SET OPTIONS (
  `region-LOCATION.default_kms_key_name` = 'projects/KMS_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY'
);

Alternativ können Sie sich an den Administrator Ihrer Organisation wenden, um das Abrechnungsprojekt von der Richtlinie constraints/gcp.restrictNonCmekServices auszunehmen.

Datentyp „TIME“ wird nicht unterstützt

Wenn Sie eine Verbindung zu einer BigQuery-Tabelle herstellen, die Spalten mit dem Datentyp TIME enthält (z. B. 23:59:59), konvertiert Data Studio das Feld in TEXT. Dadurch werden zeitbasierte Sortierungen oder Aggregationen verhindert.

Ursache: Data Studio unterstützt den BigQuery-Datentyp TIME (z. B. 23:59:59) nicht nativ. Der Connector wandelt TIME-Spalten bei der Aufnahme in TEXT-Strings um, was eine zeitbasierte Sortierung verhindert.

Schritte zur Fehlerbehebung

Konvertieren Sie `TIME`-Spalten mit einer der folgenden Problemumgehungen in DATETIME-Objekte:

Problemumgehung 1: Benutzerdefinierte SQL-Abfrage verwenden

Kombinieren Sie das Feld `TIME` direkt in Ihrer SQL-Abfrage mit einem Basisdatum (`1970-01-01`):

SELECT
  *,
  -- Combine a dummy date (1970-01-01) with your TIME field
  DATETIME(DATE "1970-01-01", your_time_field) AS time_as_datetime
FROM
  `your_project.your_dataset.your_table`
  • Ergebnis: Data Studio übernimmt „time_as_datetime“ als Feld vom Typ **Datum und Uhrzeit**.
  • Formatierung: Ändern Sie in den Eigenschaften des Berichtsdiagramms das **Anzeigeformat** des Felds in **Stunde**, **Minute** oder ein benutzerdefiniertes Zeitformat (`h:mm:ss`), damit nur der Zeitanteil angezeigt wird (weitere Informationen).

Problemumgehung 2: Berechnetes Feld in Data Studio erstellen

Wenn Sie die SQL-Abfrage nicht ändern, erstellen Sie ein berechnetes Feld in Ihrer Datenquelle:

PARSE_DATETIME("%H:%M:%S", CAST(your_time_field AS TEXT))
  • Ergebnis: Mit der Funktion PARSE_DATETIME wird der Textstring in ein Objekt vom Typ **Datum und Uhrzeit** geparst. Das Kalenderdatum wird standardmäßig auf den 1. Januar 1970 festgelegt (weitere Informationen).

VPC Service Controls-Fehler

Fehlerbehebung bei Fehlern vom Typ „Zugriff verweigert“ und Einschränkungen für Hintergrundprozesse, wenn Sie innerhalb von Dienstperimetern arbeiten.

Service Control Failure beim Aufrufen von Berichten ohne VPN

Wenn Sie einen Bericht außerhalb des VPN oder Unternehmensnetzwerks Ihrer Organisation aufrufen, schlagen einige oder alle Diagramme mit dem folgenden Fehler fehl:

Service Control Failure

Ursache: Der Connector übergibt die IP-Adresse des Betrachters an BigQuery, um die IP-basierten Zugriffsebenen von VPC Service Controls zu prüfen. Wenn Sie einen Bericht kopieren, verweisen alte oder „Ghost“-benutzerdefinierte SQL-Datenquellen in der Kopie möglicherweise auf ein Abrechnungsprojekt, das innerhalb eines Dienstperimeters geschützt ist, auch wenn sich Ihr primärer Datensatz außerhalb befindet.

Schritte zur Fehlerbehebung

Identifizieren und entfernen Sie alle versteckten, an den Perimeter gebundenen Abrechnungsprojekte in Ihrem Bericht oder weisen Sie sie neu zu:

  1. Erstellen Sie eine Kopie des betroffenen Berichts, um die Fehlerbehebung sicher durchzuführen.
  2. Rufen Sie im Berichtseditor der Kopie Ressource > Hinzugefügte Datenquellen verwalten auf.
  3. Prüfen Sie alle eingebetteten **BigQuery**- oder **benutzerdefinierten SQL**-Datenquellen, die mit dem Bericht verknüpft sind.
  4. Bearbeiten Sie jede benutzerdefinierte SQL-Verbindung, um das konfigurierte **Abrechnungsprojekt** zu überprüfen. Wenn eine Datenquelle auf ein Abrechnungsprojekt verweist, das durch einen VPC Service Controls-Perimeter geschützt ist, aktualisieren Sie sie so, dass ein ungeschütztes Abrechnungsprojekt verwendet wird, oder löschen Sie die Datenquelle, wenn sie nicht mehr verwendet wird.

Fehler bei der geplanten E‑Mail-Zustellung oder bei Diagrammbenachrichtigungen hinter VPC Service Controls

Wenn automatisierte Hintergrundfunktionen (z. B. geplante E‑Mail-Zustellung oder Diagrammbenachrichtigungen) für ein Diagramm ausgeführt werden, das mit einem durch VPC Service Controls geschützten BigQuery-Dataset verbunden ist, wird die geplante E‑Mail ohne Berichtsinhalte oder Anhänge zugestellt oder die Benachrichtigung wird nicht ausgelöst (VPC Service Controls unexpected field in error map).

Ursache: Da automatisierte Hintergrundfunktionen (z. B. geplante E‑Mail-Zustellung oder Diagrammbenachrichtigungen) als Hintergrundaufgaben ohne IP-Adresse des Endnutzers ausgeführt werden, werden sie von VPC Service Controls (VPC-SC) blockiert, wenn IP-basierte Zugriffsebenen (VPC Service Controls unexpected field in error map) ausgewertet werden.

Schritte zur Fehlerbehebung

Wenn Sie automatisierte Hintergrundfunktionen hinter einem VPC Service Controls-Perimeter verwenden möchten, konfigurieren Sie Ihre Datenquelle so, dass Dienstkonto-Anmeldedaten verwendet werden, oder erstellen Sie eine identitätsbasierte Zugriffsebene: