Gérer des tables partitionnées

Vous trouverez dans ce document la procédure à suivre pour gérer les tables partitionnées dans BigQuery. Les tables partitionnées et les tables partitionnées par temps d'ingestion sont gérées de la même manière. Vous pouvez effectuer les tâches de gestion suivantes pour les tables partitionnées :

  • Mettre à jour une table partitionnée par date d'ingestion :
    • Description
    • Date d'expiration de la table
    • Date d'expiration de la partition
    • Exigences relatives au filtre de partitionnement
    • Définition du schéma
    • Libellés
  • Renommer (copier) une table partitionnée dans le temps
  • Copier une table partitionnée dans le temps
  • Copier des partitions
  • Supprimer une table partitionnée dans le temps
  • Supprimer des partitions dans une table partitionnée dans le temps

Obtenir des métadonnées de partitions

Vous pouvez obtenir des informations sur les tables partitionnées de différentes manières :

Obtenir des métadonnées de partitions à l'aide des vues INFORMATION_SCHEMA

Lorsque vous interrogez la vue INFORMATION_SCHEMA.PARTITIONS, les résultats de la requête contiennent une ligne pour chaque partition. Par exemple, la requête suivante répertorie toutes les partitions de la table dans l'ensemble de données nommé mydataset :

SELECT table_name, partition_id, total_rows
FROM `mydataset.INFORMATION_SCHEMA.PARTITIONS`
WHERE partition_id IS NOT NULL

Pour en savoir plus, consultez INFORMATION_SCHEMA.PARTITIONS.

Obtenir des métadonnées de partitions avec des métatables

En ancien SQL, vous pouvez obtenir les métadonnées des partitions de tables en interrogeant la métatable __PARTITIONS_SUMMARY__. Les métatables sont des tables en lecture seule contenant des métadonnées.

Interrogez la métatable __PARTITIONS_SUMMARY__ comme suit :

#legacySQL
SELECT
  column
FROM
  [dataset.table$__PARTITIONS_SUMMARY__]

La métatable __PARTITIONS_SUMMARY__ contient les colonnes suivantes :

Valeur Description
project_id Nom du projet.
dataset_id Nom de l'ensemble de données.
table_id Nom de la table partitionnée par date.
partition_id Nom (date) de la partition.
creation_time Heure à laquelle la partition a été créée, exprimée en millisecondes depuis le 1er janvier 1970 UTC.
last_modified_time Heure à laquelle la partition a été modifiée pour la dernière fois, exprimée en millisecondes depuis le 1er janvier 1970 UTC.

Pour exécuter une tâche de requête qui utilise la métatable __PARTITIONS_SUMMARY__, vous devez au minimum disposer des autorisations bigquery.jobs.create et bigquery.tables.getData.

Pour en savoir plus sur les rôles IAM dans BigQuery, consultez la page Contrôle des accès.

Mettre à jour les propriétés des tables partitionnées

Vous pouvez mettre à jour les éléments suivants d'une table partitionnée :

  • Description
  • Date d'expiration de la table
  • Date d'expiration de la partition
  • Définition du schéma
  • Étiquettes

Autorisations requises

Pour mettre à jour les propriétés d'une table, vous devez au minimum disposer des autorisations bigquery.tables.update et bigquery.tables.get. Les rôles IAM prédéfinis suivants incluent les autorisations bigquery.tables.update et bigquery.tables.get :

  • bigquery.dataEditor
  • bigquery.dataOwner
  • bigquery.admin

En outre, si un utilisateur possède les autorisations bigquery.datasets.create, il obtient également un accès bigquery.dataOwner à l'ensemble de données qu'il crée. L'accès bigquery.dataOwner permet à l'utilisateur de mettre à jour les propriétés des tables dans cet ensemble de données.

Pour en savoir plus sur les rôles et les autorisations IAM dans BigQuery, consultez la page Rôles prédéfinis et autorisations.

Mettre à jour la description d'une table partitionnée

Le processus de mise à jour de la description d'une table partitionnée est identique à la procédure à suivre pour mettre à jour la description d'une table standard. Pour plus d'informations sur l'ajout ou la modification de la description d'une table, consultez la section Mettre à jour la description d'une table.

