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 le streaming de données dans BigQuery pour éviter d'atteindre la limite du nombre de tâches de chargement par table et par jour.
Étant donné que la limite de 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 le streaming.
Fonctionnement des quotas d'opérations sur les tables
La limite BigQuery pour les modifications de table par table et par jour par projet est fixe, qu'il s'agisse d'ajouter ou de mettre à jour des données, ou de tronquer la table. Cette limite inclut le total cumulé 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 recharge. Si vous dépassez la limite d'opérations sur les tables ou leur taux de recharge, les tâches de chargement échouent et génèrent une erreur quotaExceeded. La limite au niveau du projet pour les tâches de chargement par jour est réinitialisée sur une période de 24 heures glissantes. Lorsque les tâches de chargement sont terminées, votre quota disponible diminue. Le quota est ensuite progressivement reconstitué 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 Tâches de chargement.
Pour les tables partitionnées, une limite distincte s'applique aux modifications des tables partitionnées, en remplacement de la limite standard pour les tables.
Pour ne pas dépasser vos limites quotidiennes d'opérations de table, répartissez-les sur une période de 24 heures. Par exemple, si vous effectuez 25 mises à jour, chacune comportant 60 opérations, vous pouvez exécuter environ 60 opérations toutes les 58 minutes. Cette approche vous aide à respecter la limite quotidienne. Pour surveiller les mises à jour des tables, consultez les vues INFORMATION_SCHEMA BigQuery.
Opérations sur les tables exclues du quota
La mise à jour des informations (métadonnées) d'une table et l'utilisation d'instructions LMD ne sont pas comptabilisées dans la limite quotidienne de modification des tables. 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 quotidiennes des tables et n'étaient pas limitées, même à la limite, ce n'est plus le cas.
Les insertions de flux modifient également les tables, mais elles sont régies par leurs propres quotas spécifiques.
Charger des stratégies pour éviter la limite d'opérations sur les tables
Pour ne pas dépasser la limite quotidienne d'opérations sur les tables BigQuery, suivez ces bonnes pratiques :
- Effectuez moins d'écritures, mais de plus grande taille, plutôt que de nombreuses petites écritures.
- Réduisez au minimum les jobs d'écriture distincts dans votre table de production finale chaque jour.
Pour appliquer ces bonnes pratiques, traitez vos données par lot ou en flux continu dans BigQuery. Le choix de la méthode de chargement dépend de la nécessité ou non de charger de grands volumes de données en temps réel. Les sections suivantes expliquent en détail le chargement par lot et le streaming 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, regroupez de grandes quantités de données et chargez-les dans BigQuery avec moins de jobs. 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'avoir accumulé 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 considérée comme une opération sur une table, même si le job contient beaucoup plus de données. Vous pouvez regrouper vos fichiers par lots 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 un seul job 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 commande bq load 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'indicateur AUTODETECT détermine automatiquement le schéma de votre table à partir des données sources dans Cloud Storage. Il peut également accepter un caractère générique (*) pour charger plusieurs fichiers correspondant à un modèle de dénomination 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 projet Google Cloud .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 du 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înegs://my-bucket/path/to/data/my_prefix_*.csvutilise le caractère générique*pour charger tous les fichiers degs://my-bucket/path/to/data/commençant parmy_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 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_FORMATdéfinit le type de vos fichiers sources, par exempleCSVouJSON. Dans cet exemple, utilisezCSV.BUCKET_NAME: nom du 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înegs://my-bucket/path/to/data/my_prefix_*.csvutilise le caractère générique*pour charger tous les fichiers degs://my-bucket/path/to/data/commençant parmy_prefix_et se terminant par.csv.
Pour en savoir plus, consultez Instructions LOAD dans GoogleSQL.
Charger 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 des API Google.
L'API Storage Write optimise le chargement des données pour respecter les limites des tables. Pour le streaming en temps réel et à 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 Charger des données par lot à l'aide de l'API Storage Write.
Charger 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, comme 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 le streaming de données hautes performances et la sémantique "exactement une fois".
Pour en savoir plus sur l'utilisation de Dataflow pour charger des données par lots dans BigQuery, consultez Écrire des données de Dataflow dans BigQuery.
Diffusion de données par flux
Pour charger de gros volumes de données avec des mises à jour fréquentes, nous vous recommandons de diffuser vos données par flux dans BigQuery. Avec le streaming de données, de nouvelles données sont écrites en continu depuis votre application cliente dans BigQuery. Cette stratégie permet d'éviter d'atteindre la limite d'exécution d'un trop grand nombre de jobs 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 streaming efficace qui offre des fonctionnalités avancées telles que la sémantique de diffusion "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 streaming. 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 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 en streaming vers BigQuery, consultez Écrire des données de Dataflow dans BigQuery.
Bonnes pratiques pour gérer vos tables à charger
En plus du chargement par lot ou du streaming de données dans BigQuery, gérez vos tables de différentes manières pour les optimiser pour l'ingestion de données.
Utiliser des tables partitionnées
Le partitionnement des tables 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 les divisant 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 d'opérations quotidiennes sur les tables 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, qui remplace la limite standard des tables. 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 lots. Par exemple, vous pouvez rassembler toutes les données de la journée pour 2025-09-18 dans une table intermédiaire temporaire. Ensuite, à la fin de la journée, vous exécutez un seul job pour charger ces données dans la partition spécifique de cette journée dans votre table de production principale.
Comme 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 en pleine croissance, il est préférable de l'éviter si vos partitions sont systématiquement inférieures à 10 Go. Pour en savoir plus, consultez Quand utiliser le partitionnement.
Pour en savoir plus sur les différentes méthodes de partitionnement disponibles, comme le partitionnement par unité de temps et par plage d'entiers, consultez Types de tables partitionnées.
Profitez de l'intervalle exponentiel entre les tentatives, de la troncature et de la gigue intégrés.
La nouvelle tentative et l'intervalle exponentiel entre les tentatives intégrés sont une méthode de gestion des erreurs qui aide votre application à se rétablir en douceur lorsqu'une opération échoue temporairement. Ces échecs peuvent inclure une erreur de limite de débit (rateLimitExceeded) ou un bref problème réseau (unavailable).
Dans un système fiable, les workers qui prennent des tâches de votre file d'attente côté client utilisent également un intervalle exponentiel entre les tentatives et les relances. Pour ce faire, ils appellent BigQuery, ce qui crée deux niveaux de protection.
Par exemple, la bibliothèque google-cloud-bigquery-storage officielle 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 ce code de nouvelle tentative vous-même. L'appel client.append_rows() gère automatiquement ces nouvelles tentatives.
Cette gestion intégrée est un avantage important de l'utilisation des bibliothèques clientes officielles. Vous n'avez besoin de traiter que les erreurs qui ne peuvent pas être relancées, par exemple INVALID_ARGUMENT, qui signifie qu'il existe une incompatibilité de schéma.