Estimer et contrôler les coûts

Cette page décrit les bonnes pratiques pour estimer et contrôler les coûts dans BigQuery.

Les principaux coûts dans BigQuery sont ceux liés au calcul, utilisé pour le traitement des requêtes, et au stockage, pour les données stockées dans BigQuery. BigQuery propose deux types de modèles de tarification pour le traitement des requêtes : à la demande et basée sur la capacité. Chaque modèle propose différentes bonnes pratiques pour contrôler les coûts. Pour les données stockées dans BigQuery, les coûts dépendent du modèle de facturation du stockage configuré pour chaque ensemble de données.

Comprendre les tarifs de calcul pour BigQuery

Il existe de subtiles différences dans la tarification du calcul pour BigQuery qui affectent la planification de la capacité et le contrôle des coûts.

Modèles de tarification

Pour le calcul à la demande dans BigQuery, vous êtes facturé par Tio pour les requêtes BigQuery.

En revanche, pour la capacité de calcul dans BigQuery, vous êtes facturé pour les ressources de calcul (emplacements) utilisées pour traiter la requête. Pour utiliser ce modèle, vous devez configurer des réservations pour les emplacements.

Les réservations présentent les caractéristiques suivantes :

  • Ils sont alloués dans des pools d'emplacements et vous permettent de gérer la capacité et d'isoler les charges de travail de manière adaptée à votre organisation.
  • Ils doivent résider dans un projet d'administration et sont soumis à des quotas et limites.

Le modèle de tarification de la capacité propose plusieurs éditions, qui offrent toutes une option de paiement à l'usage facturée en heures d'emplacement. Les éditions Enterprise et Enterprise Plus proposent également des engagements d'emplacements facultatifs sur un ou trois ans qui peuvent vous faire économiser de l'argent par rapport au tarif du paiement à l'usage.

Vous pouvez également définir des réservations avec autoscaling à l'aide de l'option de paiement à l'utilisation. Pour en savoir plus, consultez les ressources suivantes :

Limiter les coûts pour chaque modèle

Lorsque vous utilisez le modèle de tarification à la demande, la seule façon de limiter les coûts est de configurer des quotas quotidiens au niveau du projet ou de l'utilisateur. Toutefois, ces quotas imposent un plafond strict qui empêche les utilisateurs d'exécuter des requêtes au-delà de la limite du quota. Pour définir des quotas, consultez Créer des quotas de requêtes personnalisés.

Lorsque vous utilisez le modèle de tarification basé sur la capacité avec des réservations d'emplacements, vous spécifiez le nombre maximal d'emplacements disponibles pour une réservation. Vous pouvez également souscrire des engagements d'emplacements qui vous permettent de bénéficier de remises pendant une période donnée.

Vous pouvez utiliser les éditions entièrement à la demande en définissant la référence de la réservation sur 0 et le maximum sur un paramètre qui répond aux besoins de votre charge de travail. BigQuery augmente automatiquement le nombre d'emplacements nécessaires à votre charge de travail, sans jamais dépasser le maximum que vous avez défini. Pour en savoir plus, consultez Gérer la charge de travail à l'aide des réservations.

Contrôler les coûts des requêtes

Pour contrôler les coûts des requêtes individuelles, nous vous recommandons de suivre d'abord les bonnes pratiques d'optimisation du calcul des requêtes et d'optimisation du stockage.

Les sections suivantes décrivent d'autres bonnes pratiques que vous pouvez utiliser pour mieux contrôler les coûts de vos requêtes.

Créer des quotas de requêtes personnalisés

Bonne pratique : Utilisez des quotas de requêtes quotidiennes personnalisés pour limiter la quantité de données traitées par jour.

Vous pouvez gérer les coûts en définissant un quota personnalisé qui spécifie une limite concernant la quantité de données traitées par jour et par projet ou par utilisateur. Les utilisateurs ne peuvent pas exécuter de requêtes une fois le quota atteint.

Pour définir un quota personnalisé, vous devez disposer de rôles ou d'autorisations spécifiques. Pour connaître les quotas à définir, consultez Quotas et limites.

Pour en savoir plus, consultez Limiter les coûts pour chaque modèle de tarification.

Vérifier le coût estimé avant d'exécuter une requête

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

Lorsque vous utilisez le modèle de tarification à la demande, 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 :

Utiliser l'outil de validation des requêtes

