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 :
    • Date d'expiration de la table
    • Date d'expiration de la partition
    • Description
    • 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

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 temps d'ingestion ou 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 :

Autorisations requises

Pour mettre à jour les propriétés de la table, vous devez disposer d'un accès WRITER au niveau de l'ensemble de données ou bénéficier d'un rôle IAM au niveau du projet avec l'autorisation bigquery.tables.update. Voici les rôles IAM prédéfinis au niveau du projet qui incluent les autorisations bigquery.tables.update :

De plus, comme le rôle bigquery.user dispose des autorisations bigquery.datasets.create, tout utilisateur bénéficiant du rôle de bigquery.user peut mettre à jour n'importe quelle table créée par un utilisateur dans l'ensemble de données. Lorsqu'un utilisateur ayant le rôle bigquery.user crée un ensemble de données, il bénéficie d'un accès OWNER à cet ensemble de données. L'accès OWNER à un ensemble de données permet à l'utilisateur de contrôler entièrement celui-ci ainsi que toutes les tables et vues qu'il contient.

Pour en savoir plus sur les rôles et les autorisations 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 la date d'expiration de la partition d'une table partitionnée lorsque la table est créée à l'aide de l'outil de ligne de commande bq mk ou en appelant la méthode API tables.insert. La spécification de l'expiration de la partition n'est actuellement pas possible dans l'UI Web de BigQuery.

Si vous définissez une date d'expiration de partition lorsque vous créez une table, toutes les partitions sont soumises à cette date. 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 CLI bq update ou de la méthode API tables.patch. La mise à jour de la date d'expiration de la partition n'est actuellement pas possible dans l'UI Web de BigQuery.

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 sa date d'expiration en fonction de la date de création de la partition. Par exemple, si la date de la partition est le 3 janvier 2018 et que vous définissez le délai d'expiration de la partition sur "5 jours", la partition expire le 8 janvier 2018, quelle que soit la dernière date de mise à jour.

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 :

UI Web

Vous ne pouvez pas ajouter ni mettre à jour une date d'expiration de partition à l'aide de l'UI Web de BigQuery.

Ligne de commande

Exécutez la commande bq update avec le paramètre --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. Aucune valeur minimale n'est requise. Le délai d'expiration correspond à la date de la partition plus la valeur entière. Si vous définissez 0 ou un nombre négatif, l'expiration de la date 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 de votre projet.
  • [DATASET] correspond au 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 mettre à jour la date d'expiration des partitions dans mydataset.mytable et la définir sur "5 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 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 plus d'informations, 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 source 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 source 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 à l'aide de la commande bq cp dans l'outil de ligne de commande, ou en appelant la méthode API jobs.insert et en configurant une tâche de copie. Actuellement, il n'est pas possible de copier des partitions dans l'UI Web de BigQuery.

Autorisations requises

Au niveau de l'ensemble de données, la copie des partitions nécessite l'accès READER à l'ensemble de données source qui contient les partitions copiées et l'accès WRITER à l'ensemble de données de destination.

Au lieu d'utiliser des autorisations au niveau des ensembles de données, vous pouvez tirer parti d'un rôle IAM au niveau du projet qui inclut les autorisations bigquery.tables.create et bigquery.tables.getData. Pour créer la copie de la partition dans l'ensemble de données de destination (si la table de destination est nouvelle), l'autorisation bigquery.tables.create est requise. Pour lire les données dans les partitions à copier, l'autorisation bigquery.tables.getData est nécessaire.

Voici les rôles IAM prédéfinis au niveau du projet qui incluent les autorisations bigquery.tables.create et bigquery.tables.getData pour chaque ensemble de données du projet :

Vous devez également obtenir l'autorisation bigquery.jobs.create pour exécuter des tâches de copie. Vous trouverez ci-dessous les rôles IAM prédéfinis au niveau du projet qui incluent les autorisations bigquery.jobs.create :

De plus, étant donné que le rôle bigquery.user dispose des autorisations bigquery.datasets.create, un utilisateur bénéficiant du rôle bigquery.user peut lire ou copier les données de toute table ou partition qu'il a créée. Lorsqu'un utilisateur ayant le rôle bigquery.user crée un ensemble de données, il bénéficie d'un accès OWNER à cet ensemble de données. L'accès OWNER à un ensemble de données permet à l'utilisateur de contrôler entièrement celui-ci ainsi que toutes les tables et partitions qu'il contient.

Pour en savoir plus sur les rôles et les autorisations IAM dans BigQuery, consultez la page Contrôle des accès. Si vous souhaitez obtenir davantage d'informations sur les rôles au niveau des ensembles de données, consultez la section Rôles primitifs pour les ensembles de données.

Copier une seule partition

UI Web

Copier des partitions n'est pas possible dans l'UI Web de BigQuery.

