Résoudre les erreurs de quota BigQuery

BigQuery comprend différents quotas qui limitent le taux et le volume des requêtes entrantes. Ces quotas permettent à la fois de protéger les systèmes backend et d'éviter toute facturation inattendue si vous envoyez des tâches volumineuses. Ce document explique comment diagnostiquer et limiter des erreurs spécifiques résultant de quotas.

Si votre message d'erreur n'est pas listé dans ce document, consultez la section Messages d'erreur, qui contient des informations plus génériques sur les erreurs.

Aperçu

Si une opération BigQuery échoue en raison d'une limite de quota, l'API renvoie le code d'état HTTP 403 Forbidden. Le corps de la réponse contient plus d'informations sur la limite qui a été atteinte. Le corps de la réponse ressemble à ce qui suit :

{
  "code" : 403,
  "errors" : [ {
    "domain" : "global",
    "message" : "Quota exceeded: ...",
    "reason" : "quotaExceeded"
  } ],
  "message" : "Quota exceeded: ..."
}

Le champ message de la charge utile décrit la limite qui a été dépassée. Par exemple, le champ message peut indiquer Exceeded rate limits: too many table update operations for this table.

En général, les limites de quota appartiennent à deux catégories, indiquées par le champ reason dans la charge utile de la réponse.

  • rateLimitExceeded : cette valeur indique une limite à court terme. Pour résoudre ces problèmes de limite, réessayez l'opération après quelques secondes. Utilisez un intervalle exponentiel entre les tentatives. Autrement dit, augmentez le délai entre chaque tentative, de manière exponentielle.

  • quotaExceeded : cette valeur indique une limite à plus long terme. Si vous atteignez une limite de quota à plus long terme, vous devez attendre au moins 10 minutes avant de réessayer l'opération. Si vous atteignez régulièrement l'une de ces limites de quota à plus long terme, vous devez analyser votre charge de travail pour identifier et limiter le problème. Vous pouvez par exemple optimiser votre charge de travail ou demander une augmentation du quota.

Pour les erreurs quotaExceeded, examinez le message d'erreur pour comprendre quelle limite de quota a été dépassée. Analysez ensuite votre charge de travail pour voir si vous pouvez éviter de l'atteindre. Par exemple, l'optimisation des performances des requêtes peut limiter les erreurs de quota pour les requêtes simultanées.

Dans certains cas, le quota peut être augmenté en contactant l'assistance BigQuery ou en contactant l'équipe commerciale Google Cloud. Toutefois, nous vous recommandons d'essayer d'abord les suggestions de ce document.

Diagnostic

Pour diagnostiquer les problèmes, procédez comme suit :

  • Utilisez les vues INFORMATION_SCHEMA pour analyser le problème sous-jacent. Ces vues contiennent des métadonnées sur vos ressources BigQuery, y compris les tâches, les réservations et les insertions en flux continu.

    Par exemple, la requête suivante utilise la vue INFORMATION_SCHEMA.JOBS pour répertorier toutes les erreurs liées aux quotas au cours des dernières 24 heures :

    SELECT
     job_id,
     creation_time,
     error_result
    FROM `region-us`.INFORMATION_SCHEMA.JOBS
    WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) AND
          error_result.reason IN ('rateLimitExceeded', 'quotaExceeded')
    
  • Affichez les erreurs dans Cloud Audit Logs

    Par exemple, en utilisant l'Explorateur de journaux, la requête suivante renvoie des erreurs avec Quota exceeded ou limit dans la chaîne du message :

    resource.type = ("bigquery_project" OR "bigquery_dataset")
    protoPayload.status.code ="7"
    protoPayload.status.message: ("Quota exceeded" OR "limit")
    

    Dans cet exemple, le code d'état 7 indique PERMISSION_DENIED, ce qui correspond au code d'état HTTP 403.

    Pour obtenir d'autres exemples de requêtes Cloud Audit Logs, consultez la page Requêtes BigQuery.

Erreurs de quota de requêtes simultanées

Si un projet exécute simultanément plus de requêtes interactives que la limite attribuée pour ce projet, vous pouvez rencontrer cette erreur.

Pour en savoir plus sur cette limite, consultez la section Nombre maximal de requêtes interactives simultanées.

Message d'erreur

Exceeded rate limits: too many concurrent queries for this project_and_region

Diagnostic