Lorsque vous saisissez une requête dans la console Google Cloud , l'outil de validation des requêtes valide sa syntaxe 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.

  • Si votre requête n'est pas valide, l'outil de validation des requêtes affiche un message d'erreur. Exemple :

    Not found: Table myProject:myDataset.myTable was not found in location US

  • Si votre requête est valide, l'outil de validation des requêtes fournit une estimation du nombre d'octets nécessaires pour traiter la requête. Exemple :

    This query will process 623.1 KiB when run.

Effectuer une simulation

Pour effectuer une simulation, procédez comme suit :

Console

  1. Accédez à la page BigQuery.

    Accéder à BigQuery

  2. Saisissez votre requête dans l'Éditeur de requête.

    Si la requête est valide, une coche apparaît automatiquement avec la quantité de données que la requête va traiter. Si la requête n'est pas valide, un point d'exclamation apparaît avec un message d'erreur.

bq

Saisissez une requête semblable à celle-ci à l'aide de l'option --dry_run.

bq query \
--use_legacy_sql=false \
--dry_run \
'SELECT
   COUNTRY,
   AIRPORT,
   IATA
 FROM
   `project_id`.dataset.airports
 LIMIT
   1000'

Pour une requête valide, la commande génère la réponse suivante :

Query successfully validated. Assuming the tables are not modified,
running this query will process 10918 bytes of data.

API

Pour effectuer une simulation avec l'API, envoyez une tâche de requête avec la valeur dryRun définie sur true dans le type JobConfiguration.

Go

Avant d'essayer cet exemple, suivez les instructions de configuration pour Go du guide de démarrage rapide de BigQuery : Utiliser les bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API BigQuery pour Go.

Pour vous authentifier auprès de BigQuery, configurez le service Identifiants par défaut de l'application. Pour en savoir plus, consultez la page Configurer l'authentification pour les bibliothèques clientes. 

import (
	"context"
	"fmt"
	"io"

	"cloud.google.com/go/bigquery"
)

// queryDryRun demonstrates issuing a dry run query to validate query structure and
// provide an estimate of the bytes scanned.
func queryDryRun(w io.Writer, projectID string) error {
	// projectID := "my-project-id"
	ctx := context.Background()
	client, err := bigquery.NewClient(ctx, projectID)
	if err != nil {
		return fmt.Errorf("bigquery.NewClient: %v", err)
	}
	defer client.Close()

	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 := status.Err(); err != nil {
		return err
	}
	fmt.Fprintf(w, "This query will process %d bytes\n", status.Statistics.TotalBytesProcessed)
	return nil
}

Java

Avant d'essayer cet exemple, suivez les instructions de configuration pour Java du guide de démarrage rapide de BigQuery : Utiliser les bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API BigQuery pour Java.

Pour vous authentifier auprès de BigQuery, configurez le service Identifiants par défaut de l'application. Pour en savoir plus, consultez la page Configurer l'authentification pour les bibliothèques clientes. 

import com.google.cloud.bigquery.BigQuery;
import com.google.cloud.bigquery.BigQueryException;
import com.google.cloud.bigquery.BigQueryOptions;
import com.google.cloud.bigquery.Job;
import com.google.cloud.bigquery.JobInfo;
import com.google.cloud.bigquery.JobStatistics;
import com.google.cloud.bigquery.QueryJobConfiguration;

// Sample to run dry query on the table
public class QueryDryRun {

  public static void runQueryDryRun() {
    String query =
        "SELECT name, COUNT(*) as name_count "
            + "FROM `bigquery-public-data.usa_names.usa_1910_2013` "
            + "WHERE state = 'WA' "
            + "GROUP BY name";
    queryDryRun(query);
  }

  public static void queryDryRun(String query) {
    try {
      // Initialize client that will be used to send requests. This client only needs to be created
      // once, and can be reused for multiple requests.
      BigQuery bigquery = BigQueryOptions.getDefaultInstance().getService();

      QueryJobConfiguration queryConfig =
          QueryJobConfiguration.newBuilder(query).setDryRun(true).setUseQueryCache(false).build();

      Job job = bigquery.create(JobInfo.of(queryConfig));
      JobStatistics.QueryStatistics statistics = job.getStatistics();

      System.out.println(
          "Query dry run performed successfully." + statistics.getTotalBytesProcessed());
    } catch (BigQueryException e) {
      System.out.println("Query not performed \n" + e.toString());
    }
  }
}