Actuellement, vous ne pouvez pas créer de descriptions pour des partitions individuelles.

Mettre à jour la date d'expiration d'une table

Le processus de mise à jour de la date d'expiration d'une table partitionnée est identique à la procédure à suivre pour mettre à jour la date d'expiration d'une table standard. Pour plus d'informations sur l'ajout ou la modification de la date d'expiration d'une table, consultez la section Mettre à jour la date d'expiration d'une table.

Mettre à jour la date d'expiration de la partition

Lorsque vous créez une table partitionnée par date d'ingestion ou par colonne de date/d'horodatage, vous pouvez spécifier une date d'expiration de partition. Ce paramètre spécifie la durée pendant laquelle BigQuery conserve les données dans chaque partition. Ce paramètre s'applique à toutes les partitions de la table. Lorsqu'une partition expire, BigQuery supprime les données qu'elle contient.

Le délai d'expiration d'une partition est calculé à partir de la limite de partition au format UTC. Par exemple, avec le partitionnement quotidien, la limite de partition est à minuit (00:00:00 UTC). Si le délai d'expiration de partition de la table est de six heures, chaque partition expire à 06:00:00 UTC le lendemain.

Vous pouvez également spécifier un délai d'expiration de partition par défaut au niveau de l'ensemble de données. Si vous définissez le délai d'expiration de partition sur une table, la valeur remplace le délai d'expiration de partition par défaut. Si vous ne spécifiez aucun délai d'expiration de partition (sur la table ou l'ensemble de données), les partitions n'expirent jamais.

Si vous définissez un délai d'expiration de table, cette valeur est prioritaire sur le délai d'expiration de partition. Par exemple, si le délai d'expiration de table est défini sur cinq jours et que le délai d'expiration de partition est de sept jours, la table et toutes les partitions qu'elle contient sont supprimées au bout de cinq jours.

À tout moment après la création d'une table, vous pouvez mettre à jour le délai d'expiration de partition de la table. Le nouveau paramètre s'applique à toutes les partitions de la table, quelle que soit leur date de création. Les partitions existantes expirent immédiatement si elles sont antérieures au nouveau délai d'expiration.

Lorsqu'une partition expire, les données de cette partition ne sont plus disponibles pour l'interrogation, et le stockage de cette partition n'est pas facturé. BigQuery supprime finalement la partition arrivée à expiration. Jusqu'à cette date, la partition est comptabilisée dans le cadre des quotas de table. Pour supprimer une partition immédiatement, vous pouvez la supprimer manuellement.

Pour les projets créés avant le 13 décembre 2016, le délai d'expiration de partition est basé sur la dernière date de modification de la partition. Ce comportement s'applique à la fois aux tables existantes et aux nouvelles tables créées dans le projet. Pour que votre projet adopte ce nouveau comportement, ouvrez une requête dans l'outil de suivi des problèmes de BigQuery.

Pour mettre à jour la date d'expiration de la partition d'une table partitionnée, procédez comme suit :

Console

Vous ne pouvez pas mettre à jour le délai d'expiration de partition dans Cloud Console.

SQL

Les instructions LDD (langage de définition de données) vous permettent de créer et de modifier des tables et des vues à l'aide de la syntaxe de requête SQL standard.

En savoir plus sur l'utilisation des instructions de langage de définition de données

Pour mettre à jour la date d'expiration de la partition d'une table partitionnée à l'aide d'une instruction LDD :

  1. Dans Cloud Console, ouvrez la page "BigQuery".

    Accéder à BigQuery

  2. Cliquez sur Saisir une nouvelle requête.

  3. Saisissez votre instruction LDD dans la zone de texte de l'éditeur de requête.

     ALTER TABLE mydataset.mytable
     SET OPTIONS (
       -- Sets partition expiration to 5 days
       partition_expiration_days=5
     )
     

  4. Cliquez sur Exécuter.

bq

Exécutez la commande bq update avec l'option --time_partitioning_expiration. Si vous mettez à jour une table partitionnée dans un projet autre que votre projet par défaut, ajoutez l'ID du projet au nom de l'ensemble de données, en respectant le format suivant : project_id:dataset.

