Introduction à l'optimisation des coûts et des performances de BigQuery
Le problème
Imaginez : votre entreprise exploite plusieurs datasets BigQuery et vous venez d'intégrer, le mois dernier, une nouvelle équipe d'analystes qui les interroge. Un matin, en sirotant votre café (ou votre thé, on ne fait pas de discrimination), vous recevez votre facture GCP et découvrez que vos coûts d'analyse et de stockage BQ ont bondi de 5 000 %. De quoi recracher instantanément votre boisson sur votre clavier et votre écran. Cet article va vous aider à corriger, voire à prévenir ce genre de mésaventure, en présentant plusieurs méthodes pour optimiser vos coûts BigQuery.
Poser les bonnes bases
Avant de vous attaquer à vos coûts BigQuery, quelques préparatifs et prérequis sont nécessaires.
Je les aborde dans cette première partie de la série. Une fois les bases assimilées et les préparatifs effectués, vous pourrez enchaîner directement avec la Partie 2 et les suivantes pour passer à l'optimisation concrète.
Voici ce qu'il faut savoir sur les slots BigQuery, les modèles de tarification et les facteurs qui déterminent les coûts :
Les slots
Au cœur du moteur de calcul de BigQuery se trouve une notion appelée slot. Un slot, c'est tout simplement un vCPU avec un peu de mémoire associée — comme une mini-VM dédiée au traitement BigQuery. Lorsque vous lancez une requête dans BigQuery, celle-ci est exécutée sur un ensemble de slots alloués. En théorie, plus vous disposez de slots alloués et disponibles, plus vos requêtes s'exécutent rapidement.
Un slot prend en charge presque toutes les opérations qui interviennent dans le traitement d'un job BigQuery.
Les shuffle slots
Dans BigQuery, une tâche non documentée que les slots assurent est le shuffling des données. Jusqu'à 60 % des slots alloués à votre projet peuvent jouer le rôle de shuffle slot à un instant donné.
Pour faire simple, le shuffling consiste à redistribuer les données traitées vers un nouvel emplacement afin que l'étape en cours ou suivante du plan d'exécution se déroule plus vite. Le white paper de Google sur l'architecture de BigQuery vous donnera une compréhension plus poussée de son fonctionnement. Le shuffling permet à la requête de s'exécuter plus efficacement, mais il mobilise des slots précieux pour des opérations qui ne font pas progresser directement l'exécution.
Les modèles de tarification
BigQuery propose actuellement deux modèles de tarification distincts : à la demande ou forfaitaire.
Tarification à la demande
Le modèle par défaut est la tarification à la demande, qui alloue 2 000 slots à vos requêtes ainsi qu'un autre pool, dont la taille n'est pas publiée, pour les loads, les copies de tables et les jobs d'extraction. Lorsque des slots excédentaires se libèrent à l'échelle de BigQuery, ce pool de 2 000 slots peut s'étendre, mais ce n'est pas garanti : ne partez donc pas du principe que cela arrivera. À titre indicatif, j'ai vu au maximum environ 3 500 slots, sur de courtes périodes.
Dans ce modèle, vous êtes facturé à un tarif fixe de 5 $ par To de données scannées par les requêtes.
Pour de nombreuses organisations, c'est le principal moteur des coûts BigQuery.
Tarification forfaitaire
La tarification forfaitaire (ou par slots) fixe un prix forfaitaire pour les scans BigQuery, au prix potentiel de la performance. Elle limite le nombre de slots disponibles à ceux que vous avez achetés à l'avance et supprime la facturation à 5 $ par To scanné.
Les slots (y compris les Flex Slots que j'aborde plus bas) s'achètent toujours par tranches de 100. Les slots standards (donc non Flex) sont achetés dans le cadre d'un commitment d'un mois ou d'un an. Notez qu'une fois la réservation souscrite, elle ne peut pas être annulée facilement. Un commitment d'un mois peut être converti en commitment d'un an, mais l'inverse n'est pas possible.
Une petite subtilité existe concernant ce qui se passe en fin de commitment, qui diffère entre les deux et qui a évolué à plusieurs reprises. Pour cette raison, je me contente de renvoyer à la documentation Google sur les commitments mensuels et les commitments annuels, au cas où elle évoluerait à nouveau. Je recommande vivement de programmer des rappels dans votre calendrier bien avant l'échéance, pour pouvoir réagir à temps.
Cela dit, en tarification forfaitaire, vos slots peuvent être complétés, voire entièrement remplacés, par un pool supplémentaire de slots appelés Flex Slots. Les Flex Slots sont identiques en capacité et en fonctionnement aux slots classiques, mais ils offrent une option de commitment plus court et plus flexible, avec une durée minimale de 60 secondes. Une fois cette durée minimale atteinte, vous pouvez annuler la réservation à tout moment et les slots disparaissent. Cela vous permet d'augmenter ou de réduire votre capacité de slots selon les besoins. On y a généralement recours quand un volume supplémentaire de slots est nécessaire sur de courtes périodes — pics d'utilisation ou exécution d'un job particulièrement gourmand qui risquerait de saturer tous les slots d'une réservation. L'exemple type : les enseignes du retail le Black Friday ou le Cyber Monday, les plus grosses journées commerciales aux États-Unis.
À la date de rédaction, 100 slots coûtent 2 000 $ US pour un commitment d'un mois et 1 700 $ US par mois pour un commitment d'un an. Ainsi, pour égaler la performance du modèle à la demande, vous devrez acheter vingt tranches de 100 slots, soit 40 000 $ US par mois pour un commitment d'un mois ou 34 000 $ US par mois pour un commitment d'un an. De manière générale, il n'est donc pas rentable d'acheter 2 000 slots à moins que vos coûts de scan BigQuery atteignent déjà ce niveau.
Le plan pour analyser les coûts
Avant d'optimiser les coûts, il faut analyser les données d'utilisation de votre ou vos projets. Pour cela, vous devez accéder aux données de requête de vos projets et datasets.
Petite mise au point pour cadrer les attentes : j'aborde ce point dès la première partie de la série afin que la collecte puisse démarrer dès maintenant et enregistrer vos données d'utilisation, au cas où vous ne liriez pas plusieurs parties d'affilée (assis ou debout). C'est à partir de la Partie 3 que les fruits de ce travail seront réellement exploités.
Deux méthodes existent : les sinks de logs d'audit et les vues INFORMATION_SCHEMA.
Le sink de logs d'audit est la méthode à privilégier, car les données sont bien plus riches et couvrent plusieurs projets, datasets et régions. En revanche, s'il n'est pas déjà activé, il lui faudra un certain temps pour se remplir au fil des jobs exécutés sur BigQuery. Notez qu'un faible coût est associé au sink de logs d'audit, sous la forme de coûts de stockage BigQuery pour les données.
Les vues INFORMATION_SCHEMA, elles, existent déjà dans chaque dataset, projet et région. Mais, contrairement au sink de logs d'audit, chaque combinaison dataset/région possède son propre jeu de tables : les requêtes devront donc parfois être exécutées plusieurs fois. Notez aussi que certaines informations présentes dans les tables de logs d'audit sont absentes des tables INFORMATION_SCHEMA. Quelques exemples sont documentés en commentaires dans les requêtes SQL plus loin dans l'article, là où elles ne correspondront pas exactement aux requêtes du sink de logs d'audit.
Si vous optez pour la méthode INFORMATION_SCHEMA, vous pouvez sauter la prochaine section sur la configuration du sink de logs d'audit, puisque vos données existent déjà. Une nuance toutefois : les données collectées par le sink de logs d'audit sont plus riches que celles fournies par les vues INFORMATION_SCHEMA. Le revers de la médaille, c'est qu'une fois le sink configuré, l'enregistrement démarre à cet instant précis : il faudra donc laisser tourner vos workloads habituels pendant un certain temps avant que les données soient exploitables. Ce délai dépend fortement des workloads exécutés et de ce qui est considéré comme normal en matière de fréquence d'exécution chez vous.
Note : si vous êtes déjà client DoiT et que vous utilisez le dashboard BigQuery Lens de notre Cloud Management Platform (CMP), le sink de logs d'audit est déjà configuré dans votre environnement. Je vous recommande de l'utiliser pour les opérations décrites dans ces articles. Plus d'informations ici.
Le nom complet du dataset sera
Si c'est votre cas, vous pouvez sauter la section suivante.
Configurer un sink de logs d'audit
Si vous choisissez d'utiliser les vues INFORMATION_SCHEMA plutôt qu'un sink de logs d'audit, sautez cette section.
Voici les instructions pour configurer un sink de logs d'audit. Il est préférable d'exécuter ces commandes depuis votre poste local ou depuis Cloud Shell, avec la CLI gcloud configurée pour utiliser le projet dans lequel vous souhaitez stocker le dataset.
Exécutez d'abord la commande suivante en mettant à jour le nom du sink, l'ID du projet et le nom du dataset :
gcloud logging sinks create <Sink Name> bigquery.googleapis.com/projects/<Project ID>/datasets/<Dataset Name> \ — use-partitioned-tables \
— log-filter=’protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.BigQueryAuditMetadata"’
Une fois cette commande exécutée, elle affiche un compte de service créé à cette fin. Copiez l'adresse e-mail complète de ce compte de service dans une note.
Vous allez ensuite accorder à ce compte de service le rôle BigQuery Editor dans chaque projet qui utilise BigQuery. Comme toujours dans le cloud, plusieurs méthodes existent. J'inclus ici les trois plus courantes : par projet, à l'échelle d'une organisation, ou sur un dossier au sein d'une organisation.
Note : pour récupérer l'ID du projet, du dossier ou de l'organisation, ouvrez le sélecteur de projet en haut de votre console GCP. Une colonne ID y figure et vous donnera l'identifiant nécessaire pour la ressource.
Par projet :
gcloud projects add-iam-policy-binding <Project ID> \
— member=<Service Account> — role=roles/bigquery.dataEditor
À l'échelle d'une organisation :
gcloud organizations add-iam-policy-binding <Organization ID> \
— -member=<Service Account> — role=roles/bigquery.dataEditor
Sur l'ensemble d'un dossier :
gcloud resource-manager folders add-iam-policy-binding <Folder ID> \
— -member=<Service Account> — role=roles/bigquery.dataEditor
À ce stade, les données de requête commencent à être stockées dans le dataset indiqué plus haut. Pour disposer d'un volume de données significatif, attendez au minimum quelques jours, voire quelques semaines pour de meilleurs résultats. Plus la collecte couvre une longue période d'utilisation normale, mieux c'est : cela permet de repérer les éventuels pics ou tendances d'usage.
Les vues INFORMATION_SCHEMA
Les vues INFORMATION_SCHEMA existent déjà dans chaque dataset, projet et région, mais, contrairement au sink de logs d'audit, chaque combinaison dataset/région possède son propre jeu de tables : les requêtes devront parfois être exécutées plusieurs fois. Les vues INFORMATION_SCHEMA omettent certaines informations présentes dans les tables de logs d'audit. Des exemples sont documentés en commentaires dans les requêtes SQL plus loin dans la série, là où elles ne s'aligneront pas exactement avec les requêtes du sink de logs d'audit.
L'avantage des vues INFORMATION_SCHEMA, c'est que les données sont déjà disponibles, même si vous n'avez pas configuré le sink.
À suivre
Cela conclut la première partie de cette série, qui pose les fondations des méthodes décrites dans la suite.