Résoudre les problèmes liés aux erreurs et aux limites du connecteur BigQuery

Lorsque vous connectez Data Studio à BigQuery, vous pouvez rencontrer des délais d'expiration, des limites de syntaxe SQL, des limites de quota ou des erreurs VPC Service Controls. Ce guide décrit les problèmes courants liés au connecteur BigQuery. Développez Procédure de résolution pour examiner et résoudre votre problème.

Erreurs de syntaxe de requête et SQL

Les requêtes SQL personnalisées dans Data Studio sont soumises à des limites spécifiques. Si votre requête dépasse ces limites, des erreurs peuvent se produire.

Erreur de jointure Field is ambiguous

Si votre requête personnalisée contient des noms de colonnes en double, les graphiques affichent l'erreur suivante :

User Configuration Error: Field is ambiguous

Texte du message d'erreur : Erreur de configuration de l'utilisateur

Cause : Les tables jointes (JOIN) ne peuvent pas partager des noms de colonnes en double. Par exemple, si vous joignez deux tables avec des schémas identiques sur un champ Criteria_ID, la table virtuelle obtenue comportera des colonnes en double (Criteria_ID, Parent_ID, Name), ce qui déclenchera une erreur d'ambiguïté.

Procédure de résolution

Assurez-vous que tous les noms de colonnes sont uniques en utilisant le mot clé AS ou la clause EXCEPT :

Option 1 : Renommer explicitement les champs en double à l'aide d'alias

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 : Exclure et renommer des champs spécifiques à l'aide de EXCEPT

Si vous ne devez renommer qu'un petit nombre de champs tout en conservant les autres, utilisez EXCEPT :

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

Erreur de syntaxe de requête SQL personnalisée (plusieurs instructions)

Votre requête SQL personnalisée échoue si elle contient des variables ou plusieurs instructions (DECLARE, SET).

Cause : Data Studio exécute votre code SQL dans une requête SELECT externe (SELECT * FROM (<your_custom_sql>)). Par conséquent, votre requête doit être une instruction SELECT unique.