bq update \
--time_partitioning_expiration integer \
--time_partitioning_type unit_time \
project_id:dataset.table

Où :

  • integer est la durée de vie par défaut (en secondes) des partitions de la table. Il n'y a pas de valeur minimale. Le délai d'expiration correspond à la date de la partition plus la valeur entière. Si vous spécifiez 0, le délai d'expiration de la partition est supprimé et la partition n'expire jamais. Les partitions sans date d'expiration doivent être supprimées manuellement.
  • Le valeur de unit_time est DAY, HOUR, MONTH ou YEAR, en fonction de la précision de partitionnement de la table. Cette valeur doit correspondre à la précision que vous avez définie lors de la création de la table.
  • project_id est l'ID de votre projet.
  • dataset est le nom de l'ensemble de données contenant la table que vous mettez à jour.
  • table est le nom de la table que vous mettez à jour.

Exemples :

Saisissez la commande suivante pour faire passer le délai d'expiration des partitions dans mydataset.mytable à cinq jours (432 000 secondes). mydataset se trouve dans le projet par défaut.

bq update --time_partitioning_expiration 432000 mydataset.mytable

Saisissez la commande suivante pour faire passer le délai d'expiration des partitions dans mydataset.mytable à cinq jours (432 000 secondes). mydataset se trouve dans myotherproject, et non dans votre projet par défaut.

bq update \
--time_partitioning_expiration 432000 \
myotherproject:mydataset.mytable

API

Appelez la méthode tables.patch, puis utilisez la propriété timePartitioning.expirationMs pour mettre à jour le délai d'expiration de partition, exprimé en millisecondes. Étant donné que la méthode tables.update remplace l'intégralité de la ressource de table, la méthode tables.patch est à privilégier.

Mettre à jour les exigences relatives au filtre de partitionnement

Lorsque vous créez une table partitionnée, vous pouvez demander l'utilisation de filtres en activant l'option Demander un filtre de partition. Lorsque cette option est appliquée, toute tentative d'interrogation de la table partitionnée sans spécifier de clause WHERE génère l'erreur suivante : Cannot query over table 'project_id.dataset.table' without a filter that can be used for partition elimination.

Pour plus d'informations sur l'ajout de l'option Demander un filtre de partitionnement lors de la création d'une table partitionnée, consultez la section Créer des tables partitionnées.

Si vous n'activez pas l'option Demander un filtre de partitionnement lorsque vous créez une table partitionnée, vous pouvez mettre à jour la table afin d'ajouter cette option.

Mettre à jour l'option "Demander un filtre de partitionnement"

Pour mettre à jour une table partitionnée afin d'exiger des requêtes contenant une clause WHERE qui élimine des partitions :

Console

Vous ne pouvez pas utiliser Cloud Console pour exiger des filtres de partitionnement après la création d'une table partitionnée.

bq

Pour mettre à jour une table partitionnée afin d'exiger des filtres de partitionnement à l'aide de l'outil de ligne de commande bq, exécutez la commande bq update avec l'option --require_partition_filter.

Pour mettre à jour une table partitionnée dans un projet autre que votre projet par défaut, ajoutez l'ID du projet à l'ensemble de données, en respectant le format suivant : project_id:dataset.

Exemple :

Pour mettre à jour mypartitionedtable dans l'ensemble de données mydataset de votre projet par défaut, saisissez :

bq update --require_partition_filter mydataset.mytable

Pour mettre à jour mypartitionedtable dans l'ensemble de données mydataset de myotherproject, saisissez :

bq update --require_partition_filter myotherproject:mydataset.mytable

API

Appelez la méthode tables.patch, puis définissez la propriété requirePartitionFilter sur true pour exiger des filtres de partitionnement. Étant donné que la méthode tables.update remplace l'intégralité de la ressource de table, la méthode tables.patch est à privilégier.

Java

Avant d'essayer l'exemple ci-dessous, suivez la procédure de configuration pour Java décrite dans le 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 en langage Java.

