Bonnes pratiques BigQuery – Contrôler les coûts

Vous trouverez sur cette page la description des bonnes pratiques relatives au contrôle des coûts dans BigQuery.

Éviter la requête SELECT *

Bonne pratique : Interrogez uniquement les colonnes dont vous avez besoin.

L'utilisation de la requête SELECT * est le moyen le plus coûteux d'interroger des données. Lorsque vous vous servez de SELECT *, BigQuery effectue une analyse complète de chaque colonne de la table.

Si vous testez ou explorez des données, utilisez l'une des options d'aperçu des données au lieu de SELECT *.

L'application d'une clause LIMIT à une requête SELECT * n'a aucune incidence sur la quantité de données lues. La lecture de tous les octets de la table vous est facturée, et la requête est comptabilisée dans votre quota de niveau gratuit.

Interrogez plutôt les colonnes dont vous avez besoin. Par exemple, excluez une ou plusieurs colonnes des résultats à l'aide de SELECT * EXCEPT.

Si vous devez effectuer des requêtes sur chaque colonne d'une table, mais uniquement sur un sous-ensemble de données, envisagez d'effectuer les actions suivantes :

  • Matérialisez les résultats dans une table de destination, puis interrogez cette table à la place.
  • Partitionnez vos tables par date, puis interrogez la partition concernée. Par exemple, WHERE _PARTITIONDATE="2017-01-01" analyse uniquement la partition du 1er janvier 2017.

Échantillonner des données à l'aide des options d'aperçu

Bonne pratique : N'exécutez pas de requêtes pour explorer ou prévisualiser les données d'une table.

Si vous testez ou explorez vos données, vous pouvez afficher les données gratuitement sans affecter les quotas à l'aide des options d'aperçu de la table.

Vous trouverez ci-dessous les options d'aperçu de données disponibles dans BigQuery :

  • Sur la page Détails de la table dans l'UI Web, cliquez sur Aperçu pour échantillonner les données.
  • Dans la CLI, exécutez la commande bq head et indiquez le nombre de lignes à prévisualiser.
  • Dans l'API, récupérez les données de la table d'un ensemble de lignes spécifié à l'aide de tabledata.list.

Déterminer le prix de vos requêtes avant de les exécuter

Bonne pratique : Avant d'exécuter des requêtes, prévisualisez-les pour estimer les coûts.

Les requêtes sont facturées en fonction du nombre d'octets lus. Pour estimer les coûts avant d'exécuter une requête, utilisez :

  • l'outil de validation des requêtes dans l'UI Web ;
  • le paramètre --dry_run dans la CLI ;
  • le paramètre dryRun lorsque vous envoyez une tâche de requête à l'aide de l'API ;
  • le simulateur de coût Google Cloud Platform.

Utiliser l'outil de validation des requêtes

Lorsque vous saisissez une requête dans l'UI Web, l'outil de validation des requêtes valide la syntaxe de la requête et fournit une estimation du nombre d'octets lus. Vous pouvez vous servir de cette estimation pour calculer le coût de la requête dans le simulateur de coût.

Outil de validation des requêtes

Effectuer une simulation

Ligne de commande

Lorsque vous exécutez une requête dans la CLI, vous pouvez estimer le nombre d'octets lus à l'aide du paramètre --dry_run. Vous pouvez vous servir de cette estimation pour calculer le coût de la requête dans le simulateur de coût.

Par exemple, la requête suivante génère la réponse ci-dessous :

    bq --location=[LOCATION] query --use_legacy_sql=false --dry_run 'SELECT COUNTRY, AIRPORT, IATA FROM `[PROJECT].[DATASET].airports` LIMIT 1000'
    Query successfully validated. Assuming the tables are not modified, running this query will process 10918 bytes of data.

Pour effectuer une simulation à l'aide de l'API, envoyez une tâche de requête avec le paramètre jobs.configuration.dryRun défini sur true.

API

Pour effectuer une simulation à l'aide de l'API, envoyez une tâche de requête avec le paramètre jobs.configuration.dryRun défini sur true.

Go

Avant d'essayer cet exemple, suivez les instructions de configuration de Go décrites dans le Guide de démarrage rapide de BigQuery – Utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API BigQuery Go.

// To run this sample, you will need to create (or reuse) a context and
// an instance of the bigquery client.  For example:
// import "cloud.google.com/go/bigquery"
// ctx := context.Background()
// client, err := bigquery.NewClient(ctx, "your-project-id")
q := client.Query(`
SELECT
	name,
	COUNT(*) as name_count
FROM ` + "`bigquery-public-data.usa_names.usa_1910_2013`" + `
WHERE state = 'WA'
GROUP BY name`)
q.DryRun = true
// Location must match that of the dataset(s) referenced in the query.
q.Location = "US"

job, err := q.Run(ctx)
if err != nil {
	return err
}
// Dry run is not asynchronous, so get the latest status and statistics.
status := job.LastStatus()
if err != nil {
	return err
}
fmt.Printf("This query will process %d bytes\n", status.Statistics.TotalBytesProcessed)

Python

Avant d'essayer cet exemple, suivez les instructions de configuration de Python décrites dans le Guide de démarrage rapide de BigQuery – Utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API BigQuery Python.

Pour effectuer une simulation à l'aide de la bibliothèque cliente Python, définissez la propriété QueryJobConfig.dry_run sur True. Le paramètre Client.query () affiche toujours une tâche QueryJob terminée lorsqu'il a effectué une simulation de configuration de requête.
# from google.cloud import bigquery
# client = bigquery.Client()