Si vous n'avez pas identifié les tâches de requête qui renvoient cette erreur, procédez comme suit :

  • Recherchez les autres requêtes qui s'exécutent simultanément avec les requêtes ayant échoué.

    Par exemple, si votre requête ayant échoué a été envoyée le 08-06-2021 à 12:00:00 UTC dans la région us, exécutez la requête suivante dans la table de la vue INFORMATION_SCHEMA.JOBS du projet dans lequel la requête ayant échoué a été envoyée :

    DECLARE failed_query_submission_time DEFAULT CAST('2021-06-08 12:00:00' AS TIMESTAMP);
    
    SELECT
     job_id,
     state,
     user_email,
     query
    FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
    WHERE creation_time >= date_sub(failed_query_submission_time, INTERVAL 1 DAY)
    AND job_type = 'QUERY'
    AND priority = 'INTERACTIVE'
    AND start_time <= failed_query_submission_time
    AND (end_time >= failed_query_submission_time OR state != 'DONE')
    
  • Si votre requête envoyée à INFORMATION_SCHEMA.JOBS_BY_PROJECT échoue avec la même erreur, exécutez la commande bq ls dans le terminal Cloud Shell pour lister les requêtes en cours d'exécution :

    bq ls -j --format=prettyjson -n 200 | jq '.[] | select(.status.state=="RUNNING")| {configuration: .query, id: .id, jobReference: .jobReference, user_email: .user_email}'

Solution

Pour résoudre cette erreur de quota, procédez comme suit :

  • Suspendez la tâche. Si votre diagnostic précédent identifie un processus ou un workflow responsable d'une augmentation des requêtes, mettez ce processus ou ce workflow en pause.

  • Utilisez des tâches avec priorité par lot. Les requêtes par lot ne sont pas comptabilisées dans votre limite de débit simultané. L'exécution de requêtes par lot peut vous permettre de démarrer plusieurs requêtes à la fois. Elles utilisent les mêmes ressources que les requêtes interactives (à la demande). BigQuery met en file d'attente chaque requête par lot en votre nom et lance la requête lorsque des ressources inactives sont disponibles dans le pool de ressources partagées de BigQuery.

    Vous pouvez également créer un projet distinct pour exécuter des requêtes.

  • Distribuez les requêtes. Organisez et répartissez la charge sur différents projets en fonction de la nature de vos requêtes et des besoins de votre entreprise.

  • Distribuez les temps d'exécution. Répartissez la charge sur une période plus longue. Si votre solution de création de rapports doit exécuter de nombreuses requêtes, essayez d'introduire un caractère aléatoire au démarrage des requêtes. Par exemple, ne démarrez pas tous les rapports en même temps.

  • Utilisez BigQuery BI Engine. Si vous avez rencontré cette erreur lors de l'utilisation d'un outil d'informatique décisionnelle pour créer des tableaux de bord qui interrogent des données dans BigQuery, nous vous recommandons d'utiliser BigQuery BI Engine. L'utilisation de BigQuery BI Engine est optimale pour ce cas d'utilisation.

  • Optimisez les requêtes et le modèle de données. Une requête peut souvent être réécrite afin d'être exécutée plus efficacement. Par exemple, si votre requête contient une –clause WITH– d'Expression de table commune (CTE) référencée à plusieurs endroits de la requête, ce calcul est fait plusieurs fois. Il est préférable de conserver les calculs effectués par le CTE dans une table temporaire, puis de la référencer dans la requête.

    Les jointures multiples peuvent également être la source d'un manque d'efficacité. Dans ce cas, vous pouvez envisager d'utiliser des colonnes imbriquées et répétées. Bien souvent, cette méthode améliore la localité des données, élimine le besoin de certaines jointures et réduit la consommation des ressources ainsi que le temps d'exécution des requêtes.

    L'optimisation des requêtes les rend moins coûteuses. Ainsi, lorsque vous utilisez la tarification forfaitaire, vous pouvez exécuter davantage de requêtes avec vos emplacements. Pour en savoir plus, consultez la section Présentation de l'optimisation des performances des requêtes.

  • Optimisez le modèle de requête. BigQuery n'est pas une base de données relationnelle. Il n'est pas optimisé pour un nombre infini de petites requêtes. L'exécution d'un grand nombre de petites requêtes épuise rapidement vos quotas. Ces requêtes ne s'exécutent pas aussi efficacement qu'avec les produits de base de données plus petits. BigQuery est un grand entrepôt de données et il s'agit de son principal cas d'utilisation. Il fonctionne mieux avec des requêtes analytiques sur de grandes quantités de données.

  • Conservez les données (tables enregistrées). Prétraitez les données dans BigQuery et stockez-les dans des tables supplémentaires. Par exemple, si vous exécutez de nombreuses requêtes similaires qui utilisent beaucoup de ressources de calcul avec différentes conditions WHERE, leurs résultats ne sont pas mis en cache. Ces requêtes consomment également des ressources à chaque exécution. Vous pouvez améliorer les performances de ces requêtes et réduire leur temps de traitement en précalculant les données et en les stockant dans une table. Ces données précalculées dans la table peuvent être interrogées par des requêtes SELECT. Cette opération peut souvent être effectuée lors de l'ingestion dans le processus ETL, ou en utilisant des requêtes programmées ou des vues matérialisées.

  • Augmentez les limites de quota. Vous pouvez également augmenter les limites de quota pour résoudre cette erreur. Pour augmenter la limite, adressez-vous à l'assistance ou contactez le service commercial. Le traitement d'une augmentation de quota peut prendre plusieurs jours. Afin de fournir plus d'informations pour votre requête, nous vous recommandons d'inclure dans votre requête la priorité de la tâche, l'utilisateur qui exécute la requête et la méthode concernée.

    Les limites sont appliquées au niveau du projet. Toutefois, l'augmentation du nombre de tâches simultanées par projet réduit le nombre d'emplacements disponibles pour chaque requête exécutée simultanément, ce qui peut réduire les performances de requêtes individuelles. Pour améliorer les performances, nous vous recommandons d'augmenter le nombre d'emplacements si la limite de requêtes simultanées est augmentée.

    Pour en savoir plus sur l'augmentation de cette limite, consultez la section Quotas et limites. Pour en savoir plus sur les emplacements, consultez la section Réservation d'emplacement.