import com.google.cloud.bigquery.BigQuery;
import com.google.cloud.bigquery.BigQueryException;
import com.google.cloud.bigquery.BigQueryOptions;
import com.google.cloud.bigquery.Table;

// Sample to update require partition filter on a table.
public class UpdateTableRequirePartitionFilter {

  public static void runUpdateTableRequirePartitionFilter() {
    // TODO(developer): Replace these variables before running the sample.
    String datasetName = "MY_DATASET_NAME";
    String tableName = "MY_TABLE_NAME";
    updateTableRequirePartitionFilter(datasetName, tableName);
  }

  public static void updateTableRequirePartitionFilter(String datasetName, String tableName) {
    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();

      Table table = bigquery.getTable(datasetName, tableName);
      table.toBuilder().setRequirePartitionFilter(true).build().update();

      System.out.println("Table require partition filter updated successfully");
    } catch (BigQueryException e) {
      System.out.println("Table require partition filter was not updated \n" + e.toString());
    }
  }
}

Mettre à jour la définition du schéma

Le processus de mise à jour de la définition du schéma d'une table partitionnée est identique à la procédure à suivre pour mettre à jour la définition du schéma d'une table standard. Pour en savoir plus, consultez la page Modifier des schémas de table.

Renommer une table partitionnée

Actuellement, vous ne pouvez pas modifier le nom d'une table partitionnée existante. Si vous devez modifier le nom de la table, suivez les étapes pour copier la table. Lorsque vous spécifiez la table de destination dans l'opération de copie, utilisez le nouveau nom de la table.

Copier des tables partitionnées

Copier une seule table partitionnée

Le processus de copie d'une table partitionnée est identique à la procédure à suivre pour copier une table standard. Pour plus d'informations, consultez la section Copier une table.

Lorsque vous copiez une table partitionnée, prenez en compte les points suivants :

  • Les tables sources et de destination doivent figurer dans des ensembles de données situés dans la même zone.

  • Copier une table partitionnée dans une nouvelle table de destination partitionnée
    Si vous copiez une table partitionnée par date d'ingestion vers une nouvelle table, toutes les informations de partitionnement sont copiées avec la table. La nouvelle table et l'ancienne table auront des partitions identiques.
  • Copier une table non partitionnée dans une table partitionnée
    Si vous copiez une table non partitionnée dans une table partitionnée, BigQuery copie les données sources dans la partition correspondant à la date actuelle.
  • Copier une table partitionnée dans une autre table partitionnée
    Pour copier une table partitionnée dans une autre table partitionnée, les spécifications de partition pour les tables sources et de destination doivent correspondre. Vous pouvez spécifier si vous souhaitez ajouter des données dans la table de destination ou écraser son contenu.
  • Copier une table partitionnée dans une table non partitionnée
    Si vous copiez une table partitionnée dans une table non partitionnée, la table de destination reste non partitionnée. Les données sont soit ajoutées à la table non partitionnée, soit utilisées pour écraser la table non partitionnée, en fonction de vos paramètres.

Copier plusieurs tables partitionnées

Le processus de copie de plusieurs tables partitionnées est identique à la procédure à suivre pour copier plusieurs tables standards. Pour plus d'informations, consultez la section Copier plusieurs tables sources.

Lorsque vous copiez plusieurs tables partitionnées, prenez en compte les points suivants :

  • Si vous copiez plusieurs tables sources dans une table partitionnée lors de la même tâche, les tables sources ne peuvent pas contenir à la fois des tables partitionnées et non partitionnées.
  • Si toutes les tables sources sont des tables partitionnées, leurs spécifications de partition doivent correspondre à la spécification de partition de la table de destination. Vos paramètres déterminent si la table de destination est ajoutée ou écrasée.
  • Les tables sources et de destination doivent figurer dans des ensembles de données situés dans la même zone.

Copier des partitions

Vous pouvez copier une ou plusieurs partitions en effectuant les actions suivantes :

  • Exécuter la commande bq cp de l'outil de ligne de commande bq
  • En appelant la méthode API jobs.insert et en configurant une tâche de copie (copy)
  • Utiliser les bibliothèques clientes

Actuellement, la copie de partitions n'est pas possible dans Cloud Console.