job_config = bigquery.QueryJobConfig()
job_config.dry_run = True
job_config.use_query_cache = False
query_job = client.query(
    ('SELECT name, COUNT(*) as name_count '
     'FROM `bigquery-public-data.usa_names.usa_1910_2013` '
     "WHERE state = 'WA' "
     'GROUP BY name'),
    # Location must match that of the dataset(s) referenced in the query.
    location='US',
    job_config=job_config)  # API request

# A dry run query completes immediately.
assert query_job.state == 'DONE'
assert query_job.dry_run

print("This query will process {} bytes.".format(
    query_job.total_bytes_processed))

Utiliser le simulateur de coût

Pour estimer les coûts des requêtes dans le simulateur de coût Google Cloud Platform, saisissez le nombre d'octets traités par la requête en Mo, Go, To ou Po. Si votre requête traite moins de 1 To de données, l'estimation est de 0 $, car BigQuery fournit gratuitement 1 To de traitement de requêtes à la demande par mois.

Simulateur de coût

Restreindre les coûts des requêtes en limitant le nombre d'octets facturés

Bonne pratique : Limitez les coûts des requêtes à l'aide du paramètre "Nombre maximal d'octets facturés".

Vous pouvez limiter le nombre d'octets facturés pour une requête en utilisant le paramètre "Nombre maximal d'octets facturés". Si elle lit des octets qui dépassent la limite que vous avez définie, la requête échoue sans engendrer de frais.

Si une requête échoue en raison du paramètre "Nombre maximal d'octets facturés", une erreur est renvoyée sous la forme suivante :

Error: Query exceeded limit for bytes billed: 1000000. 10485760 or higher required.

Pour définir le nombre maximal d'octets facturés, procédez comme suit :

  • Dans l'UI Web de BigQuery, saisissez un nombre entier dans le champ Nombre maximal d'octets facturés des options de requête. Nombre maximal d'octets facturés
  • Dans la CLI, exécutez la commande bq query avec le paramètre --maximum_bytes_billed.

    bq --location=US query --maximum_bytes_billed=1000000 --use_legacy_sql=false "SELECT word FROM `bigquery-public-data.samples.shakespeare`"
    
  • Dans l'API, définissez la propriété maximumBytesBilled.

La clause LIMIT n'affecte pas les coûts

Bonne pratique : N'utilisez pas la clause LIMIT comme méthode de contrôle des coûts.

L'application d'une clause LIMIT à une requête n'a aucune incidence sur la quantité de données lues. Elle limite seulement la sortie de l'ensemble de résultats. La lecture de tous les octets de la table vous est facturée, comme indiqué par la requête.

La quantité de données lues par la requête est comptabilisée dans votre quota de niveau gratuit malgré la présence d'une clause LIMIT.

Afficher les coûts à l'aide d'un tableau de bord et interroger vos journaux d'audit

Bonne pratique : Créez un tableau de bord pour afficher vos données de facturation afin de pouvoir adapter votre utilisation de BigQuery. Pensez également à diffuser vos journaux d'audit vers BigQuery afin d'analyser les modèles d'utilisation.

Vous pouvez exporter vos données de facturation dans BigQuery et les visualiser dans un outil comme Google Data Studio. Pour accéder au tutoriel sur la création d'un tableau de bord de facturation, consultez l'article intitulé Visualize GCP Billing using BigQuery and Data Studio.

Vous pouvez également diffuser vos journaux d'audit vers BigQuery et les analyser pour rechercher des modèles d'utilisation, comme les coûts des requêtes par utilisateur.

Partitionner les données par date

Bonne pratique : Partitionnez vos tables par date.

Si possible, partitionnez vos tables BigQuery par date. Le partitionnement des tables vous permet d'interroger des sous-ensembles de données pertinents afin d'améliorer les performances et de réduire les coûts.

Par exemple, lorsque vous interrogez des tables partitionnées, filtrez une date ou une plage de dates à l'aide de la colonne pseudo _PARTITIONTIME. La requête ne traite que les données des partitions spécifiées par la date ou la plage.

Matérialiser les résultats d'une requête par étapes

Bonne pratique : Matérialisez les résultats de votre requête par étapes, si possible.

Si vous créez une requête volumineuse à plusieurs étapes, BigQuery lit toutes les données requises par la requête à chaque fois que vous l'exécutez. Toutes les données lues à chaque exécution de la requête vous sont facturées.

Divisez plutôt votre requête en étapes, où chacune d'elles matérialise les résultats de la requête en les écrivant dans une table de destination. Interroger la plus petite table de destination vous permet de diminuer la quantité de données lues et de réduire les frais. Le coût de stockage des résultats matérialisés est bien inférieur au coût de traitement de grandes quantités de données.

Prendre en compte le coût des grands ensembles de résultats

Bonne pratique : Si vous écrivez les résultats d'une requête volumineuse dans une table de destination, servez-vous du délai d'expiration de la table par défaut pour supprimer les données lorsque vous n'en avez plus besoin.

Conserver de grands ensembles de résultats dans l'espace de stockage BigQuery a un coût. Si vous n'avez pas besoin d'un accès permanent aux résultats, supprimez automatiquement les données à l'aide du délai d'expiration de la table par défaut.

Pour en savoir plus, consultez les tarifs de stockage.

Utiliser les insertions en flux continu avec prudence

Bonne pratique : Utilisez des insertions en flux continu uniquement si vos données doivent être immédiatement disponibles.

Le chargement des données est gratuit dans BigQuery, contrairement à la diffusion des données. Chargez vos données plutôt que de les diffuser, sauf si vos données doivent être immédiatement disponibles.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.