Optimiser les tâches de chargement

Les stratégies et les bonnes pratiques décrites dans ce document vous aident à optimiser le chargement par lot ou la diffusion de données dans BigQuery afin d'éviter d'atteindre la limite du nombre de tâches de chargement par table et par jour.

Étant donné que la limite des tâches de chargement est fixe et ne peut pas être augmentée, vous devez optimiser vos tâches de chargement en structurant vos tables à l'aide de méthodes telles que les partitions de table, ou en gérant vos chargements à l'aide de méthodes telles que le chargement par lot ou la diffusion.

Fonctionnement des quotas d'opérations de table

La limite BigQuery pour les modifications de table par table et par jour par projet est fixe, que les modifications ajoutent ou mettent à jour des données, ou tronquent la table. Cette limite inclut le total combiné de toutes les tâches de chargement, tâches de copie et tâches de requête qui ajoutent ou écrasent une table de destination.

Les tâches de chargement ont un taux de remplissage. Si vous dépassez la limite d'opérations de table ou son taux de remplissage, les tâches de chargement échouent avec une erreur quotaExceeded. La limite au niveau du projet pour les tâches de chargement par jour est remplie sur une période glissante de 24 heures. Lorsque les tâches de chargement sont terminées, votre quota disponible diminue. Le quota est ensuite progressivement rempli au cours des 24 heures suivantes. Les tâches de chargement ayant échoué sont toujours comptabilisées dans les quotas par table et par projet. Pour en savoir plus sur les limites des tâches de chargement, consultez la section Tâches de chargement.

Pour les tables partitionnées, une limite distincte s'applique aux modifications de partition, remplaçant la limite de table standard.

Pour respecter les limites quotidiennes d'opérations de table, répartissez les opérations sur une période de 24 heures. Par exemple, si vous effectuez 25 mises à jour, chacune avec 60 opérations, vous pouvez exécuter environ 60 opérations toutes les 58 minutes. Cette approche vous permet de respecter la limite quotidienne. Pour surveiller les mises à jour de table, consultez les vues BigQuery INFORMATION_SCHEMA.

Opérations de table exclues du quota

La mise à jour des informations de table (métadonnées) et l'utilisation d'instructions LMD ne sont pas comptabilisées dans votre limite quotidienne de modifications de table. Cette exclusion s'applique aux tables standards et partitionnées.

Votre projet peut exécuter un nombre illimité d'instructions LMD. Alors que les instructions LMD étaient auparavant comptabilisées dans les modifications de table quotidiennes et n'étaient pas limitées, même à la limite, ce n'est plus le cas.

Les insertions en flux continu modifient également les tables, mais elles sont régies par leurs propres quotas spécifiques.

Stratégies de chargement pour éviter la limite d'opérations de table

Pour respecter la limite quotidienne d'opérations de table de BigQuery, tenez compte des bonnes pratiques suivantes :

  • Effectuez moins d'écritures, mais plus importantes, au lieu de nombreuses petites.
  • Réduisez au minimum les tâches d'écriture distinctes dans votre table de production finale chaque jour.

Pour appliquer ces bonnes pratiques, traitez vos données par lot ou diffusez-les dans BigQuery. Votre choix de méthode de chargement dépend de la nécessité de charger des volumes de données importants en temps réel ou non. Les sections suivantes expliquent en détail le chargement par lot et la diffusion de données, y compris les outils et services que vous pouvez utiliser pour chaque méthode.

Chargement par lot

Pour respecter la limite de chargement quotidienne par projet pour BigQuery, traitez par lot de grandes quantités de données et chargez-les dans BigQuery avec moins de tâches. Les sections suivantes décrivent plusieurs méthodes que vous pouvez utiliser pour charger vos données par lot.

Charger plus de données pour chaque tâche

Au lieu d'envoyer des données à BigQuery chaque fois que de nouvelles informations sont disponibles, collectez-les et chargez-les dans BigQuery à l'aide d'une seule tâche volumineuse.

Par exemple, au lieu d'exécuter une tâche de chargement distincte pour quelques lignes de données, vous pouvez attendre d'accumuler plusieurs milliers de lignes de données dans un fichier (par exemple, dans un fichier CSV ou JSON), puis exécuter une tâche de chargement pour ajouter toutes les données à une table. Cette action est comptabilisée comme une seule opération de table, même si la tâche contient beaucoup plus de données. Vous pouvez traiter vos fichiers par lot en utilisant des caractères génériques avec votre tâche de chargement. Les caractères génériques vous permettent de sélectionner des lots de fichiers dans un répertoire pour charger plusieurs fichiers dans une seule tâche de chargement.

L'exemple suivant montre comment utiliser des caractères génériques avec votre commande bq load ou vos requêtes SQL LOAD DATA.

bq