Autorisations requises

Pour copier des tables et des partitions, vous devez au minimum disposer des autorisations ci-dessous.

Sur l'ensemble de données source :

  • bigquery.tables.get
  • bigquery.tables.getData

Sur l'ensemble de données de destination :

  • bigquery.tables.create pour créer la copie de la table ou de la partition dans l'ensemble de données de destination

Les rôles IAM prédéfinis suivants incluent les autorisations bigquery.tables.create, bigquery.tables.get et bigquery.tables.getData :

  • bigquery.dataEditor
  • bigquery.dataOwner
  • bigquery.admin

En outre, pour exécuter la tâche de copie, vous devez disposer des autorisations bigquery.jobs.create.

Les rôles IAM prédéfinis suivants incluent les autorisations bigquery.jobs.create :

  • bigquery.user
  • bigquery.jobUser
  • bigquery.admin

En outre, si un utilisateur possède les autorisations bigquery.datasets.create, il obtient également un accès bigquery.dataOwner à l'ensemble de données qu'il crée. L'accès bigquery.dataOwner permet à l'utilisateur de copier des tables et des partitions dans l'ensemble de données, mais l'accès à l'ensemble de données de destination est requis sauf si l'utilisateur l'a également créé.

Pour en savoir plus sur les rôles et les autorisations IAM dans BigQuery, consultez la page Rôles prédéfinis et autorisations.

Copier une seule partition

Console

La copie de partitions n'est pas possible dans Cloud Console.

bq

Pour copier une partition, exécutez la commande bq cp (copier) de l'outil de ligne de commande bq avec un décorateur de partition ($date), par exemple $20160201.

Les paramètres facultatifs peuvent servir à contrôler la disposition en écriture de la partition de destination :

  • -a ou --append_table ajoute les données de la partition source à une table ou une partition existante de l'ensemble de données de destination.
  • -f ou --force écrase une table ou une partition existante dans l'ensemble de données de destination, et ne demande pas de confirmation.
  • -n ou --no_clobber renvoie le message d'erreur suivant si la table ou la partition existe déjà dans l'ensemble de données de destination : Table '<var>project_id:dataset.table</var> or <var>table$date</var>' already exists, skipping. Si -n n'est pas spécifié, le comportement par défaut consiste à vous demander de choisir de remplacer la table ou la partition de destination.
  • --destination_kms_key est la clé Cloud KMS gérée par le client et utilisée pour chiffrer la partition ou la table de destination.

La commande cp ne fonctionne pas avec les options --time_partitioning_field ou --time_partitioning_type. Sachez également qu'une tâche de copie ne permet pas de convertir une table partitionnée par temps d'ingestion en table partitionnée.

--destination_kms_key n'est pas présenté ici. Pour en savoir plus, consultez la page Protéger des données avec des clés Cloud KMS.

Si l'ensemble de données source ou de destination se trouve dans un projet autre que votre projet par défaut, ajoutez l'ID du projet aux noms des ensembles de données en respectant le format suivant : project_id:dataset.

(Facultatif) Spécifiez l'option --location et définissez la valeur correspondant à votre emplacement.

bq --location=location cp \
-a -f -n \
project_id:dataset.source_table$source_partition \
project_id:dataset.destination_table$destination_partition

Où :

  • location est le nom du site. L'option --location est facultative. Par exemple, si vous utilisez BigQuery dans la région de Tokyo, vous pouvez définir la valeur de l'option sur asia-northeast1. Vous pouvez définir une valeur par défaut correspondant à l'emplacement en utilisant le fichier .bigqueryrc.
  • project_id est l'ID de votre projet.
  • dataset est le nom de l'ensemble de données source ou de destination.
  • source_table est la table que vous copiez.
  • source_partition est le décorateur de partition de la partition source.
  • destination_table est le nom de la table dans l'ensemble de données de destination.
  • destination_partition est le décorateur de partition dans la partition de destination.

Exemples :

Copier une partition dans une nouvelle table

Saisissez la commande suivante pour copier la partition du 30 janvier 2018 de mydataset.mytable vers une nouvelle table (mydataset.mytable2). mydataset se trouve dans votre projet par défaut.