Par exemple, la requête suivante échoue, car elle déclare une variable avant de sélectionner :

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`;

Procédure de résolution

Combinez les calculs dans une seule instruction SELECT à l'aide d'expressions de table courantes (CTE ou clauses WITH) :

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;

Performances et délais avant expiration des requêtes

Lorsque l'exécution des requêtes prend plus de trois à cinq minutes, Data Studio expire avant de recevoir les résultats et renvoie l'erreur HTTP 504 Gateway timeout.

Erreurs de requête HTTP 504 Gateway timeout ou de longue durée

Les requêtes personnalisées ou les agrégations de graphiques complexes dans Data Studio peuvent expirer au bout de trois à cinq minutes, ce qui renvoie une erreur HTTP 504 Gateway timeout.

Procédure de résolution

Si vos requêtes expirent systématiquement, utilisez les optimisations suivantes :

  • Activer l'API BigQuery Storage Read : activez l'API BigQuery Storage Read pour augmenter le débit de données.
  • Simplifiez votre requête : supprimez les commandes "JOIN" inutiles, regroupez les données par périodes plus larges et ne sélectionnez que les colonnes requises.
  • Utilisez BigQuery BI Engine : réservez de la capacité avec BigQuery BI Engine pour des performances inférieures à la seconde.
  • Utilisez des vues de base de données : enregistrez votre requête SQL personnalisée en tant que vue BigQuery ou vue matérialisée, puis connectez Data Studio directement à cette vue.
  • Pré-agréger dans une table de rapport : utilisez des requêtes programmées dans BigQuery pour écrire des enregistrements récapitulatifs dans une table distincte, puis interrogez la table récapitulative.

Quotas et limites des tables

Lorsque votre ensemble de données contient des milliers de tables ou renvoie des millions d'enregistrements, des erreurs de limite peuvent se produire :

Blocage de la réactivité de l'interface utilisateur pour les ensembles de données contenant plus de 5 000 tables

Lorsque vous essayez de vous connecter à un ensemble de données BigQuery à l'aide de la liste de sélection de tables dans Data Studio, l'interface utilisateur se fige ou ne répond plus.

Cause : Le connecteur accepte jusqu'à 5 000 tables par ensemble de données. Si un ensemble de données dépasse 5 000 tables ou vues, la liste de sélection des tables expire et se fige.

Procédure de résolution

Utilisez l'une de ces alternatives pour vous connecter sans charger la liste des tables :

  • Se connecter à l'aide d'une requête personnalisée : sélectionnez REQUÊTE PERSONNALISÉE et écrivez une instruction "SELECT" moins complexe : 
    SELECT * FROM `your_project.your_dataset.your_table`
  • Se connecter directement depuis BigQuery : dans la console BigQuery, recherchez votre table, cliquez sur Exporter ou Explorer les données, puis sélectionnez Ouvrir avec Looker Studio.
  • Divisez ou réorganisez votre ensemble de données : déplacez les tables de reporting vers des ensembles de données de reporting dédiés plus petits contenant moins de 5 000 tables.

Limite maximale de 2 millions de lignes renvoyées

Lorsque vous visualisez des ensembles de données volumineux, votre graphique peut afficher un avertissement de troncature des données ou omettre les lignes au-delà de deux millions d'enregistrements.

Cause : Le connecteur renvoie un maximum de 2 millions de lignes par requête de graphique. Si une requête dépasse deux millions d'enregistrements, les graphiques tronquent les données et affichent un avertissement.

Procédure de résolution

Pour éviter la troncation des données :

  • Appliquez des filtres de date au niveau du rapport pour limiter le volume de requêtes.
  • Interroger des tables partitionnées par date (`DATE`, `DATETIME`, `TIMESTAMP`) qui nécessitent des filtres de partition (en savoir plus).
  • Regroupez les dimensions à cardinalité élevée dans BigQuery avant de les visualiser dans Data Studio.

Variance de MEDIAN et PERCENTILE

Lorsque vous calculez des médianes (MEDIAN) ou des centiles (PERCENTILE) exacts dans des graphiques connectés à BigQuery, le résultat peut différer légèrement de calculs identiques effectués sur d'autres bases de données SQL ou exportations CSV.

Cause : Dans les requêtes BigQuery, MEDIAN et PERCENTILE utilisent la fonction d'agrégation approximative APPROX_QUANTILES. Cela permet de traiter rapidement des ensembles de données à l'échelle du pétaoctet, mais les résultats approximatifs peuvent différer légèrement des calculs exacts effectués sur les exportations CSV ou d'autres bases de données SQL.

Erreurs de type de données et de chiffrement

Découvrez comment gérer les types de colonnes non compatibles et les règles de chiffrement des clés appliquées par l'organisation.

Erreur de chiffrement CONDITION_NOT_MET (CMEK)

Lorsque vous interrogez un ensemble de données, le graphique échoue et renvoie l'erreur suivante :

User Configuration Error: CONDITION_NOT_MET

Cause : Lorsque Data Studio exécute un job de requête, BigQuery écrit les résultats de la requête dans une table temporaire du projet de facturation. Si la contrainte de règle d'administration constraints/gcp.restrictNonCmekServices est appliquée pour BigQuery sur le projet de facturation, BigQuery nécessite une clé de chiffrement gérée par le client (CMEK) pour toutes les nouvelles tables, y compris les tables de résultats de requête temporaires. Comme le connecteur ne transmet pas de clé Cloud Key Management Service dans les requêtes de job de requête, les requêtes échouent avec l'erreur User Configuration Error: CONDITION_NOT_MET, sauf si une clé Cloud KMS par défaut est configurée pour le projet.

Procédure de résolution

Configurez une clé Cloud KMS par défaut pour le projet dans BigQuery afin que BigQuery chiffre automatiquement les tables de résultats de requêtes temporaires :

  1. Attribuez le rôle Chiffreur/Déchiffreur de CryptoKeys Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) sur votre clé Cloud KMS au compte de service de chiffrement BigQuery pour le projet de facturation.
  2. Définissez une clé Cloud KMS par défaut pour le projet (region-LOCATION.default_kms_key_name) dans le projet de facturation pour l'emplacement de l'ensemble de données que vous interrogez. Exemple : 
    ALTER PROJECT PROJECT_ID
SET OPTIONS (
  `region-LOCATION.default_kms_key_name` = 'projects/KMS_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY'
);

Vous pouvez également contacter l'administrateur de votre organisation pour exempter le projet de facturation de la règle constraints/gcp.restrictNonCmekServices.

Type de données TIME non compatible

Lorsque vous vous connectez à une table BigQuery contenant des colonnes du type de données TIME (par exemple, 23:59:59), Looker Studio convertit le champ en TEXT, ce qui empêche le tri ou les agrégations basés sur le temps.

Cause : Data Studio n'est pas compatible de manière native avec le type de données TIME de BigQuery (par exemple, 23:59:59). Le connecteur convertit les colonnes TIME en chaînes TEXT lors de l'ingestion, ce qui empêche le tri basé sur le temps.

Procédure de résolution

Convertissez les colonnes "TIME" en objets DATETIME à l'aide de l'une des solutions suivantes :

Solution 1 : Utiliser une requête SQL personnalisée

Combinez le champ "TIME" avec une date de base ("1970-01-01") directement dans votre code SQL :

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`
  • Résultat : Data Studio ingère "time_as_datetime" en tant que champ **Date et heure**.
  • Mise en forme : dans les propriétés du graphique de votre rapport, remplacez le **Format d'affichage** du champ par **Heure**, **Minute** ou un format d'heure personnalisé (`h:mm:ss`) afin de n'afficher que la partie heure (en savoir plus).