Erreurs de quota du nombre de modifications de partitions pour les tables partitionnées en colonnes

BigQuery renvoie cette erreur lorsque votre table partitionnée en colonnes atteint le quota du nombre de modifications de partition autorisées par jour. Les modifications de partition incluent le total de toutes les tâches de chargement, tâches de copie et tâches de requête qui s'ajoutent ou écrasent une partition de destination, ou qui utilisent une instruction LMD DELETE, INSERT, MERGE, TRUNCATE TABLE ou UPDATE pour écrire des données dans une table.

Pour afficher la valeur limite du Nombre de modifications de partition par table partitionnée en colonnes par jour, consultez la section Tables partitionnées.

Message d'erreur

Quota exceeded: Your table exceeded quota for
Number of partition modifications to a column partitioned table
Solution

Ce quota ne peut pas être augmenté. Pour résoudre cette erreur de quota, procédez comme suit :

  • Modifiez le partitionnement de la table afin d'obtenir plus de données dans chaque partition et de réduire le nombre total de partitions. Par exemple, passez du partitionnement par jour au partitionnement par mois, ou modifiez le mode de partitionnement de la table.
  • Utilisez le clustering au lieu du partitionnement.
  • Si vous chargez fréquemment des données à partir de plusieurs petits fichiers stockés dans Cloud Storage qui utilisent une tâche par fichier, combinez plusieurs tâches de chargement en une seule tâche. Le chargement peut être effectué à partir de plusieurs URI Cloud Storage avec une liste d'éléments séparés par une virgule (par exemple, gs://my_path/file_1,gs://my_path/file_2) ou en utilisant des caractères génériques (par exemple, gs://my_path/*).

    Pour en savoir plus, consultez la section Charger des données par lot.

  • Si vous utilisez des requêtes à une seule ligne (c'est-à-dire des instructions INSERT) pour écrire des données dans une table, envisagez de regrouper plusieurs requêtes en une seule afin de réduire le nombre de tâches. BigQuery n'est pas très performant lorsqu'il est utilisé en tant que base de données relationnelle. Les instructions INSERT à une seule ligne exécutées à grande vitesse ne sont donc pas une bonne pratique recommandée.
  • Si vous avez l'intention d'insérer des données à un taux élevé, envisagez d'utiliser l'API BigQuery Storage Write. Cette solution est recommandée pour une ingestion de données hautes performances. L'API BigQuery Storage Write dispose de fonctionnalités robustes, y compris la sémantique de diffusion de type "exactement une fois". Consultez la section API Storage Write afin d'en savoir plus sur les limites et les quotas, et la section Tarifs d'ingestion de données BigQuery pour connaître les coûts d'utilisation de cette API.

Erreurs de quota d'insertion en flux continu

Cette section donne des conseils pour résoudre les erreurs de quota liées à l'insertion de données en flux continu dans BigQuery.

Dans certaines régions, les insertions en flux continu ont un quota plus élevé si vous ne remplissez pas le champ insertId pour chaque ligne. Pour en savoir plus sur les quotas d'insertion en flux continu, consultez la section Insertions en flux continu. Les erreurs liées aux quotas d'insertion en flux continu dans BigQuery dépendent de la présence ou de l'absence de insertId.

Message d'erreur

Si le champ insertId est vide, l'erreur de quota suivante est possible :

Limite de quota Message d'erreur
Octets par seconde et par projet Votre entité avec gaia_id : GAIA_ID, projet : PROJECT_ID dans la région : REGION a dépassé le quota d'insertion d'octets par seconde.

Si le champ insertId est renseigné, les erreurs de quota suivantes sont possibles :

Limite de quota Message d'erreur
Lignes par seconde et par projet Votre projet PROJECT_ID dans REGION a dépassé le quota d'insertion en flux continu de lignes par seconde.
Lignes par seconde et par table Votre table TABLE_ID a dépassé le quota d'insertion en flux continu de lignes par seconde.
Octets par seconde et par table Votre table TABLE_ID a dépassé le quota d'insertion en flux continu d'octets par seconde.

Le champ insertId permet de dédupliquer les lignes insérées. Si plusieurs insertions avec le même insertId arrivent dans un intervalle de quelques minutes, BigQuery écrit une seule version de l'enregistrement. Cependant, cette déduplication automatique n'est pas garantie. Pour un débit en flux continu maximal, nous vous recommandons de ne pas inclure insertId et d'utiliser plutôt la déduplication manuelle. Pour en savoir plus, consultez la section Assurer la cohérence des données.

Diagnostic

Utilisez les vues STREAMING_TIMELINE_BY_* pour analyser le trafic en flux continu. Ces vues cumulent des statistiques de flux continu sur des intervalles d'une minute, regroupés par code d'erreur. Les erreurs de quota apparaissent dans les résultats, avec la valeur de error_code égale à RATE_LIMIT_EXCEEDED ou QUOTA_EXCEEDED.

En fonction de la limite de quota spécifique qui a été atteinte, consultez total_rows ou total_input_bytes. Si l'erreur est un quota au niveau de la table, filtrez par table_id.

Par exemple, la requête suivante affiche le nombre total d'octets ingérés par minute et le nombre total d'erreurs de quota :

SELECT
 start_timestamp,
 error_code,
 SUM(total_input_bytes) as sum_input_bytes,
 SUM(IF(error_code IN ('QUOTA_EXCEEDED', 'RATE_LIMIT_EXCEEDED'),
     total_requests, 0)) AS quota_error
FROM
 `region-us`.INFORMATION_SCHEMA.STREAMING_TIMELINE_BY_PROJECT
WHERE
  start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY)