bq cp -a 'mydataset.mytable$20180130' mydataset.mytable2

Copier une partition dans une table non partitionnée

Saisissez la commande suivante pour copier la partition du 30 janvier 2018 de mydataset.mytable vers une table non partitionnée (mydataset2.mytable2). Le raccourci -a permet d'ajouter les données de la partition à la table de destination non partitionnée. Les deux ensembles de données sont dans votre projet par défaut.

bq cp -a 'mydataset.mytable$20180130' mydataset2.mytable2

Saisissez la commande suivante pour copier la partition du 30 janvier 2018 de mydataset.mytable vers une table non partitionnée (mydataset2.mytable2). Le raccourci -f permet d'écraser la table de destination non partitionnée sans avoir recours à une invite.

bq --location=US cp -f 'mydataset.mytable$20180130' mydataset2.mytable2

Copier une partition dans une autre table partitionnée

Saisissez la commande suivante pour copier la partition du 30 janvier 2018 de mydataset.mytable vers une autre table partitionnée (mydataset2.mytable2). Le raccourci -a permet d'ajouter les données de la partition à la table de destination. Comme aucun décorateur de partition n'est spécifié dans la table de destination, la clé de la partition source est conservée et les données sont copiées dans la partition du 30 janvier 2018 de la table de destination. Vous pouvez également spécifier un décorateur de partition dans la table de destination pour copier les données vers une partition spécifique. mydataset se trouve dans votre projet par défaut. mydataset2 se trouve dans myotherproject, et non dans votre projet par défaut.

bq --location=US cp \
-a \
'mydataset.mytable$20180130' \
myotherproject:mydataset2.mytable2

Saisissez la commande suivante pour copier la partition du 30 janvier 2018 de mydataset.mytable vers la partition du 20 février 2018 d'une autre table partitionnée (mydataset2.mytable2). Le raccourci -f permet d'écraser la partition du 20 février 2018 dans la table de destination sans avoir recours à une invite. Si aucun décorateur de partition n'est utilisé, toutes les données de la table de destination sont écrasées. mydataset se trouve dans votre projet par défaut. mydataset2 se trouve dans myotherproject, et non dans votre projet par défaut.

bq cp \
-f \
'mydataset.mytable$20180130' \
'myotherproject:mydataset2.mytable2$20180220'

Saisissez la commande suivante pour copier la partition du 30 janvier 2018 de mydataset.mytable vers une autre table partitionnée (mydataset2.mytable2). mydataset se trouve dans votre projet par défaut. mydataset2 se trouve dans myotherproject, et non dans votre projet par défaut. Si la table de destination contient des données, le comportement par défaut consiste à vous demander de les écraser.

bq cp \
'mydataset.mytable$20180130' \
myotherproject:mydataset2.mytable2

API

Appelez la méthode jobs.insert et configurez une tâche de copie (copy). (Facultatif) Spécifiez votre région dans la propriété location de la section jobReference de la ressource de tâche.

Spécifiez les propriétés suivantes dans la configuration de votre tâche :

  • Indiquez la partition, la table et l'ensemble de données sources dans la propriété sourceTables.
  • Indiquez la table et l'ensemble de données de destination dans la propriété destinationTable.
  • Avec la propriété writeDisposition, indiquez si les données doivent être ajoutées dans la table ou la partition de destination, ou bien si celle-ci doit être écrasée.

Copier plusieurs partitions

Pour copier plusieurs partitions, procédez comme suit :

Console

Actuellement, la copie de partitions n'est pas possible dans Cloud Console.

bq

Le processus de copie de plusieurs partitions est identique à la copie d'une seule partition, mais vous devez définir plusieurs partitions sources sous la forme d'une liste séparée par des virgules :

bq cp \
'mydataset.mytable$20180130,mydataset.mytable$20180131' \
myotherproject:mydataset.mytable2

API

Appelez la méthode jobs.insert et configurez une tâche de copie (copy). Spécifiez votre région dans la propriété location de la section jobReference de la ressource de tâche.