Node.js

Avant d'essayer cet exemple, suivez les instructions de configuration pour Node.js du guide de démarrage rapide de BigQuery : Utiliser les bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API BigQuery pour Node.js.

Pour vous authentifier auprès de BigQuery, configurez le service Identifiants par défaut de l'application. Pour en savoir plus, consultez la page Configurer l'authentification pour les bibliothèques clientes. 

// Import the Google Cloud client library
const {BigQuery} = require('@google-cloud/bigquery');
const bigquery = new BigQuery();

async function queryDryRun() {
  // Runs a dry query of the U.S. given names dataset for the state of Texas.

  const query = `SELECT name
    FROM \`bigquery-public-data.usa_names.usa_1910_2013\`
    WHERE state = 'TX'
    LIMIT 100`;

  // For all options, see https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/query
  const options = {
    query: query,
    // Location must match that of the dataset(s) referenced in the query.
    location: 'US',
    dryRun: true,
  };

  // Run the query as a job
  const [job] = await bigquery.createQueryJob(options);

  // Print the status and statistics
  console.log('Status:');
  console.log(job.metadata.status);
  console.log('\nJob Statistics:');
  console.log(job.metadata.statistics);
}

PHP

Avant d'essayer cet exemple, suivez les instructions de configuration pour PHP du guide de démarrage rapide de BigQuery : Utiliser les bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API BigQuery pour PHP.

Pour vous authentifier auprès de BigQuery, configurez le service Identifiants par défaut de l'application. Pour en savoir plus, consultez la page Configurer l'authentification pour les bibliothèques clientes. 

use Google\Cloud\BigQuery\BigQueryClient;

/** Uncomment and populate these variables in your code */
// $projectId = 'The Google project ID';
// $query = 'SELECT id, view_count FROM `bigquery-public-data.stackoverflow.posts_questions`';

// Construct a BigQuery client object.
$bigQuery = new BigQueryClient([
    'projectId' => $projectId,
]);

// Set job configs
$jobConfig = $bigQuery->query($query);
$jobConfig->useQueryCache(false);
$jobConfig->dryRun(true);

// Extract query results
$queryJob = $bigQuery->startJob($jobConfig);
$info = $queryJob->info();

printf('This query will process %s bytes' . PHP_EOL, $info['statistics']['totalBytesProcessed']);

Python

Définissez la propriété QueryJobConfig.dry_run sur True. La méthode Client.query() renvoie toujours une tâche QueryJob terminée lorsque vous lui transmettez une configuration de requête simulée.

Avant d'essayer cet exemple, suivez les instructions de configuration pour Python du guide de démarrage rapide de BigQuery : Utiliser les bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API BigQuery pour Python.

Pour vous authentifier auprès de BigQuery, configurez le service Identifiants par défaut de l'application. Pour en savoir plus, consultez la page Configurer l'authentification pour les bibliothèques clientes. 

from google.cloud import bigquery

# Construct a BigQuery client object.
client = bigquery.Client()

job_config = bigquery.QueryJobConfig(dry_run=True, use_query_cache=False)

# Start the query, passing in the extra configuration.
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"
    ),
    job_config=job_config,
)  # Make an API request.

# A dry run query completes immediately.
print("This query will process {} bytes.".format(query_job.total_bytes_processed))

Estimer le coût d'une requête

Lorsque vous utilisez le modèle de tarification à la demande, vous pouvez estimer le coût d'exécution d'une requête en calculant le nombre d'octets traités.

Calcul de la taille des requêtes à la demande

Pour calculer le nombre d'octets traités par les différents types de requêtes, consultez les sections suivantes :

Éviter d'exécuter des requêtes pour explorer les données d'une table

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 :

  • Dans la console Google Cloud , sur la page "Détails de la table", cliquez sur l'onglet Aperçu pour échantillonner les données.
  • Dans l'outil de ligne de commande bq, exécutez la commande bq head et spécifiez le nombre de lignes à prévisualiser.
  • Dans l'API, récupérez les données de la table à partir d'un ensemble de lignes donné à l'aide de tabledata.list.
  • Évitez d'utiliser LIMIT dans des tables hors cluster, car cette clause LIMIT ne permet pas de réduire les coûts de calcul.

Limiter le nombre d'octets facturés par requête

Bonne pratique : Limitez les coûts des requêtes à l'aide du paramètre "Nombre maximal d'octets facturés" lorsque vous utilisez le modèle de tarification à la demande.

