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 dans le temps :
  • 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

Pour obtenir plus d'informations sur la création et l'utilisation de tables partitionnées, y compris pour savoir comment collecter des informations relatives aux tables, répertorier des tables et contrôler l'accès à leurs données, consultez la page Créer et utiliser des tables partitionnées par date d'ingestion ou la page Créer et utiliser des tables partitionnées.

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

Au minimum, pour mettre à jour les propriétés d'une table, vous devez disposer des autorisations bigquery.tables.update et bigquery.tables.get. Les rôles Cloud 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 des autorisations bigquery.datasets.create, lorsqu'il crée un ensemble de données, il obtient également le rôle bigquery.dataOwner qui lui permet d'y accéder. Un accès bigquery.dataOwner permet à l'utilisateur de mettre à jour les propriétés des tables dans l'ensemble de données.

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

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

Vous pouvez spécifier l'expiration de la partition pour une table partitionnée lorsque la table est créée grâce à l'une des méthodes suivantes :

  • En utilisant une instruction DDL ALTER TABLE
  • En utilisant la commande bq mk de l'outil de ligne de commande
  • En appelant la méthode d'API tables.insert
  • Utiliser les bibliothèques clientes

La spécification de la date d'expiration de la partition n'est actuellement pas possible dans la console GCP ou l'UI Web classique de BigQuery.

Si vous spécifiez une date d'expiration de partition lorsque vous créez une table, cette date d'expiration remplace la date d'expiration de la partition par défaut au niveau de l'ensemble de données. Lorsque vous définissez une date d'expiration de partition au niveau de la table, toutes les partitions sont soumises à cette date d'expiration. Vous ne pouvez pas appliquer différents délais d'expiration à des partitions individuelles.

À tout moment après la création de la table, vous pouvez mettre à jour la date d'expiration de la partition de la table à l'aide de la commande bq update de la CLI ou de la méthode d'API tables.patch. La mise à jour de la date d'expiration de la partition n'est actuellement pas possible dans la console GCP ni dans l'UI Web classique de BigQuery. Vous pouvez toutefois utiliser une instruction LDD dans les deux UI pour mettre à jour la date d'expiration de la partition.

Lorsque vous mettez à jour la date d'expiration de la partition d'une table, ce paramètre s'applique à toutes les partitions, quelle que soit leur date de création.

Lorsque vous mettez à jour le délai d'expiration de la partition d'une table, vous devez calculer la date d'expiration de la partition à partir de sa date de création à minuit (UTC).

Si une date d'expiration est déjà paramétrée pour la table, celle-ci ainsi que toutes les partitions qu'elle contient sont supprimées en fonction des paramètres d'expiration de la table. L'expiration de cette dernière a priorité sur l'expiration de la partition.

Par exemple, si la date d'expiration d'une table partitionnée est définie sur "5 jours" et que le délai d'expiration de la partition est configuré sur "7 jours", la table et toutes les partitions qu'elle contient sont supprimées au bout de cinq jours.

Pour les projets ayant des tables partitionnées créées avant le 13 décembre 2016, la date d'expiration de la partition est basée sur la dernière date de modification de la partition. Ce comportement s'applique également aux nouvelles tables créées dans ces projets. Pour migrer votre projet vers le 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 :

LDD

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 DDL :

  1. Ouvrez l'UI Web de BigQuery dans la console GCP.
    Accéder à la console GCP

  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 (Run).

CLI

Exécutez la commande bq update avec l'indicateur --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 au format suivant : project_id:dataset.

bq update \
--time_partitioning_expiration integer \
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, l'expiration de la partition est supprimée et la partition n'expire jamais. Les partitions sans date d'expiration doivent être supprimées manuellement.
  • project_id est l'ID du projet.
  • dataset est le nom de l'ensemble de données qui contient la table que vous mettez à jour.
  • table est le nom de la table que vous mettez à jour.

Exemples :

Saisissez la commande suivante pour mettre à jour le délai d'expiration des partitions dans mydataset.mytable à cinq jours (432 000 secondes). mydataset est dans votre projet par défaut.

