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
etus-south1
me-central1
,me-central2
etme-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".
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 exemplemydataset
COPIED_TABLE
: nom de votre table copiée, par exemplecopy_mytable
ORIGINAL_TABLE
: nom de votre table d'origine, par exemplemytable
Dans la console Google Cloud, ouvrez l'éditeur 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 exemplemycolumn
.Vous pouvez également appeler la méthode API
tables.update
outables.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 InstructionCREATE 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
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 :
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.
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.
- 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 :
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 exemplebackup_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.
- 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
oucolumn_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 exemplemycolumn
DATASET
: nom de l'ensemble de données contenant la table, par exemplemydataset
ORIGINAL_TABLE
: nom de votre table d'origine, par exemplemytable
Vous pouvez également appeler la méthode API
tables.update
outables.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
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 exemplemydataset
COPIED_TABLE
: nom de votre table copiée, par exemplecopy_mytable
PARTITION_COLUMN
: colonne sur laquelle vous effectuez le partitionnement, par exemplemycolumn
.
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 exemplebackup_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.
- 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
oucolumn_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.