Vous pouvez limiter le nombre d'octets facturés pour une requête en utilisant le paramètre "Nombre maximal d'octets facturés". Lorsque vous définissez le nombre maximal d'octets facturés, le nombre d'octets lus par la requête est estimé avant l'exécution de la requête. Si le nombre d'octets estimés dépasse la limite, la requête échoue sans engendrer de frais.

Pour les tables en cluster, l'estimation du nombre d'octets facturés pour une requête correspond à la limite supérieure et peut être supérieure au nombre réel d'octets facturés après l'exécution de la requête. Dans certains cas, si vous définissez le nombre maximal d'octets facturés, une requête sur une table en cluster peut échouer, même si le nombre d'octets réellement facturé ne dépasse pas le paramètre d'octets facturés maximal.

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 :

Console

  1. Dans l'éditeur de requête, cliquez sur Plus > Paramètres de requête > Options avancées.
  2. Dans le champ Nombre maximal d'octets facturés, saisissez un nombre entier.
  3. Cliquez sur Enregistrer.

bq

Exécutez la commande bq query avec l'option --maximum_bytes_billed.

  bq query --maximum_bytes_billed=1000000 \
  --use_legacy_sql=false \
  'SELECT
     word
   FROM
     `bigquery-public-data`.samples.shakespeare'

API

Définissez la propriété maximumBytesBilled dans JobConfigurationQuery ou QueryRequest.

Éviter d'utiliser LIMIT dans des tables hors cluster

Bonne pratique : Pour les tables hors cluster, n'utilisez pas de clause LIMIT comme méthode de contrôle des coûts.

Pour les tables hors cluster, l'application d'une clause LIMIT à une requête n'a aucune incidence sur la quantité de données lues. Vous êtes facturé pour la lecture de tous les octets de la table, comme indiqué par la requête, même si celle-ci ne renvoie qu'un sous-ensemble. Dans un tableau en cluster, une clause LIMIT peut réduire le nombre d'octets analysés, car l'analyse s'arrête lorsque suffisamment de blocs sont analysés pour obtenir le résultat. Seuls les octets analysés vous sont facturés.

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.

Contrôler les coûts des charges de travail

Cette section décrit les bonnes pratiques pour contrôler les coûts au sein d'une charge de travail. Une charge de travail est un ensemble de requêtes associées. Par exemple, une charge de travail peut être un pipeline de transformation de données qui s'exécute quotidiennement, un ensemble de tableaux de bord exécutés par un groupe d'analystes commerciaux ou plusieurs requêtes ponctuelles exécutées par un ensemble de data scientists.

Utiliser le simulateur de coût Google Cloud

Bonne pratique : Utilisez le simulateur de coûtGoogle Cloud pour créer une estimation globale des coûts mensuels pour BigQuery en fonction de l'utilisation prévue. Vous pouvez ensuite comparer cette estimation à vos coûts réels pour identifier les points à optimiser.

À la demande

Pour estimer les coûts dans le simulateur de coûtGoogle Cloud lorsque vous utilisez le modèle de tarification à la demande, procédez comme suit :

  1. Ouvrez le simulateur de coûtGoogle Cloud .
  2. Cliquez sur Ajouter à l'estimation.
  3. Sélectionnez BigQuery.
  4. Sélectionnez "À la demande" pour Type de service.
  5. Choisissez l'emplacement où vos requêtes seront exécutées.
  6. Dans le champ Quantité de données interrogées, saisissez l'estimation des octets lus provenant de votre simulation ou de l'outil de validation des requêtes.
  7. Saisissez les estimations de l'utilisation de l'espace de stockage pour le stockage actif, le stockage à long terme, les insertions en flux continu et les lectures en flux continu. Vous devez seulement estimer le stockage physique ou logique, selon le modèle de facturation du stockage des ensembles de données.
  8. L'estimation s'affiche dans le panneau Détails des coûts. Pour en savoir plus sur le coût estimé, cliquez sur Ouvrir la vue détaillée. Vous pouvez également télécharger et partager l'estimation des coûts.

Pour en savoir plus, consultez la section Tarifs à la demande.

Éditions