GROUP BY
 start_timestamp,
 error_code
ORDER BY 1 DESC

Solution

Pour résoudre cette erreur de quota, procédez comme suit :

  • Si vous utilisez le champ insertId pour la déduplication et que votre projet se trouve dans une région compatible avec le quota d'insertion en flux continu le plus élevé, nous vous recommandons de supprimer le champ insertId. Cette solution peut nécessiter des étapes supplémentaires pour dédupliquer manuellement les données. Pour en savoir plus, consultez la section Supprimer manuellement les doublons.

  • Si vous n'utilisez pas insertId ou si vous ne pouvez pas le supprimer, surveillez le trafic en flux continu sur une période de 24 heures et analysez les erreurs de quota :

    • Si vous constatez principalement des erreurs RATE_LIMIT_EXCEEDED plutôt que des erreurs QUOTA_EXCEEDED et que votre trafic global est inférieur à 80 % du quota, les erreurs indiquent probablement des pics temporaires. Vous pouvez retenter l'opération en utilisant un intervalle exponentiel entre les tentatives pour résoudre ces erreurs.

    • Si vous utilisez une tâche Dataflow pour insérer des données, pensez à utiliser des tâches de chargement plutôt que des insertions en flux continu. Pour en savoir plus, consultez la section Définir la méthode d'insertion. Si vous utilisez Dataflow avec un connecteur d'E/S personnalisé, envisagez plutôt d'utiliser un connecteur d'E/S intégré. Pour en savoir plus, consultez la section Modèles d'E/S personnalisés.

    • Si vous voyez des erreurs QUOTA_EXCEEDED ou si le trafic global dépasse systématiquement 80 % du quota, envoyez une requête d'augmentation du quota. Pour plus d'informations, consultez la page Demander une limite de quota supérieure.

    • Vous pouvez également envisager de remplacer les insertions en flux continu par la nouvelle API Storage Write, qui bénéficie d'un débit plus élevé, un prix plus faible et de nombreuses fonctionnalités utiles.