bq update --time_partitioning_expiration 432000 mydataset.mytable

Exécutez la commande suivante pour mettre à jour la date d'expiration des partitions dans mydataset.mytable et la définir sur "5 jours (432 000 secondes)". mydataset est dans myotherproject, qui n'est pas votre projet par défaut.

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

API

Appelez la méthode tables.patch, puis mettez à jour le délai d'expiration de la partition (en millisecondes) à l'aide de la propriété timePartitioning.expirationMs. Étant donné que la méthode tables.update remplace l'intégralité de la ressource de table, il est préférable d'utiliser la méthode tables.patch.

Mettre à jour les exigences relatives au filtre de partitionnement

Lorsque vous créez une table partitionnée, vous pouvez demander l'utilisation de filtres de prédicat en activant l'option Demander un filtre de partitionnement. Lorsque cette option est appliquée, les tentatives d'interrogation de la table partitionnée sans spécifier de clause WHERE génèrent l'erreur suivante : "Cannot query over table 'project_id.dataset.table' without a filter that can be used for partition elimination" (Impossible d'interroger une table "project_id.dataset.table" sans un filtre permettant d'éliminer une partition).

Pour plus d'informations sur l'activation 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'activer 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 la console GCP pour exiger des filtres de partitionnement après la création d'une table partitionnée.

UI classique

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

CLI

Pour mettre à jour une table partitionnée afin d'exiger des filtres de partitionnement à l'aide de la CLI, entrez la commande bq update et fournissez l'indicateur --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, au format suivant : project_id:dataset.

Exemple :

Pour mettre à jour mypartitionedtable dans mydataset dans votre projet par défaut, entrez :

bq update --require_partition_filter mydataset.mytable

Pour mettre à jour mypartitionedtable dans mydataset dans myotherproject, entrez :

bq update --require_partition_filter myotherproject:mydataset.mytable

API

Appelez la méthode tables.patch et 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, il est préférable d'utiliser la méthode tables.patch.

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 dans le temps dans 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 à 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 ou écraser la table de destination.
  • 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 exploité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 :

  • Utilisez la commande bq cp de l'outil de ligne de commande
  • Appeler la méthode d'API jobs.insert et configurer une tâche copy
  • Utiliser les bibliothèques clientes

Actuellement, la copie de partitions n'est possible ni dans la console GCP ni dans l'UI Web classique de BigQuery.

Autorisations requises

Au minimum, pour copier des tables et des partitions, vous devez disposer des autorisations suivantes.

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 Cloud IAM prédéfinis suivants incluent des 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.

Vous trouverez ci-dessous les rôles Cloud IAM prédéfinis qui incluent les autorisations bigquery.jobs.create :

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

En outre, si un utilisateur possède des autorisations bigquery.datasets.create, lorsqu'il crée un ensemble de données, il obtient également le rôle bigquery.dataOwner qui lui permet d'y accéder. L'accès bigquery.dataOwner donne à l'utilisateur la possibilité 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 Cloud IAM dans BigQuery, consultez la page Contrôle des accès.

Copier une seule partition

Console

La copie de partitions n'est pas possible dans la console GCP.

UI classique

La copie de partitions n'est pas possible dans l'UI Web classique de BigQuery.

CLI

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

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

  • -a ou --append_table permet d'ajouter les données de la partition source à une table ou une partition existante dans 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 dans l'ensemble de données de destination : Table 'project_id:dataset.table or table$date' already exists, skipping. Si If 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 qui est gérée par le client et permet de chiffrer la partition ou la table de destination.

La commande cp ne fonctionne pas avec les paramètres --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. Consultez la page Protéger des données avec des clés Cloud KMS pour plus d'informations.

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'indicateur --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 de votre emplacement. L'indicateur --location est facultatif. Par exemple, si vous utilisez BigQuery dans la région de Tokyo, définissez la valeur du paramètre 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 du 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 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 la partition de destination.

Exemples :

Copier une partition dans une nouvelle table