Pour estimer les coûts dans le simulateur de coûtGoogle Cloud lorsque vous utilisez le modèle de tarification basée sur la capacité avec les éditions BigQuery, procédez comme suit :

  1. Ouvrez le simulateur de coûtGoogle Cloud .
  2. Cliquez sur Ajouter à l'estimation.
  3. Sélectionnez BigQuery.
  4. Sélectionnez "Éditions" pour Type de service.
  5. Choisissez la localisation d'utilisation des emplacements.
  6. Choisissez votre édition.
  7. Définissez le nombre maximal d'emplacements, le nombre d'emplacements de base, l'engagement (facultatif) et l'utilisation estimée de l'autoscaling.
  8. Choisissez l'emplacement de stockage des données.
  9. Saisissez les estimations de l'utilisation de l'espace de stockage pour le stockage actif, le stockage à long terme, les insertions en flux continu et les lectures en flux continu. Vous devez seulement estimer le stockage physique ou logique, selon le modèle de facturation du stockage des ensembles de données.
  10. L'estimation s'affiche dans le panneau Détails des coûts. Pour en savoir plus sur le coût estimé, cliquez sur Ouvrir la vue détaillée. Vous pouvez également télécharger et partager l'estimation des coûts.

Pour en savoir plus, consultez Tarification basée sur la capacité.

Utiliser des réservations et des engagements

Bonne pratique : Utilisez les réservations et les engagements BigQuery pour contrôler les coûts.

Pour en savoir plus, consultez Limiter les coûts pour chaque modèle de tarification.

Utiliser l'outil d'estimation des emplacements

Bonne pratique : Utilisez l'estimateur d'emplacements pour estimer le nombre d'emplacements requis pour vos charges de travail.

L'estimateur d'emplacements BigQuery vous aide à gérer la capacité des emplacements en fonction des métriques de performances historiques.

De plus, les clients utilisant le modèle de tarification à la demande peuvent consulter des recommandations de dimensionnement pour les engagements et les réservations avec autoscaling offrant des performances similaires lorsqu'ils passent à la tarification basée sur la capacité.

Annuler les tâches de longue durée inutiles

Pour libérer de la capacité, vérifiez les tâches de longue durée pour vous assurer qu'elles doivent continuer à s'exécuter. Si ce n'est pas le cas, résiliez-les.

Afficher les coûts à l'aide d'un tableau de bord

Bonne pratique : Créez un tableau de bord pour analyser vos données Cloud Billing afin de pouvoir surveiller et ajuster votre utilisation de BigQuery.

Vous pouvez exporter vos données de facturation dans BigQuery et les visualiser dans un outil comme Looker Studio. Pour consulter un tutoriel sur la création d'un tableau de bord de facturation, consultez Visualiser la facturation Google Cloud à l'aide de BigQuery et Looker Studio.

Utiliser les budgets et les alertes de facturation

Bonne pratique : Utilisez les budgets Cloud Billing pour surveiller vos frais BigQuery depuis un seul et même endroit.

Les budgets de facturation Cloud vous permettent de suivre vos coûts réels par rapport à vos coûts planifiés. Une fois que vous avez fixé un montant pour votre budget, définissez les règles fixant des seuils d'alertes budgétaires qui permettront de déclencher des notifications par e-mail. Vous pourrez ainsi suivre de près vos dépenses BigQuery par rapport à votre budget.

Contrôler les coûts de stockage

Suivez ces bonnes pratiques pour optimiser le coût du stockage BigQuery. Vous pouvez également optimiser le stockage pour améliorer les performances des requêtes.

Utiliser le stockage à long terme

Bonne pratique : Utilisez les tarifs de stockage à long terme pour réduire le coût des données plus anciennes.

Lorsque vous chargez des données dans le stockage BigQuery, elles sont soumises aux tarifs de stockage de BigQuery. Pour les données plus anciennes, vous pouvez profiter automatiquement des tarifs de stockage à long terme de BigQuery.

Si une table n'est pas modifiée pendant 90 jours consécutifs, le prix de stockage de cette table diminue automatiquement de 50 %. Si vous disposez d'une table partitionnée, chaque partition est prise en considération individuellement pour l'éligibilité à une tarification à long terme soumise aux mêmes règles que les tables non partitionnées.

Configurer le modèle de facturation du stockage

Bonne pratique : Optimisez le modèle de facturation du stockage en fonction de vos habitudes d'utilisation.

BigQuery permet de facturer le stockage en utilisant des octets logiques (non compressés) ou physiques (compressés), ou une combinaison des deux. Le modèle de facturation du stockage configuré pour chaque ensemble de données détermine vos tarifs de stockage, mais n'a aucune incidence sur les performances des requêtes.

