Interroger des tables partitionnées

Ce document décrit certaines considérations spécifiques concernant l'interrogation des tables partitionnées dans BigQuery.

Pour obtenir des informations générales sur l'exécution de requêtes dans BigQuery, consultez la page Exécuter des requêtes interactives et par lot.

Présentation

Si une requête utilise un filtre éligible sur la valeur de la colonne de partitionnement, BigQuery peut analyser les partitions correspondant au filtre et ignorer les partitions restantes. Ce processus est appelé élimination des partitions.

Il s'agit du mécanisme par lequel BigQuery élimine les partitions inutiles de l'analyse de l'entrée. Les partitions éliminées ne sont pas incluses lors du calcul des octets analysés par la requête. En général, l'élimination des partitions permet de réduire le coût des requêtes.

Interroger une table partitionnée par colonne d'unité de temps

Pour restreindre les partitions lorsque vous interrogez une table partitionnée par colonne d'unité de temps, incluez un filtre sur la colonne de partitionnement.

Dans l'exemple suivant, supposons que dataset.table soit partitionné sur la colonne transaction_date. L'exemple de requête élimine des dates antérieures à 2016-01-01.

SELECT * FROM dataset.table
WHERE transaction_date >= '2016-01-01'

Interroger une table partitionnée par date d'ingestion

Les tables partitionnées par date d'ingestion contiennent une pseudo-colonne nommée _PARTITIONTIME, qui est la colonne de partitionnement. La valeur de la colonne est le temps d'ingestion UTC pour chaque ligne, tronqué à la limite de la partition (par exemple, horaire ou quotidien), en tant que valeur TIMESTAMP.

Par exemple, si vous ajoutez des données le 15 avril 2021 à 08:15:00 UTC, la colonne _PARTITIONTIME de ces lignes contient les valeurs suivantes :

  • Table partitionnée par heure : TIMESTAMP("2021-04-15 08:00:00")
  • Table partitionnée par jour : TIMESTAMP("2021-04-15")
  • Table partitionnée par mois: TIMESTAMP("2021-04-01")
  • Table partitionnée par année: TIMESTAMP("2021-01-01")

Si la précision des partitions est quotidienne, la table contient également une pseudo-colonne nommée _PARTITIONDATE. La valeur est égale à _PARTITIONTIME tronquée à une valeur DATE.

Ces deux noms de pseudo-colonnes sont réservés. Vous ne pouvez créer aucune colonne portant un nom donné dans vos tables.

Pour restreindre les partitions, filtrez sur l'une de ces colonnes. Par exemple, la requête suivante analyse uniquement les partitions comprises entre le 1er janvier 2016 et le 2 janvier 2016 :

SELECT
  column
FROM
  dataset.table
WHERE
  _PARTITIONTIME BETWEEN TIMESTAMP('2016-01-01') AND TIMESTAMP('2016-01-02')

Pour sélectionner la pseudo-colonne _PARTITIONTIME, vous devez utiliser un alias. Par exemple, la requête suivante sélectionne _PARTITIONTIME en attribuant l'alias pt à la pseudo-colonne :

SELECT
  _PARTITIONTIME AS pt, column
FROM
  dataset.table

Pour les tables partitionnées par jour, vous pouvez sélectionner la pseudo-colonne _PARTITIONDATE de la même manière :

SELECT
  _PARTITIONDATE AS pd, column
FROM
  dataset.table

Les pseudo-colonnes _PARTITIONTIME et _PARTITIONDATE ne sont pas renvoyées par une instruction SELECT *. Vous devez les sélectionner explicitement :

SELECT
  _PARTITIONTIME AS pt, *
FROM
  dataset.table

Gérer les fuseaux horaires dans les tables partitionnées par date d'ingestion

La valeur de _PARTITIONTIME est basée sur la date UTC lorsque le champ est renseigné. Si vous souhaitez interroger des données basées sur un fuseau horaire autre qu'UTC, choisissez l'une des options suivantes :

  • Ajustez les différences de fuseaux horaires dans vos requêtes SQL.
  • Utilisez des décorateurs de partitions pour charger des données dans des partitions par date d'ingestion spécifiques, en fonction d'un fuseau horaire différent d'UTC.