Ligne de commande

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 renvoient le message d'erreur suivant si la table ou la partition existe déjà dans l'ensemble de données de destination : Table '[PROJECT_ID]:[DATASET].[TABLE] or [TABLE]$[DATE]' 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 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].

Incluez le paramètre --location, puis définissez la valeur correspondant à votre zone.

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 zone. Le paramètre --location est facultatif si vos données se situent dans la zone multirégionale US ou EU. Par exemple, si vous utilisez BigQuery dans la région de Tokyo, définissez la valeur du paramètre sur asia-northeast1. Vous pouvez spécifier une valeur par défaut pour votre zone à l'aide du 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 est dans votre projet par défaut. mydataset a été créé dans la zone multirégionale US.

bq --location=US 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. Ils ont été créés dans la région asia-northeast1.

bq --location=asia-northeast1 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. Les deux ensembles de données sont dans votre projet par défaut et ont été créés dans la zone multirégionale US.

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 ajouter un décorateur de partition dans la table de destination pour copier les données dans une partition spécifique. mydataset est dans votre projet par défaut. mydataset2 est dans myotherproject, mais pas dans votre projet par défaut. Les deux ensembles de données ont été créés dans la zone multirégionale US.

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 est dans votre projet par défaut. mydataset2 est dans myotherproject, mais pas dans votre projet par défaut. Les deux ensembles de données ont été créés dans la zone multirégionale US.

bq --location=US 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 est dans votre projet par défaut. mydataset2 est dans myotherproject, mais pas 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. Les deux ensembles de données ont été créés dans la région asia-northeast1.

bq --location=asia-northeast1 cp 'mydataset.mytable$20180130' myotherproject:mydataset2.mytable2

API

Appelez la méthode jobs.insert, puis configurez une tâche de copie. Indiquez votre région dans la propriété location de la section jobReference de la ressource job.

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é sourceTable.
  • Saisissez l'ensemble de données et la table de destination dans la propriété destinationTable.
  • Servez-vous de la propriété writeDisposition pour spécifier si la table ou la partition de destination doit être ajoutée ou écrasée.

Copier plusieurs partitions

Pour copier plusieurs partitions, procédez comme suit :

UI Web

Actuellement, il n'est pas possible de copier des partitions dans l'UI Web de BigQuery.

Ligne de commande

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

bq --location=[LOCATION] cp 'mydataset.mytable$20180130,mydataset.mytable$20180131' myotherproject:mydataset.mytable2

API

Appelez la méthode jobs.insert, puis configurez une tâche de copie. Indiquez votre région dans la propriété location de la section jobReference de la ressource job.

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.
  • Saisissez l'ensemble de données et la table de destination dans la propriété destinationTable.
  • Servez-vous de la propriété writeDisposition pour spécifier si la table ou la partition de destination doit être ajoutée ou é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 des tables partitionnées à l'aide de la commande bq rm dans l'outil de ligne de commande ou en appelant la méthode API tables.delete. La suppression de partitions n'est actuellement pas possible dans l'UI Web 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 une liste de partitions dans 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 disposer d'un accès OWNER au niveau de l'ensemble de données, ou avoir un rôle IAM au niveau du projet avec les autorisations bigquery.tables.delete. Voici les rôles IAM prédéfinis au niveau du projet qui incluent les autorisations bigquery.tables.delete :

Les utilisateurs auxquels sont attribués des rôles prédéfinis au niveau du projet peuvent supprimer des partitions dans n'importe quelle table partitionnée du projet. Les utilisateurs avec une autorisation OWNER au niveau de l'ensemble de données peuvent supprimer des partitions uniquement dans les tables de cet ensemble de données.

En outre, parce que le rôle bigquery.user dispose de l'autorisation bigquery.datasets.create, un utilisateur bénéficiant du rôle bigquery.user peut supprimer des tables et des partitions dans un ensemble de données que l'utilisateur a créé. Lorsqu'un utilisateur ayant le rôle bigquery.user crée un ensemble de données, il bénéficie d'un accès OWNER à cet ensemble de données. L'accès OWNER à un ensemble de données permet à l'utilisateur de contrôler entièrement celui-ci, toutes les tables qu'il contient et toutes les partitions de la table.

Pour en savoir plus sur les rôles et les autorisations IAM dans BigQuery, consultez la page Contrôle des accès. Si vous souhaitez obtenir davantage d'informations sur les rôles au niveau des ensembles de données, consultez la section Rôles primitifs pour les ensembles de données.

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 :

UI Web

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

CLI

Exécutez la commande bq rm avec le paramètre --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. Vous pouvez vous servir du paramètre --force (ou le raccourci -f) pour passer l'étape de confirmation.

Si la table partitionnée se trouve dans l'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 de votre projet.
  • [DATASET] correspond au 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.