Vous pouvez utiliser les vues INFORMATION_SCHEMA pour déterminer le modèle de facturation du stockage qui vous convient le mieux en fonction de vos habitudes d'utilisation.

Éviter d'écraser les tables

Bonne pratique : Lorsque vous utilisez le modèle de facturation du stockage physique, évitez d'écraser les tables à plusieurs reprises.

Lorsque vous écrasez une table, par exemple en utilisant le paramètre --replace dans les tâches de chargement par lot ou l'instruction SQL TRUNCATE TABLE, les données remplacées sont conservées pendant la durée des périodes de voyage temporel et de sécurité. Si vous écrasez fréquemment une table, des frais de stockage supplémentaires vous seront facturés.

Vous pouvez charger des données de manière incrémentielle dans une table à l'aide du paramètre WRITE_APPEND dans les tâches de chargement, de l'instruction SQL MERGE ou de l'API Storage Write.

Réduire la fenêtre de fonctionnalité temporelle

Bonne pratique : Selon vos besoins, vous pouvez réduire la fenêtre de fonctionnalité temporelle.

Réduire la valeur par défaut de la fenêtre de fonctionnalité temporelle (sept jours) a pour effet de réduire la période de conservation des données supprimées ou modifiées dans une table. Le stockage temporel n'est facturé que lorsque vous utilisez le modèle de facturation du stockage physique (compressé).

La fenêtre de fonctionnalité temporelle est définie au niveau de l'ensemble de données. Vous pouvez également définir la fenêtre de fonctionnalité temporelle par défaut pour les nouveaux ensembles de données à l'aide des paramètres de configuration.

Utiliser l'expiration de la table pour les tables de destination

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 selon le délai d'expiration de table défini par défaut.

Archiver des données dans Cloud Storage

Bonne pratique : Pensez à archiver les données dans Cloud Storage.

Vous pouvez déplacer des données de BigQuery vers Cloud Storage en fonction de vos besoins d'archivage. Nous vous recommandons de vous pencher sur la tarification du stockage à long terme et le modèle de facturation du stockage physique avant d'exporter des données en dehors de BigQuery.

Résoudre les problèmes de différences de coûts et de frais inattendus dans BigQuery

Pour résoudre les problèmes de frais BigQuery inattendus ou d'écarts de coûts, procédez comme suit :

  1. Pour comprendre d'où proviennent les frais BigQuery lorsque vous consultez le rapport Cloud Billing, nous vous recommandons tout d'abord de regrouper les frais par SKU. Vous pourrez ainsi plus facilement observer l'utilisation et les frais des services BigQuery correspondants.

  2. Ensuite, étudiez la tarification des SKU correspondants sur la page de documentation sur les SKU ou sur la page Pricing de l'interface utilisateur Cloud Billing pour comprendre de quelle fonctionnalité il s'agit (par exemple, l'API BigQuery Storage Read, le stockage à long terme, la tarification à la demande ou l'édition Standard).

  3. Après avoir identifié les SKU correspondants, utilisez les vues INFORMATION_SCHEMA pour identifier les ressources spécifiques associées à ces frais, par exemple :

Points importants à prendre en compte pour le dépannage :

  • Tenez compte du fait qu'une période quotidienne dans le rapport Cloud Billing commence à minuit, heure du Pacifique des États-Unis et du Canada (UTC-8), et applique le passage à l'heure d'été aux États-Unis. Ajustez vos calculs et vos agrégations de données pour qu'ils correspondent aux mêmes périodes.

  • Filtrez par projet si plusieurs projets sont associés au compte de facturation et que vous souhaitez examiner les frais provenant d'un projet spécifique.

  • Veillez à sélectionner la bonne région lorsque vous effectuez des investigations.

Pour résoudre les problèmes de frais inattendus liés à l'exécution de jobs, vous devez identifier l'origine de ces frais :

  • Si vous constatez une augmentation des coûts d'analyse à la demande, cela peut être lié à une augmentation du nombre de tâches lancées ou à une modification de la quantité de données à traiter par les tâches. Examinez ce problème à l'aide de la vue INFORMATION_SCHEMA.JOBS.
  • Si les frais liés aux emplacements engagés augmentent, examinez la situation en interrogeant INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES pour voir si de nouveaux engagements ont été souscrits ou modifiés.
  • Pour les augmentations de frais liées à l'utilisation de réservations, examinez les modifications apportées aux réservations enregistrées dans INFORMATION_SCHEMA.RESERVATION_CHANGES. Pour faire correspondre l'utilisation des réservations d'autoscaling aux données de facturation, suivez l'exemple d'autoscaling.