Solution 2 : Créer un champ calculé dans Data Studio

Si vous ne modifiez pas la requête SQL, créez un champ calculé dans votre source de données :

PARSE_DATETIME("%H:%M:%S", CAST(your_time_field AS TEXT))
  • Résultat : la fonction `PARSE_DATETIME` analyse la chaîne de texte et la convertit en un objet **Date et heure**, en définissant par défaut la date du calendrier sur le 1er janvier 1970 (en savoir plus).

Erreurs liées à VPC Service Controls

Résolvez les erreurs d'accès refusé et les restrictions de processus en arrière-plan lorsque vous travaillez dans des périmètres de service.

Service Control Failure lors de l'affichage des rapports sans VPN

Lorsque vous consultez un rapport en dehors du VPN ou du réseau d'entreprise de votre organisation, certains graphiques ou tous les graphiques échouent avec l'erreur suivante :

Service Control Failure

Cause : le connecteur transmet l'adresse IP du lecteur de rapports à BigQuery pour vérifier les niveaux d'accès basés sur l'adresse IP de VPC Service Controls. Lorsque vous copiez un rapport, les sources de données SQL personnalisées anciennes ou "fantômes" de la copie peuvent faire référence à un projet de facturation protégé dans un périmètre de service, même si votre ensemble de données principal se trouve en dehors.

Procédure de résolution

Identifiez et supprimez ou réattribuez les projets de facturation masqués liés au périmètre dans votre rapport :

  1. Créez une copie du rapport concerné pour résoudre le problème en toute sécurité.
  2. Dans l'éditeur de rapports de la copie, accédez à Ressource > Gérer les nouvelles sources de données.
  3. Examinez chaque source de données **BigQuery** ou **SQL personnalisé** intégrée au rapport.
  4. Modifiez chaque connexion SQL personnalisée pour vérifier le **projet de facturation** configuré. Si une source de données pointe vers un projet de facturation protégé par un périmètre VPC Service Controls, modifiez-la pour utiliser un projet de facturation non protégé ou supprimez-la si elle n'est plus utilisée.

Échecs de l'envoi d'e-mails programmés ou d'alertes de graphique protégés par VPC Service Controls

Lorsque des fonctionnalités automatisées en arrière-plan (comme l'envoi d'e-mails programmés ou les alertes de graphique) s'exécutent sur un graphique connecté à un ensemble de données BigQuery protégé par VPC Service Controls, l'e-mail programmé est envoyé sans contenu de rapport ni pièce jointe, ou l'alerte ne se déclenche pas (VPC Service Controls unexpected field in error map).

Cause : Étant donné que les fonctionnalités d'arrière-plan automatisées (comme l'envoi d'e-mails programmés ou les alertes de graphique) s'exécutent en tant que tâches d'arrière-plan sans adresse IP d'utilisateur final, VPC Service Controls (VPC-SC) les bloque lors de l'évaluation des niveaux d'accès basés sur l'adresse IP (VPC Service Controls unexpected field in error map).

Procédure de résolution

Pour utiliser les fonctionnalités d'arrière-plan automatisées derrière un périmètre VPC Service Controls, configurez votre source de données pour qu'elle utilise des identifiants de compte de service ou créez un niveau d'accès basé sur l'identité :