Optimiser les performances avec des pseudo-colonnes

Pour améliorer les performances des requêtes, utilisez la pseudo-colonne _PARTITIONTIME seule du côté gauche d'une comparaison.

Par exemple, les deux requêtes suivantes sont équivalentes. Selon la taille de la table, la seconde requête, qui place la pseudo-colonne _PARTITIONTIME seule sur la gauche de l'opérateur de comparaison >, peut offrir de meilleures performances que la première requête. Les deux requêtes traitent le même volume de données.

-- Might be slower.
SELECT
  field1
FROM
  dataset.table1
WHERE
  TIMESTAMP_ADD(_PARTITIONTIME, INTERVAL 5 DAY) > TIMESTAMP("2016-04-15");

-- Often performs better.
SELECT
  field1
FROM
  dataset.table1
WHERE
  _PARTITIONTIME > TIMESTAMP_SUB(TIMESTAMP('2016-04-15'), INTERVAL 5 DAY);

Pour limiter les partitions analysées dans une requête, utilisez une expression constante dans votre filtre. La requête suivante limite les partitions éliminées en fonction de la première condition de filtre dans la clause WHERE. Toutefois, la deuxième condition de filtre ne limite pas les partitions analysées, car elle utilise des valeurs de table dynamiques.

SELECT
  column
FROM
  dataset.table2
WHERE
  -- This filter condition limits the scanned partitions:
  _PARTITIONTIME BETWEEN TIMESTAMP('2017-01-01') AND TIMESTAMP('2017-03-01')
  -- This one doesn't, because it uses dynamic table values:
  AND _PARTITIONTIME = (SELECT MAX(timestamp) from dataset.table1)

Pour limiter les partitions analysées, n'incluez aucune autre colonne dans un filtre _PARTITIONTIME. Par exemple, la requête suivante ne limite pas les partitions analysées, car field1 est une colonne de la table.

-- Scans all partitions of table2. No pruning.
SELECT
  field1
FROM
  dataset.table2
WHERE
  _PARTITIONTIME + field1 = TIMESTAMP('2016-03-28');

Si vous interrogez souvent une période spécifique, envisagez de créer une vue qui filtre la pseudo-colonne _PARTITIONTIME. Par exemple, l'instruction suivante crée une vue qui n'inclut que les sept derniers jours de données d'une table nommée dataset.partitioned_table :

-- This view provides pruning.
CREATE VIEW dataset.past_week AS
  SELECT *
  FROM
    dataset.partitioned_table
  WHERE _PARTITIONTIME BETWEEN
    TIMESTAMP_TRUNC(TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 7 * 24 HOUR), DAY)
    AND TIMESTAMP_TRUNC(CURRENT_TIMESTAMP, DAY);

Pour en savoir plus sur la création de vues, consultez la page Créer des vues.

Interroger une table partitionnée par plages d'entiers

Pour restreindre les partitions lorsque vous interrogez une table partitionnée par plages d'entiers, incluez un filtre sur la colonne de partitionnement des entiers.

Dans l'exemple suivant, supposons que dataset.table soit une table partitionnée par plages d'entiers avec une spécification de partitionnement de customer_id:0:100:10. L'exemple de requête analyse les trois partitions commençant par 30, 40 et 50.

SELECT * FROM dataset.table
WHERE customer_id BETWEEN 30 AND 50

+-------------+-------+
| customer_id | value |
+-------------+-------+
|          40 |    41 |
|          45 |    46 |
|          30 |    31 |
|          35 |    36 |
|          50 |    51 |
+-------------+-------+

Actuellement, la restriction de partitions n'est pas compatible avec les fonctions sur une colonne partitionnée par plages d'entiers. Par exemple, la requête suivante analyse l'ensemble de la table.

SELECT * FROM dataset.table
WHERE customer_id + 1 BETWEEN 30 AND 50

Utiliser l'ancien SQL pour interroger des tables partitionnées par plages d'entiers