Heures d'utilisation des emplacements facturées supérieures à celles calculées dans la vue INFORMATION_SCHEMA.JOBS

Lorsque vous utilisez une réservation avec autoscaling, la facturation est calculée en fonction du nombre d'emplacements mis à l'échelle, et non du nombre d'emplacements utilisés. BigQuery effectue l'autoscaling par multiples de 50 emplacements, ce qui entraîne une facturation du multiple le plus proche, même si la quantité utilisée est inférieure à la quantité autoscalée. L'autoscaler dispose d'une période minimale de 1 minute avant le scaling à la baisse. Cela signifie qu'au moins 1 minute sera facturée, même si la requête a utilisé les emplacements pendant moins de temps (par exemple, pendant seulement 10 secondes sur la minute). La méthode correcte pour estimer les frais d'une réservation avec autoscaling est décrite sur la page Autoscaling des emplacements. Pour en savoir plus sur l'utilisation efficace de l'autoscaling, consultez les bonnes pratiques concernant l'autoscaling.

Un scénario similaire sera observé pour les réservations sans autoscaling : la facturation est calculée en fonction du nombre d'emplacements provisionnés, et non du nombre d'emplacements utilisés. Si vous souhaitez estimer les frais pour une réservation sans autoscaling, vous pouvez interroger directement la vue RESERVATIONS_TIMELINE.

La facturation est inférieure au nombre total d'octets facturés calculé à l'aide de INFORMATION_SCHEMA.JOBS pour les projets exécutant des requêtes à la demande

Plusieurs raisons peuvent expliquer que la facturation réelle soit inférieure au nombre d'octets traités calculé :

  • Chaque projet bénéficie d'un To de requêtes de niveau gratuit par mois, sans frais supplémentaires.
  • Les jobs de type SCRIPT n'ont pas été exclus du calcul, ce qui a pu entraîner la comptabilisation de certaines valeurs deux fois.
  • Différents types d'économies appliquées à votre compte de facturation Cloud, comme les remises négociées, les crédits promotionnels, etc. Consultez la section "Économies" du rapport Cloud Billing. Le niveau gratuit inclut également 1 To de requêtes par mois.

La facturation est supérieure aux octets traités calculés à l'aide de INFORMATION_SCHEMA.JOBS pour les projets exécutant des requêtes à la demande

Si le montant de la facturation est supérieur à la valeur que vous avez calculée en interrogeant la vue INFORMATION_SCHEMA.JOBS, cela peut être dû à certaines conditions :

  • Requêtes sur les tables avec sécurité au niveau des lignes

    • Les requêtes sur les tables avec sécurité au niveau des lignes ne produisent pas de valeur pour total_bytes_billed dans la vue INFORMATION_SCHEMA.JOBS. Par conséquent, la facturation calculée à l'aide de total_bytes_billed à partir de la vue INFORMATION_SCHEMA.JOBS sera inférieure à la valeur facturée. Pour en savoir plus sur la raison pour laquelle ces informations ne sont pas visibles, consultez la page Bonnes pratiques en matière de sécurité au niveau des lignes.

  • Effectuer des opérations de ML dans BigQuery

    • Les tarifs de BigQuery ML pour les requêtes à la demande dépendent du type de modèle créé. Certaines de ces opérations sur les modèles sont facturées à un tarif plus élevé que les requêtes non liées au ML. Par conséquent, si vous additionnez simplement tous les total_billed_bytes pour le projet et que vous utilisez le tarif à la demande standard par téraoctet, vous n'obtiendrez pas une agrégation correcte des prix. Vous devez tenir compte de la différence de prix par téraoctet.

  • Montants des prix incorrects

    • Vérifiez que les valeurs de tarification par téraoctet correctes sont utilisées dans les calculs. Assurez-vous de choisir la bonne région, car les prix dépendent de la localisation. Consultez la documentation sur les tarifs.

Nous vous conseillons de suivre la méthode recommandée pour calculer l'utilisation des jobs à la demande à des fins de facturation, décrite dans notre documentation publique.

