Appliquer des recommandations de partition et de cluster

Ce document explique comment appliquer des recommandations de partition et de cluster à vos tables BigQuery.

Limites

L'outil de recommandation de partitionnement et de clustering n'est pas compatible avec les tables BigQuery utilisant l'ancien SQL. Lors de la génération d'une recommandation, l'outil de recommandation exclut toutes les requêtes en ancien SQL de son analyse. En outre, l'application de recommandations de partition sur les tables BigQuery avec l'ancien SQL interrompt tous les workflows en ancien SQL de cette table.

Avant d'appliquer des recommandations de partition, migrez vos workflows en ancien SQL vers GoogleSQL.

L'outil de recommandation de partitionnement et de clustering n'accepte pas les ressources stockées dans les régions suivantes :

europe-central2, europe-west8, europe-west9, europe-west12, europe-north1, europe-southwest1
us-east1, us-east5 et us-south1
me-central1, me-central2 et me-west1
australia-southeast2
southamerica-west1

Avant de commencer

Assurez-vous que l'API Recommender est activée.
Vérifiez que vous disposez des autorisations IAM (Identity and Access Management) requises.

Appliquer des recommandations de cluster

Vous pouvez appliquer des recommandations de cluster en appliquant des clusters à une copie de la table d'origine, en les appliquant directement à la table d'origine ou en utilisant des vues matérialisés.

Appliquer des recommandations de cluster à une table copiée

Lorsque vous appliquez des recommandations de cluster à une table BigQuery, vous pouvez d'abord copier la table d'origine, puis appliquer la recommandation à la table copiée. Cette méthode garantit que vos données d'origine sont conservées si vous devez annuler la modification de la configuration de clustering.

Cette méthode vous permet d'appliquer des recommandations de cluster aux tables non partitionnées et aux tables partitionnées.

Dans la console Google Cloud, accédez à la page "BigQuery".

Accéder à BigQuery
Dans l'éditeur de requête, créez une table vide avec les mêmes métadonnées (y compris les spécifications de clustering) de la table d'origine à l'aide de l'opérateur LIKE :
```
CREATE TABLE DATASET.COPIED_TABLE
LIKE DATASET.ORIGINAL_TABLE
```
Remplacez les éléments suivants :
- DATASET : nom de l'ensemble de données contenant la table, par exemple mydataset
- COPIED_TABLE : nom de votre table copiée, par exemple copy_mytable
- ORIGINAL_TABLE : nom de votre table d'origine, par exemple mytable
Dans la console Google Cloud, ouvrez l'éditeur Cloud Shell.

Activer Cloud Shell
Dans l'éditeur Cloud Shell, mettez à jour la spécification de clustering de la table copiée pour qu'elle corresponde au clustering recommandé à l'aide de la commande bq update :
```
 bq update --clustering_fields=CLUSTER_COLUMN DATASET.COPIED_TABLE 
```
Remplacez CLUSTER_COLUMN par la colonne sur laquelle vous effectuez le clustering, par exemple mycolumn.

Vous pouvez également appeler la méthode API tables.update ou tables.patch pour modifier la spécification du clustering.

Dans l'éditeur de requête, récupérez le schéma de table avec la configuration de partitionnement et de clustering de la table d'origine, si un partitionnement ou un clustering existe. Vous pouvez récupérer le schéma en affichant la vue INFORMATION_SCHEMA.TABLES de la table d'origine :

SELECT
  ddl
FROM
  DATASET.INFORMATION_SCHEMA.TABLES
WHERE
  table_name = 'DATASET.ORIGINAL_TABLE;'

Le résultat est l'instruction LDD (langage de définition de données) complète de ORIGINAL_TABLE, y compris la clause PARTITION BY. Pour en savoir plus sur les arguments de votre sortie LDD, consultez la section Instruction CREATE TABLE.

Le résultat LDD indique le type de partitionnement dans la table d'origine :

Type de partitionnement	Exemple de sortie
Non partitionnée	La clause `PARTITION BY` est absente.
Partitionnée par colonne de table	`PARTITION BY c0`
	`PARTITION BY DATE(c0)`
	`PARTITION BY DATETIME_TRUNC(c0, MONTH)`
Partitionnée par date d'ingestion	`PARTITION BY _PARTITIONDATE`
Partitionnée par date d'ingestion	`PARTITION BY DATETIME_TRUNC(_PARTITIONTIME, MONTH)`