Erreurs de quota lors du chargement des fichiers CSV

Si vous chargez un fichier CSV volumineux à l'aide de la commande bq load avec l'option --allow_quoted_newlines, cette erreur peut se produire.

Message d'erreur

Input CSV files are not splittable and at least one of the files is larger than
the maximum allowed size. Size is: ...

Solution

Pour résoudre cette erreur de quota, procédez comme suit :

  • Définissez l'indicateur --allow_quoted_newlines sur false.
  • Scindez le fichier CSV en fragments plus petits de moins de 4 Go chacun.

Pour en savoir plus sur les limites qui s'appliquent lorsque vous chargez des données dans BigQuery, consultez la section Tâches de chargement.

Erreurs de quota d'importations de tables ou d'ajouts de requêtes

BigQuery renvoie ce message d'erreur lorsque votre table atteint la limite d'opérations de table par jour pour les tables standards. Les opérations de table incluent le total cumulé de toutes les tâches de chargement, tâches de copie et tâches de requête qui s'ajoutent à une table de destination ou l'écrasent, ou qui utilisent une instruction LMD DELETE, INSERT, MERGE, TRUNCATE TABLE ou UPDATE pour écrire des données dans une table.

Pour afficher la valeur limite du nombre d'Opérations de table par jour, consultez la section Tables standards.

Message d'erreur

Your table exceeded quota for imports or query appends per table

Diagnostic

Si vous n'avez pas identifié la source à l'origine de la plupart des opérations de table, procédez comme suit :

  1. Notez le projet, l'ensemble de données et la table sur lesquels la requête, la charge ou la tâche de copie ayant échoué est en train d'écrire.

  2. Utilisez les tables INFORMATION_SCHEMA.JOBS_BY_* pour en savoir plus sur les tâches qui modifient la table.

    L'exemple suivant recherche le nombre de tâches par heure regroupées par type de tâche sur une période de 24 heures à l'aide de JOBS_BY_PROJECT. Si vous prévoyez que plusieurs projets écrivent dans la table, remplacez JOBS_BY_PROJECT par JOBS_BY_ORGANIZATION.

    SELECT
      TIMESTAMP_TRUNC(creation_time, HOUR),
      job_type,
      count(1)
    FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
    #Adjust time
    WHERE creation_time BETWEEN "2021-06-20 00:00:00" AND "2021-06-21 00:00:00"
    AND destination_table.project_id = "my-project-id"
    AND destination_table.dataset_id = "my_dataset"
    AND destination_table.table_id = "my_table"
    GROUP BY 1, 2
    ORDER BY 1 DESC
    

Solution