Vous ne pouvez pas utiliser l'ancien SQL pour interroger une table partitionnée par plages d'entiers entières. À la place, la requête renvoie une erreur semblable à celle-ci :

Querying tables partitioned on a field is not supported in Legacy SQL

Cependant, l'ancien SQL permet de circonscrire une partition spécifique dans une table partitionnée par plages d'entiers à l'aide de décorateurs de table. La clé permettant de circonscrire une partition par plages est le début de la plage.

L'exemple suivant interroge la partition par plages commençant par 30:

SELECT * FROM dataset.table$30

Interroger les données dans le stockage optimisé en écriture

La partition __UNPARTITIONED__ contient temporairement les données qui sont transmises à une table partitionnée alors qu'elles se trouvent dans le stockage optimisé en écriture. Les données transmises directement à une partition spécifique d'une table partitionnée n'utilisent pas la partition __UNPARTITIONED__. À la place, les données sont transmises directement à la partition.

Les données stockées dans le stockage optimisé en écriture ont des valeurs NULL dans les colonnes _PARTITIONTIME et _PARTITIONDATE.

Pour interroger des données dans la partition __UNPARTITIONED__, utilisez la pseudo-colonne _PARTITIONTIME avec la valeur NULL. Exemple :

SELECT
  column
FROM dataset.table
WHERE
  _PARTITIONTIME IS NULL

Pour plus d'informations, consultez la section Insérer des données en flux continu dans des tables partitionnées.

Bonnes pratiques pour l'élimination des partitions

Utiliser une expression de filtre constante

Pour limiter les partitions analysées dans une requête, utilisez une expression constante dans votre filtre. Si vous utilisez des expressions dynamiques dans votre filtre de requête, BigQuery doit analyser toutes les partitions.

Par exemple, la requête suivante élimine des partitions, car le filtre contient une expression constante :

SELECT
  t1.name,
  t2.category
FROM
  table1 AS t1
INNER JOIN
  table2 AS t2
ON t1.id_field = t2.field2
WHERE
  t1.ts = CURRENT_TIMESTAMP()

Cependant, la requête suivante n'élimine pas de partitions, car le filtre WHERE t1.ts = (SELECT timestamp from table where key = 2) n'est pas une expression constante ; cela dépend des valeurs dynamiques des champs timestamp et key:

SELECT
  t1.name,
  t2.category
FROM
  table1 AS t1
INNER JOIN
  table2 AS t2
ON
  t1.id_field = t2.field2
WHERE
  t1.ts = (SELECT timestamp from table3 where key = 2)

Isoler la colonne de partition dans votre filtre

Isolez la colonne de partition lors de l'expression d'un filtre. Les filtres nécessitant des données provenant de plusieurs champs pour le calcul n'éliminent aucune partition. Par exemple, une requête avec une comparaison de dates qui utilise la colonne de partitionnement et un second champ, ou des requêtes contenant des concaténations de champs, n'éliminent aucune partition.

Par exemple, le filtre suivant n'élimine pas de partitions, car il nécessite un calcul basé sur le champ de partitionnement (ts) et sur un deuxième champ (ts2) :

WHERE TIMESTAMP_ADD(ts, INTERVAL 6 HOUR) > ts2

Exiger un filtre de partitionnement dans les requêtes

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 que le filtre soit éligible pour l'élimination de partitions, il doit y avoir au moins un prédicat qui ne référence qu'une ou plusieurs colonnes de partition. Par exemple, pour une table partitionnée suivant la colonne partition_id et dont le schéma comporte une colonne supplémentaire f, les deux clauses WHERE suivantes remplissent les conditions requises :

WHERE partition_id = "foo"
WHERE partition_id = "foo" AND f = "bar"

Toutefois, la clause WHERE (partition_id = "foo" OR f = "bar") n'est pas suffisante.

Pour les tables partitionnées par date d'ingestion, utilisez la pseudo-colonne _PARTITIONTIME ou _PARTITIONDATE.

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. Vous pouvez également mettre à jour ce paramètre sur une table existante.

Étapes suivantes