Ingérez les données dans la table copiée. Le processus à utiliser dépend du type de partition.
- Si la table d'origine n'est pas partitionnée ou partitionnée par une colonne de table, ingérez les données de la table d'origine dans la table copiée :
```
INSERT INTO DATASET.COPIED_TABLE
SELECT * FROM DATASET.ORIGINAL_TABLE
```
- Si la table d'origine est partitionnée par date d'ingestion, procédez comme suit :
  1. Récupérez la liste des colonnes pour former l'expression d'ingestion de données à l'aide de la vue INFORMATION_SCHEMA.COLUMNS :
```
SELECT
ARRAY_TO_STRING((
SELECT
  ARRAY(
  SELECT
    column_name
  FROM
    DATASET.INFORMATION_SCHEMA.COLUMNS
  WHERE
    table_name = 'ORIGINAL_TABLE')), ", ")
```
    La sortie est une liste de noms de colonnes séparés par une virgule.
  2. Ingérez les données de la table d'origine dans la table de copie :
```
INSERT DATASET.COPIED_TABLE (COLUMN_NAMES, _PARTITIONTIME)
SELECT *, _PARTITIONTIME FROM DATASET.ORIGINAL_TABLE
```
    Remplacez COLUMN_NAMES par la liste des colonnes en sortie de l'étape précédente, séparées par une virgule (par exemple, col1, col2, col3).
Vous disposez maintenant d'une table de copie en cluster avec les mêmes données que la table d'origine. Dans les étapes suivantes, vous allez remplacer votre table d'origine par une nouvelle table en cluster.
Renommez la table d'origine en table de sauvegarde :
```
ALTER TABLE DATASET.ORIGINAL_TABLE
RENAME TO DATASET.BACKUP_TABLE
```
Remplacez BACKUP_TABLE par le nom de votre table de sauvegarde, par exemple backup_mytable.
Renommez la table de copie en table d'origine :
```
ALTER TABLE DATASET.COPIED_TABLE
RENAME TO DATASET.ORIGINAL_TABLE
```
Votre table d'origine est maintenant mise en cluster conformément à la recommandation de cluster.

Nous vous recommandons d'examiner la table en cluster pour vous assurer que toutes les fonctions de la table fonctionnent comme prévu. De nombreuses fonctions de table sont probablement liées à l'ID de table et non au nom de la table. Il est donc préférable d'examiner les fonctions de table suivantes avant de continuer :

Les accès et autorisations, tels que les autorisations IAM, l'accès au niveau des lignes ou l'accès au niveau des colonnes.
Les artefacts de table, tels que les clones de table, les instantanés de table ou les index de recherche.
L'état de tous les processus de table en cours, tels que les vues matérialisées ou les jobs exécutés lors de la copie de la table.
La possibilité d'accéder aux données historiques des tables à l'aide des fonctionnalités temporelles.
Toutes les métadonnées associées à la table d'origine, par exemple table_option_list ou column_option_list. Pour en savoir plus, consultez la section Instructions de langage de définition des données.

Si des problèmes surviennent, vous devez migrer manuellement les artefacts concernés vers la nouvelle table.

Après avoir examiné la table en cluster, vous pouvez éventuellement supprimer la table de sauvegarde à l'aide de la commande suivante :

    DROP TABLE DATASET.BACKUP_TABLE

Appliquer des recommandations de cluster directement

Vous pouvez directement appliquer des recommandations de cluster à une table BigQuery existante. Cette méthode est plus rapide que d'appliquer des recommandations à une table copiée, mais elle ne conserve pas de table de sauvegarde.

Suivez ces étapes pour appliquer une nouvelle spécification de clustering à des tables non partitionnées ou partitionnées.

Dans l'outil bq, mettez à jour la spécification de clustering de votre table pour qu'elle corresponde au nouveau clustering :
```
 bq update --clustering_fields=CLUSTER_COLUMN DATASET.ORIGINAL_TABLE 
```
Remplacez les éléments suivants :
- CLUSTER_COLUMN : colonne sur laquelle vous effectuez le clustering, par exemple mycolumn
- DATASET : nom de l'ensemble de données contenant la table, par exemple mydataset
- ORIGINAL_TABLE : nom de votre table d'origine, par exemple mytable
Vous pouvez également appeler la méthode API tables.update ou tables.patch pour modifier la spécification du clustering.
Pour mettre en cluster toutes les lignes conformément à la nouvelle spécification de clustering, exécutez l'instruction UPDATE suivante :
```
UPDATE DATASET.ORIGINAL_TABLE SET CLUSTER_COLUMN=CLUSTER_COLUMN WHERE true
```
Remarque : Si une nouvelle spécification de clustering est appliquée à une table en stockage à long terme, la table reprend la tarification du stockage actif. Pour en savoir plus, consultez les tarifs de stockage.