L'exemple suivant montre une bq load commande permettant de charger des données CSV depuis Cloud Storage dans une table BigQuery nommée my_target_table. Pour sélectionner plusieurs noms de fichiers sources, utilisez un caractère générique avec la commande. L'option AUTODETECT détermine automatiquement le schéma de votre table à partir des données sources dans Cloud Storage et peut accepter un caractère générique (*) pour charger plusieurs fichiers correspondant à un modèle de nommage spécifique dans la table BigQuery.

bq load \
  --source_format=CSV \
  --autodetect \
  --project_id=PROJECT_ID \
  DATASET_NAME.TABLE_NAME \
  "gs://BUCKET_NAME/OBJECT_PATH_WILDCARD"

Remplacez les éléments suivants :

  • PROJECT_ID : ID de votre Google Cloud projet.
  • DATASET_NAME: nom de l'ensemble de données BigQuery dans lequel vous souhaitez charger les données.
  • TABLE_NAME: nom de la table BigQuery dans laquelle vous souhaitez charger les données.
  • BUCKET_NAME: nom de votre bucket Cloud Storage contenant les fichiers sources.
  • OBJECT_PATH_WILDCARD: chemin d'accès à vos fichiers CSV dans le bucket Cloud Storage. Incluez un caractère générique (*) pour faire correspondre plusieurs fichiers. Par exemple, la chaîne gs://my-bucket/path/to/data/my_prefix_*.csv utilise le caractère générique * pour charger tous les fichiers de gs://my-bucket/path/to/data/ commençant par my_prefix_ et se terminant par .csv.

Pour en savoir plus, consultez les ressources suivantes :

SQL

L'exemple suivant montre comment utiliser la requête SQL LOAD DATA query pour charger des données CSV depuis un bucket Cloud Storage dans une table BigQuery. Pour sélectionner plusieurs noms de fichiers sources, utilisez un caractère générique avec la commande.