Ce quota ne peut pas être augmenté. Pour résoudre cette erreur de quota, procédez comme suit :

  • Si vous chargez fréquemment des données à partir de plusieurs petits fichiers stockés dans Cloud Storage qui utilisent une tâche par fichier, combinez plusieurs tâches de chargement en une seule tâche. Le chargement peut être effectué à partir de plusieurs URI Cloud Storage avec une liste d'éléments séparés par une virgule (par exemple, gs://my_path/file_1,gs://my_path/file_2) ou en utilisant des caractères génériques (par exemple, gs://my_path/*).

    Pour en savoir plus, consultez la section Charger des données par lot.

  • Si vous utilisez des requêtes à une seule ligne (c'est-à-dire des instructions INSERT) pour écrire des données dans une table, envisagez de regrouper plusieurs requêtes en une seule afin de réduire le nombre de tâches. BigQuery n'est pas très performant lorsqu'il est utilisé en tant que base de données relationnelle. Les instructions INSERT à une seule ligne exécutées à grande vitesse ne sont donc pas une bonne pratique recommandée.
  • Si vous avez l'intention d'insérer des données à un taux élevé, envisagez d'utiliser l'API BigQuery Storage Write. Cette solution est recommandée pour une ingestion de données hautes performances. L'API BigQuery Storage Write dispose de fonctionnalités robustes, y compris la sémantique de diffusion de type "exactement une fois". Consultez la section API Storage Write afin d'en savoir plus sur les limites et les quotas, et la section Tarifs d'ingestion de données BigQuery pour connaître les coûts d'utilisation de cette API.

Erreurs de limite du taux maximal d'opérations de mise à jour des métadonnées de table

BigQuery renvoie cette erreur lorsque votre table atteint la limite de taux maximal d'opérations de mise à jour des métadonnées de table par table pour les tables standards. Les opérations de table incluent le total cumulé de toutes les tâches de chargement, tâches de copie et tâches de requête qui s'ajoutent à une table de destination ou l'écrasent, ou qui utilisent une instruction LMD DELETE, INSERT, MERGE, TRUNCATE TABLE ou UPDATE pour écrire des données dans une table.

Pour afficher la valeur limite du Taux maximal d'opérations de mise à jour des métadonnées de table par table, consultez la section Tables standards.

Message d'erreur

Exceeded rate limits: too many table update operations for this table

Diagnostic

Les mises à jour de table de métadonnées peuvent provenir d'appels d'API qui modifient les métadonnées d'une table ou de tâches qui modifient le contenu d'une table. Si vous n'avez pas identifié la source à l'origine de la plupart des opérations de mise à jour des métadonnées d'une table, procédez comme suit :

Identifiez les appels d'API

  1. Accédez au menu de navigation Google Cloud , puis sélectionnez Logging > Explorateur de journaux :

    Accéder à l'explorateur de journaux

  2. Pour filtrer les journaux afin d'afficher les opérations de la table, exécutez la requête suivante :

    resource.type="bigquery_dataset"
    protoPayload.resourceName="projects/my-project-id/datasets/my_dataset/tables/my_table"
    (protoPayload.methodName="google.cloud.bigquery.v2.TableService.PatchTable" OR
    protoPayload.methodName="google.cloud.bigquery.v2.TableService.UpdateTable" OR
    protoPayload.methodName="google.cloud.bigquery.v2.TableService.InsertTable")
    

Identifiez les tâches

La requête suivante renvoie la liste des tâches qui modifient la table concernée dans le projet. Si vous prévoyez que plusieurs projets dans une organisation écrivent dans la table, remplacez JOBS_BY_PROJECT par JOBS_BY_ORGANIZATION.

SELECT
 job_id,
 user_email,
 query
#Adjust region
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
#Adjust time
WHERE creation_time BETWEEN "2021-06-21 10:00:00" AND "2021-06-21 20:00:00"
AND destination_table.project_id = "my-project-id"
AND destination_table.dataset_id = "my_dataset"
AND destination_table.table_id = "my_table"

Pour en savoir plus, consultez la présentation des journaux d'audit BigQuery.

Solution

Ce quota ne peut pas être augmenté. Pour résoudre cette erreur de quota, procédez comme suit :

  • Réduisez la fréquence de mise à jour des métadonnées de la table.
  • Ajoutez un délai entre les tâches ou les opérations de table pour vous assurer que le taux de mise à jour est inférieur à la limite.
  • Pour les insertions ou les modifications de données, envisagez d'utiliser des opérations LMD. Les opérations LMD ne sont pas affectées par la limite de taux maximal d'opérations de mise à jour des métadonnées de table par table.

    Les opérations LMD sont soumises à d'autres limites et quotas. Pour en savoir plus, consultez la section Utiliser le langage de manipulation de données (LMD).

  • Si vous chargez fréquemment des données à partir de plusieurs petits fichiers stockés dans Cloud Storage qui utilisent une tâche par fichier, combinez plusieurs tâches de chargement en une seule tâche. Le chargement peut être effectué à partir de plusieurs URI Cloud Storage avec une liste d'éléments séparés par une virgule (par exemple, gs://my_path/file_1,gs://my_path/file_2) ou en utilisant des caractères génériques (par exemple, gs://my_path/*).

    Pour en savoir plus, consultez la section Charger des données par lot.

  • Si vous utilisez des requêtes à une seule ligne (c'est-à-dire des instructions INSERT) pour écrire des données dans une table, envisagez de regrouper plusieurs requêtes en une seule afin de réduire le nombre de tâches. BigQuery n'est pas très performant lorsqu'il est utilisé en tant que base de données relationnelle. Les instructions INSERT à une seule ligne exécutées à grande vitesse ne sont donc pas une bonne pratique recommandée.
  • Si vous avez l'intention d'insérer des données à un taux élevé, envisagez d'utiliser l'API BigQuery Storage Write. Cette solution est recommandée pour une ingestion de données hautes performances. L'API BigQuery Storage Write dispose de fonctionnalités robustes, y compris la sémantique de diffusion de type "exactement une fois". Consultez la section API Storage Write afin d'en savoir plus sur les limites et les quotas, et la section Tarifs d'ingestion de données BigQuery pour connaître les coûts d'utilisation de cette API.

Erreurs de limite du nombre maximal de requêtes API

BigQuery renvoie cette erreur lorsque vous atteignez la limite de débit pour le nombre de requêtes API adressées à une API BigQuery par utilisateur et par méthode (par exemple, la méthode tables.get appelle à partir d'un compte de service, ou la méthode jobs.insert appelle à partir d'une adresse e-mail d'utilisateur différente). Pour en savoir plus, consultez la limite de débit du Nombre maximal de requêtes API par seconde, par utilisateur et par méthode dans Toutes les API BigQuery.

Message d'erreur

Too many API requests per user per method for this user_method

Diagnostic

Si vous n'avez pas identifié la méthode ayant atteint cette limite de débit, procédez comme suit :

Pour le compte de service

  1. Accédez au projet qui héberge le compte de service.

  2. Dans Google Cloud Console, accédez au tableau de bord des API.

    Pour savoir comment afficher des informations détaillées concernant l'utilisation d'une API, consultez la section Utiliser le tableau de bord des API.

  3. Dans le tableau de bord des API, sélectionnez API BigQuery.

  4. Pour afficher des informations d'utilisation plus détaillées, sélectionnez Métriques, puis procédez comme suit :

    1. Pour Sélectionner des graphiques, sélectionnez Trafic par méthode API.

    2. Filtrez le graphique en fonction des identifiants du compte de service. Vous pouvez constater la présence de pics pour une méthode dans la période où vous avez observé l'erreur.

Pour les appels d'API

Certains appels d'API consignent des erreurs dans les journaux d'audit BigQuery dans Cloud Logging. Pour identifier la méthode ayant atteint la limite, procédez comme suit :

  1. Dans la console, accédez au menu de navigation Google Cloud , puis sélectionnez Journalisation > Explorateur de journaux pour votre projet :

    Accéder à l'explorateur de journaux

  2. Filtrez les journaux en exécutant la requête suivante :

     resource.type="bigquery_resource"
     protoPayload.authenticationInfo.principalEmail="<user email or service account>"
     "Too many API requests per user per method for this user_method"
     In the log entry, you can find the method name under the property protoPayload.method_name.
     

    Pour en savoir plus, consultez la présentation des journaux d'audit BigQuery.

Solution

Pour résoudre cette erreur de quota, procédez comme suit :

  • Réduisez le nombre de requêtes API ou ajoutez un délai entre plusieurs requêtes API, de sorte que le nombre de requêtes reste inférieur à cette limite.

  • Si la limite n'est dépassée qu'occasionnellement, vous pouvez implémenter de nouvelles tentatives sur cette erreur spécifique avec un intervalle exponentiel entre les tentatives.

  • Si vous insérez fréquemment des données, envisagez d'utiliser des insertions en flux continu, car celles-ci ne sont pas affectées par le quota de l'API BigQuery. Cependant, l'API d'insertion en flux continu induit des coûts et dispose de son propre ensemble de limites et quotas.

    Pour en savoir plus sur le coût des insertions en flux continu, consultez la section Tarifs de BigQuery.

  • Lorsque vous chargez des données dans BigQuery à l'aide de Dataflow avec le connecteur d'E/S BigQuery, vous pouvez rencontrer cette erreur pour la méthode tables.get. Pour résoudre ce problème, procédez comme suit :

    • Définissez la disposition de création de la table de destination sur CREATE_NEVER. Pour en savoir plus, consultez la section Disposition de création.

    • Utilisez le SDK Apache Beam version 2.24.0 ou ultérieure. Dans les versions précédentes du SDK, la disposition CREATE_IF_NEEDED appelle la méthode tables.get pour vérifier si la table existe.

  • Vous pouvez demander une augmentation de quota en contactant l'assistance ou le service commercial. Pour obtenir davantage de quota, consultez la section Demander une augmentation de quota. Le traitement d'une demande d'augmentation de quota peut prendre plusieurs jours. Afin de fournir plus d'informations pour votre requête, nous vous recommandons d'inclure dans votre requête la priorité de la tâche, l'utilisateur qui exécute la requête et la méthode concernée.

Votre projet a dépassé le quota gratuit d'octets de requêtes analysés

BigQuery renvoie cette erreur lorsque vous exécutez une requête au niveau d'utilisation gratuite et que le compte atteint la limite mensuelle de volume de données pouvant être interrogé. Pour en savoir plus sur les Requêtes (analyse), consultez la page Niveau d'utilisation gratuite.

Message d'erreur

Your project exceeded quota for free query bytes scanned

Solution

Pour continuer à utiliser BigQuery, vous devez mettre à niveau le compte vers un compte de facturation Cloud payant.

Nombre maximal d'octets tabledata.list par seconde et par erreur de quota de projet

BigQuery renvoie cette erreur lorsque le numéro de projet mentionné dans le message d'erreur atteint la taille maximale des données pouvant être lues par seconde via l'appel d'API tabledata.list dans un projet. Pour en savoir plus sur la limite Octets de la liste de données de table par minute, consultez la section Requêtes tabledata.list.

Message d'erreur

Your project:[project number] exceeded quota for tabledata.list bytes per second per project

Solution

Pour résoudre cette erreur, procédez comme suit :

  • En règle générale, nous vous recommandons de respecter cette limite. Par exemple, en séparant les requêtes sur une période plus longue avec des délais. Si l'erreur ne se produit pas fréquemment, la mise en œuvre de nouvelles tentatives avec un intervalle exponentiel entre les tentatives peut résoudre ce problème.
  • Si le cas d'utilisation nécessite la lecture rapide et fréquente d'une grande quantité de données à partir d'une table, nous vous recommandons d'utiliser l'API BigQuery Storage Read plutôt que l'API tabledata.list.
  • Si les suggestions précédentes ne fonctionnent pas, vous pouvez demander une augmentation du quota à partir du tableau de bord des API de la console en procédant comme suit :

    1. Accédez au tableau de bord des API de la console.
    2. Dans le tableau de bord, utilisez les filtres pour trouver le quota : Tabledata list bytes per minute (default quota).
    3. Sélectionnez le quota, puis suivez les instructions de la section Demander une limite de quota supérieure.

    L'examen et le traitement de la demande peuvent prendre plusieurs jours.

Nombre maximal de tâches de copie par jour et par erreur de quota de projet

BigQuery renvoie cette erreur lorsque le nombre de tâches de copie exécutées dans un projet a dépassé la limite quotidienne. Pour en savoir plus sur la limite applicable aux tâches de copie par jour, consultez la page Tâches de copie.

Message d'erreur

Your project exceeded quota for copies per project

Diagnostic

Si vous souhaitez collecter plus de données sur l'origine des tâches de copie, vous pouvez essayer les solutions suivantes :

  • Si vos tâches de copie se trouvent dans une ou plusieurs régions, vous pouvez essayer d'interroger la table INFORMATION_SCHEMA.JOBS pour ces régions spécifiques. Exemple :
    SELECT
    creation_time, job_id, user_email, destination_table.project_id, destination_table.dataset_id, destination_table.table_id
    FROM `PROJECT_ID`.`REGION_NAME`.INFORMATION_SCHEMA.JOBS
    WHERE
    creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 2 DAY) AND CURRENT_TIMESTAMP()
    AND job_type = "COPY"
    order by creation_time DESC
    
    La partie REGION_NAME doit être remplacée par le nom de la région en incluant le préfixe region-. Par exemple, region-us et region-asia-south1 Vous pouvez également ajuster l'intervalle de temps en fonction de la période qui vous intéresse.
  • Pour afficher toutes les tâches de copie dans toutes les régions, vous pouvez utiliser le filtre suivant dans Cloud Logging :
    resource.type="bigquery_resource"
    protoPayload.methodName="jobservice.insert"
    protoPayload.serviceData.jobInsertRequest.resource.jobConfiguration.tableCopy:*
    

Solution

  • Si l'objectif des opérations de copie fréquentes est de créer un instantané de données, envisagez plutôt d'utiliser des instantanés de table. Les instantanés de table sont moins chers et plus rapides que la copie de tables complètes.
  • Vous pouvez demander une augmentation de quota en contactant l'assistance ou le service commercial. L'examen et le traitement de la demande peuvent prendre plusieurs jours. Nous vous recommandons d'indiquer la priorité, le cas d'utilisation et l'ID de projet dans la requête.