Appliquer des recommandations de cluster à l'aide de vues matérialisées

Vous pouvez créer une vue matérialisée de la table pour stocker les données de la table d'origine avec la recommandation appliquée. L'utilisation de vues matérialisées pour appliquer des recommandations garantit la tenue à jour des données en cluster à l'aide d'actualisations automatiques. Lorsque vous interrogez, gérez et stockez des vues matérialisées, il existe des considérations tarifaires à prendre en compte. Pour savoir comment créer une vue matérialisée en cluster, consultez la section Vues matérialisées en cluster.

Appliquer des recommandations de partition

Vous pouvez appliquer des recommandations de partition en appliquant des partitions à une copie de la table d'origine.

Appliquer des recommandations de partition à une table copiée

Lorsque vous appliquez des recommandations de partition à une table BigQuery, vous pouvez d'abord copier la table d'origine, puis appliquer la recommandation à la table copiée. Cette approche garantit que vos données d'origine sont conservées si vous devez effectuer un rollback d'une partition.

La procédure suivante utilise un exemple de recommandation pour partitionner une table en fonction de l'unité de temps DAY.

Créez une table copiée à l'aide des recommandations de partition :
```
CREATE TABLE DATASET.COPIED_TABLE
PARTITION BY DATE_TRUNC(PARTITION_COLUMN, DAY)
AS SELECT * FROM DATASET.ORIGINAL_TABLE
```
Remplacez les éléments suivants :
- DATASET : nom de l'ensemble de données contenant la table, par exemple mydataset
- COPIED_TABLE : nom de votre table copiée, par exemple copy_mytable
- PARTITION_COLUMN : colonne sur laquelle vous effectuez le partitionnement, par exemple mycolumn.
Pour plus d'informations sur la création de tables partitionnées, consultez la section Créer des tables partitionnées.
Renommez la table d'origine en table de sauvegarde :
```
ALTER TABLE DATASET.ORIGINAL_TABLE
RENAME TO DATASET.BACKUP_TABLE
```
Remplacez BACKUP_TABLE par le nom de votre table de sauvegarde, par exemple backup_mytable.
Renommez la table de copie en table d'origine :
```
ALTER TABLE DATASET.COPIED_TABLE
RENAME TO DATASET.ORIGINAL_TABLE
```
Votre table d'origine est maintenant partitionnée conformément à la recommandation de partition.

Nous vous recommandons d'examiner la table partitionnée pour vous assurer que toutes les fonctions de la table fonctionnent comme prévu. De nombreuses fonctions de table sont probablement liées à l'ID de table et non au nom de la table. Il est donc préférable d'examiner les fonctions de table suivantes avant de continuer :

Les accès et autorisations, tels que les autorisations IAM, l'accès au niveau des lignes ou l'accès au niveau des colonnes.
Les artefacts de table, tels que les clones de table, les instantanés de table ou les index de recherche.
L'état de tous les processus de table en cours, tels que les vues matérialisées ou les jobs exécutés lors de la copie de la table.
La possibilité d'accéder aux données historiques des tables à l'aide des fonctionnalités temporelles.
Toutes les métadonnées associées à la table d'origine, par exemple table_option_list ou column_option_list. Pour en savoir plus, consultez la section Instructions de langage de définition des données.
La possibilité d'utiliser l'ancien SQL pour écrire des résultats de requête dans des tables partitionnées. L'utilisation de l'ancien SQL n'est pas totalement compatible avec les tables partitionnées. Une solution consiste à migrer vos workflows en l'ancien SQL vers GoogleSQL avant d'appliquer une recommandation de partition.

Si des problèmes surviennent, vous devez migrer manuellement les artefacts concernés vers la nouvelle table.

Après avoir examiné la table partitionnée, vous pouvez éventuellement supprimer la table de sauvegarde à l'aide de la commande suivante :

    DROP TABLE DATASET.BACKUP_TABLE

Tarifs

L'application d'une recommandation à une table peut entraîner les coûts suivants :

Coûts de traitement. Lorsque vous appliquez une recommandation, vous exécutez une requête LDD (langage de définition de données) ou LMD (langage de manipulation de données) sur votre projet BigQuery.
Coûts de stockage. Si vous utilisez la méthode de copie d'une table, vous utilisez de l'espace de stockage supplémentaire pour la table copiée (ou de sauvegarde).

Les frais de traitement et de stockage standards s'appliquent en fonction du compte de facturation associé au projet. Pour en savoir plus, consultez la page relative aux tarifs de BigQuery.