Facturation de l'utilisation de l'API BigQuery Reservations alors que l'API est désactivée et qu'aucune réservation ni aucun engagement n'ont été utilisés

Examinez le SKU pour mieux comprendre les services facturés. Si le SKU facturé est BigQuery Governance SKU, il s'agit de frais provenant de Dataplex Universal Catalog. Certaines fonctionnalités de Dataplex Universal Catalog déclenchent l'exécution de jobs à l'aide de BigQuery. Ces frais sont désormais traités sous le SKU de l'API BigQuery Reservations correspondante. Pour en savoir plus, consultez la documentation sur les tarifs de Dataplex Universal Catalog.

Le projet est attribué à une réservation, mais les coûts d'analyse BigQuery à la demande s'affichent toujours

Consultez la section Résoudre les problèmes liés aux réservations pour identifier l'origine des débits Analysis.

Frais inattendus pour les emplacements à la demande de l'édition BigQuery Standard

Dans le rapport sur la facturation Cloud, appliquez un filtre avec le libellé goog-bq-feature-type et la valeur BQ_STUDIO_NOTEBOOK. L'utilisation que vous verrez sera mesurée en tant qu'emplacements à la demande dans BigQuery Standard Edition. Il s'agit de frais pour l'utilisation du notebook BigQuery Studio. En savoir plus sur les tarifs des notebooks BigQuery Studio

Frais de l'API BigQuery Reservations apparaissant après la désactivation de l'API

La désactivation de BigQuery n'arrêtera pas les frais d'engagement. Pour ne plus être facturé pour un engagement, vous devez le supprimer. Définissez l'option de renouvellement sur NONE. L'engagement sera automatiquement supprimé à son expiration.

Frais de stockage inattendus

Voici quelques scénarios pouvant entraîner une augmentation des frais de stockage :

La suppression de tables ou d'ensembles de données a entraîné des coûts de stockage BigQuery plus élevés.

La fonctionnalité temporelle de BigQuery conserve les données supprimées pendant la durée de la fenêtre temporelle configurée, ainsi que pendant sept jours supplémentaires pour la récupération en mode sécurité. Pendant cette période de conservation, les données supprimées dans les ensembles de données du modèle de facturation du stockage physique actif contribuent au coût du stockage physique actif, même si les tables n'apparaissent plus dans INFORMATION_SCHEMA.TABLE_STORAGE ni dans la console. Si les données de la table se trouvaient dans un stockage à long terme, la suppression les déplace vers un stockage physique actif. Le coût correspondant augmente, car les octets physiques actifs sont facturés environ deux fois plus cher que les octets physiques à long terme, comme indiqué sur la page Tarifs de stockage BigQuery. L'approche recommandée pour minimiser les coûts liés à la suppression de données pour les ensembles de données du modèle de facturation du stockage physique consiste à réduire la fenêtre de fonctionnalité temporelle à deux jours.

Réduction des coûts de stockage sans modification des données

Dans BigQuery, les utilisateurs paient le stockage actif et à long terme. Les frais de stockage actif incluent toutes les tables ou partitions de tables qui n'ont pas été modifiées pendant 90 jours consécutifs, tandis que les frais de stockage à long terme incluent les tables et les partitions qui n'ont pas été modifiées pendant 90 jours consécutifs. Vous pouvez constater une réduction globale des coûts de stockage lorsque les données sont transférées vers le stockage à long terme, qui est environ 50 % moins cher que le stockage actif. Pour en savoir plus, consultez les tarifs de stockage.

Les calculs de stockage INFORMATION_SCHEMA ne correspondent pas à la facturation

  • Utilisez la vue INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE au lieu de INFORMATION_SCHEMA.TABLE_STORAGE. TABLE_STORAGE_USAGE_TIMELINE fournit des données plus précises et plus détaillées pour calculer correctement les coûts de stockage.
  • Les requêtes exécutées sur les vues INFORMATION_SCHEMA n'incluent pas les taxes, les ajustements ni les erreurs d'arrondi. Tenez-en compte lorsque vous comparez les données. Pour en savoir plus sur les rapports dans Cloud Billing, consultez cette page.
  • Les données présentées dans les vues INFORMATION_SCHEMA sont en UTC, tandis que celles des rapports sur la facturation sont indiquées à l'heure du Pacifique des États-Unis et du Canada (UTC-8).

Étapes suivantes