Saisissez la commande suivante pour copier la partition du 30 janvier 2018 à partir 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 à partir 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 à partir 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 à partir 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 sur la table de destination pour copier les données sur une partition spécifique. mydataset se trouve dans votre projet par défaut. mydataset2 se trouve dans myotherproject, qui n'est pas 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 à partir 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 est dans myotherproject, mais pas 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 à partir 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, qui n'est pas 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, puis configurez une tâche 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 :

  • Saisissez l'ensemble de données, la table et la partition sources dans la propriété sourceTables.
  • Saisissez l'ensemble de données et la table de destination dans la propriété destinationTable.
  • Indiquez si la table ou la partition de destination doit être ajoutée ou écrasée à l'aide de la propriété writeDisposition.

Copier plusieurs partitions

Pour copier plusieurs partitions, procédez comme suit :

Console

Actuellement, la copie de partitions n'est pas possible dans la console GCP.

UI classique

Actuellement, la copie de partitions n'est pas possible dans l'UI Web classique de BigQuery.

CLI

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, puis configurez une tâche 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 (avec le nom de l'ensemble de données et de la table) dans la propriété sourceTables.
  • Saisissez l'ensemble de données et la table de destination dans la propriété destinationTable.
  • Indiquez si la table ou la partition de destination doit être ajoutée ou écrasée à l'aide de la propriété writeDisposition.

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 des tables partitionnées à l'aide de la commande bq rm de l'outil de ligne de commande ou en appelant la méthode d'API tables.delete. La suppression de partitions n'est actuellement pas possible dans l'UI Web classique de BigQuery.

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'

Pour récupérer la liste des partitions d'une table partitionnée, consultez la section Répertorier des partitions dans des tables partitionnées par temps d'ingestion ou Répertorier des partitions dans des tables partitionnées.

Actuellement, 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 Cloud IAM prédéfinis suivants incluent des autorisations bigquery.tables.delete et bigquery.tables.get :

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

En outre, si un utilisateur possède des autorisations bigquery.datasets.create, lorsqu'il crée un ensemble de données, il obtient également le rôle bigquery.dataOwner qui lui permet d'y accéder. L'accès bigquery.dataOwner donne à l'utilisateur la possibilité de supprimer des tables et des partitions dans l'ensemble de données.

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

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 la console GCP.

UI classique

La suppression de partitions n'est pas possible dans l'UI Web classique de BigQuery.

CLI

Exécutez la commande bq rm avec l'indicateur --table (ou le raccourci -t), puis référencez le décorateur de partition ($date) pour supprimer une partition spécifique dans une table partitionnée. Lorsque vous supprimez une partition à l'aide de la CLI, vous devez confirmer l'opération. L'indicateur --force (ou le raccourci -f) vous permet d'ignorer cette étape.

Si la table partitionnée se trouve dans un ensemble de données d'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 rm -f -t project_id:dataset.table$date

Où :

  • project_id est l'ID du projet.
  • dataset est le nom de l'ensemble de données contenant la table.
  • table est le nom de la table.
  • $date est le décorateur de la partition que vous supprimez.

Exemples :

Saisissez la commande suivante pour supprimer la partition du 1er mars 2016 ($20160301) dans une table partitionnée nommée mydataset.mytable. mydataset est dans votre projet par défaut.

bq rm 'mydataset.mytable$20160301'

Exécutez la commande suivante pour supprimer la partition du 1er janvier 2017 ($20170101) dans une table partitionnée nommée mydataset.mytable. mydataset est dans myotherproject, mais pas dans votre projet par défaut.

bq rm 'myotherproject:mydataset.mytable$20170101'

Saisissez la commande suivante pour supprimer la partition du 18 janvier 2018 ($20180118) dans une table partitionnée nommée mydataset.mytable. mydataset est dans myotherproject, mais pas dans votre projet par défaut. Le raccourci -f vous permet de passer l'étape de confirmation.

bq rm -f 'myotherproject:mydataset.mytable$20180118'

API

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

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

Envoyer des commentaires concernant…

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