Spécifiez les propriétés suivantes dans la configuration de votre tâche :

  • Saisissez plusieurs partitions sources (y compris le nom de l'ensemble de données et de la table) dans la propriété sourceTables.
  • Indiquez la table et l'ensemble de données de destination dans la propriété destinationTable.
  • Avec la propriété writeDisposition, indiquez si les données doivent être ajoutées dans la table ou la partition de destination, ou bien si celle-ci doit être écrasée.

Supprimer une table partitionnée

Le processus de suppression d'une table partitionnée dans le temps et de toutes les partitions qu'elle contient est identique à la procédure à suivre pour supprimer une table standard. Pour plus d'informations sur la suppression d'une table, consultez la section Supprimer des tables.

Supprimer des partitions dans des tables partitionnées

Vous pouvez supprimer des partitions dans les tables partitionnées en exécutant la commande bq rm de l'outil de ligne de commande bq ou bien en appelant la méthode API tables.delete.

Vous pouvez supprimer une partition spécifique à l'aide du décorateur de partition. Par exemple, la partition du 1er mars 2016 ($20160301) dans une table partitionnée nommée mydataset.mytable peut être supprimée à l'aide de la commande suivante :

bq rm 'mydataset.mytable$20160301'

Vous ne pouvez supprimer qu'une partition à la fois.

Autorisations requises

Pour supprimer une partition, vous devez au minimum disposer des autorisations bigquery.tables.delete et bigquery.tables.get. Les rôles IAM prédéfinis suivants incluent les autorisations bigquery.tables.delete et bigquery.tables.get :

  • bigquery.dataOwner
  • bigquery.dataEditor
  • bigquery.admin

En outre, si un utilisateur possède les autorisations bigquery.datasets.create, il obtient également un accès bigquery.dataOwner à l'ensemble de données qu'il crée. L'accès bigquery.dataOwner permet à l'utilisateur de supprimer des tables et des partitions dans l'ensemble de données.

Pour en savoir plus sur les rôles et les autorisations IAM dans BigQuery, consultez la page Rôles prédéfinis et autorisations.

Supprimer une partition dans une table partitionnée

Vous pouvez supprimer une partition en spécifiant le décorateur de la partition, sauf s'il s'agit d'une des deux partitions spéciales. Actuellement, il n'est pas possible de supprimer les partitions __NULL__ ou __UNPARTITIONED__.

Pour supprimer une partition dans une table partitionnée, procédez comme suit :

Console

La suppression de partitions n'est pas possible dans Cloud Console.

bq

Exécutez la commande bq rm avec l'option --table (ou le raccourci -t), puis spécifiez le décorateur de partition pour supprimer une partition spécifique.

bq rm --table project_id:dataset.table$partition

Où :

  • project_id est l'ID de votre projet. S'il est omis, votre projet par défaut est utilisé.
  • dataset est le nom de l'ensemble de données contenant la table.
  • table est le nom de la table.
  • partition est le décorateur de partition de la partition que vous supprimez.

Les décorateurs de partition ont le format suivant, en fonction du type de partitionnement :

  • Partition horaire : yyyymmddhh. Exemple : $2016030100.
  • Partition quotidienne : yyyymmdd. Exemple : $20160301.
  • Partition mensuelle : yyyymm. Exemple : $201603.
  • Partition annuelle : yyyy. Exemple : $2016.
  • Partition par plages d'entiers : début de la plage de partition. Exemple : $20.

L'outil de ligne de commande bq vous invite à confirmer l'action. Pour ignorer la confirmation, utilisez l'option --force (ou le raccourci -f).

Par exemple :

Supprimez la partition du 1er mars 2016 dans une table partitionnée par jour nommée mydataset.mytable dans votre projet par défaut :

bq rm --table 'mydataset.mytable$20160301'

Supprimez la partition de mars 2016 dans une table partitionnée par mois :

bq rm --table 'mydataset.mytable$201603'

Supprimez la plage d'entiers commençant par 20 dans une table partitionnée par plages d'entiers nommée mydataset.mytable :

bq rm --table 'mydataset.mytable$20'

API

Appelez la méthode tables.delete, puis spécifiez le décorateur de table et de partition à l'aide du paramètre tableId.