LOAD DATA INTO
DATASET_NAME.TABLE_NAME
FROM FILES (
  format = 'SOURCE_FORMAT',
  uris = ['gs://BUCKET_NAME/OBJECT_PATH_WILDCARD]
  );

Remplacez les éléments suivants :

  • DATASET_NAME: nom de l'ensemble de données BigQuery dans lequel vous souhaitez charger les données.
  • TABLE_NAME: nom de la table BigQuery dans laquelle vous souhaitez charger les données.
  • SOURCE_FORMAT définit le type de vos fichiers sources, par exemple CSV ou JSON. Dans cet exemple, utilisez CSV.
  • BUCKET_NAME: nom de votre bucket Cloud Storage contenant les fichiers sources.
  • OBJECT_PATH_WILDCARD: chemin d'accès à vos fichiers CSV dans le bucket Cloud Storage. Incluez un caractère générique (*) pour faire correspondre plusieurs fichiers. Par exemple, la chaîne gs://my-bucket/path/to/data/my_prefix_*.csv utilise le caractère générique * pour charger tous les fichiers de gs://my-bucket/path/to/data/ commençant par my_prefix_ et se terminant par .csv.

Pour en savoir plus, consultez la section Instructions de chargement dans GoogleSQL.

Chargement par lot à l'aide de l'API BigQuery Storage Write

Pour charger des données par lot dans BigQuery, vous pouvez utiliser l'API Storage Write directement depuis votre application avec les bibliothèques clientes de l'API Google.

L'API Storage Write optimise le chargement des données pour respecter les limites de table. Pour la diffusion en temps réel à volume élevé, utilisez un flux PENDING plutôt qu'un flux COMMITTED. Lorsque vous utilisez un flux PENDING, l'API stocke temporairement les enregistrements jusqu'à ce que vous validiez le flux.

Pour obtenir un exemple complet de chargement de données par lot à l'aide de l'API Storage Write, consultez la section Charger des données par lot à l'aide de l'API Storage Write.

Chargement par lot à l'aide de Dataflow

Si vous souhaitez diffuser, transformer et écrire des données dans BigQuery à l'aide de pipelines de données, vous pouvez utiliser Dataflow. Les pipelines de données que vous créez lisent les données à partir de sources compatibles telles que Pub/Sub ou Apache Kafka. Vous pouvez également créer un pipeline Dataflow à l'aide du connecteur BigQueryIO, qui utilise l'API Storage Write pour la diffusion de données hautes performances et la sémantique de type "exactement une fois".

Pour en savoir plus sur l'utilisation de Dataflow pour charger des données par lot dans BigQuery, consultez la section Écrire depuis Dataflow dans BigQuery.

Diffusion de données

Pour charger des volumes de données importants avec des mises à jour fréquentes, nous vous recommandons de diffuser vos données dans BigQuery. Avec la diffusion de données, les nouvelles données sont écrites en continu depuis votre application cliente dans BigQuery, une stratégie qui évite d'atteindre la limite d'exécution d'un trop grand nombre de tâches de chargement. Les sections suivantes décrivent plusieurs méthodes permettant de diffuser vos données dans BigQuery.

Diffuser des données à l'aide de l'API Storage Write

Utilisez l'API Storage Write pour diffuser des enregistrements en temps réel dans BigQuery avec une latence minimale. L'API Storage Write fournit un protocole de diffusion efficace qui offre des fonctionnalités avancées telles que la sémantique de diffusion de type "exactement une fois", la détection des mises à jour de schéma et les upserts de capture de données modifiées (CDC, Change Data Capture) en flux continu. En outre, vous pouvez ingérer jusqu'à 2 Tio par mois sans frais.

Pour en savoir plus sur l'utilisation de l'API Storage Write, consultez la section Diffuser des données à l'aide de l'API Storage Write.

Diffuser des données à l'aide de Dataflow

Utilisez Dataflow pour créer des pipelines de données qui lisent les données à partir de sources compatibles, par exemple Pub/Sub ou Apache Kafka. Ces pipelines transforment ensuite les données et les écrivent dans BigQuery en tant que destination. Vous pouvez créer un pipeline Dataflow à l'aide du connecteur BigQueryIO, qui utilise l'API Storage Write.

Pour en savoir plus sur l'utilisation de Dataflow pour diffuser des données dans BigQuery, consultez la section Écrire depuis Dataflow dans BigQuery.

Bonnes pratiques pour gérer vos tables pour le chargement

En plus de charger par lot ou de diffuser des données dans BigQuery, gérez vos tables de la manière suivante pour les optimiser en vue de l'ingestion de données.

Utiliser des tables partitionnées

Le partitionnement de table est une technique puissante pour gérer les grandes tables dans BigQuery, en particulier lorsque vous devez effectuer des opérations de chargement de données fréquentes. Vous pouvez améliorer considérablement les performances et la rentabilité des tables en divisant une table en segments plus petits et plus faciles à gérer en fonction d'une date, d'un code temporel ou d'un entier.

Le principal avantage du partitionnement pour le chargement de données est que les quotas quotidiens d'opérations de table pour BigQuery s'appliquent au niveau de la partition plutôt qu'au niveau de la table. Pour les tables partitionnées, une limite distincte et plus élevée s'applique aux modifications de partition, remplaçant la limite de table standard. La limite pour les tables partitionnées augmente considérablement le nombre de tâches de chargement que vous pouvez exécuter par jour sans atteindre les limites de quota.

Une stratégie courante et très efficace consiste à charger vos données quotidiennes par lot. Par exemple, vous pouvez collecter toutes les données du jour pour 2025-09-18 dans une table de préparation temporaire. Ensuite, à la fin de la journée, vous exécutez une seule tâche pour charger ces données dans la partition spécifique de ce jour dans votre table de production principale. Étant donné que BigQuery n'interagit qu'avec les données d'une seule partition, cette approche permet de bien organiser vos données et de rendre vos opérations de chargement plus rapides et moins coûteuses.

Bien que le partitionnement soit fortement recommandé pour les tables volumineuses et en croissance, il est préférable de l'éviter si vos partitions sont systématiquement inférieures à 10 Go. Pour en savoir plus, consultez la section Quand utiliser le partitionnement.

Pour en savoir plus sur les différentes méthodes de partitionnement disponibles, telles que le partitionnement par unité de temps et par plages d'entiers, consultez la section Types de tables partitionnées.

Profiter de l'intervalle exponentiel entre les tentatives, de la troncation et de la gigue intégrés

L'intervalle exponentiel entre les tentatives intégré est une méthode de gestion des erreurs qui permet à votre application de récupérer facilement lorsqu'une opération échoue temporairement. Ces échecs peuvent inclure une erreur de limite de débit (rateLimitExceeded) ou un bref problème de réseau (unavailable).

Dans un système fiable, les nœuds de calcul qui prennent des tâches dans votre file d'attente côté client utilisent également l'intervalle exponentiel entre les tentatives. Ils le font lorsqu'ils appellent BigQuery, ce qui crée deux niveaux de protection.

Par exemple, la bibliothèque officielle google-cloud-bigquery-storage pour Python inclut une logique de nouvelle tentative intégrée avec un intervalle exponentiel entre les tentatives. Cette logique gère les erreurs gRPC temporaires, par exemple UNAVAILABLE. Dans la plupart des cas, vous n'avez pas besoin d'écrire vous-même ce code de nouvelle tentative. L'appel client.append_rows() gère automatiquement ces nouvelles tentatives.

Cette gestion intégrée est un avantage significatif de l'utilisation des bibliothèques clientes officielles. Vous n'avez besoin de traiter que les erreurs qui ne peuvent pas être retentées, par exemple INVALID_ARGUMENT, ce qui signifie qu'il existe une incompatibilité de schéma.