Suivre les bonnes pratiques d'optimisation des coûts BigQuery est ardu — et si un outil vous indiquait simplement quoi faire ?
Vos coûts BigQuery grimpent — et maintenant ?
Bien sûr, vous pourriez fouiller dans les audit logs à la recherche d'indices, ou parcourir les BigQuery Best Practices de Google Cloud pour mieux cerner ce qui pourrait être optimisé.
Mais avec un backlog de projets en attente et des urgences à gérer, vous ou votre équipe pouvez-vous vraiment y consacrer le temps nécessaire ? D'après notre expérience, la réponse est le plus souvent un non sans appel.
La plupart des entreprises avec lesquelles nous travaillons ont tout simplement trop de tâches produit prioritaires et des ressources d'engineering trop limitées pour s'attaquer à l'optimisation des coûts BigQuery. Résultat : beaucoup bâtissent leur infrastructure de données dans BigQuery au fil de l'eau, pour en subir ensuite les conséquences.
Et si vous disposiez d'un outil qui vous indiquait simplement quoi faire ?
C'est précisément pour cela que nous avons créé BigQuery Lens, qui fournit des recommandations personnalisées s'appuyant sur les bonnes pratiques BigQuery et sur notre propre expérience auprès des milliers de clients que nous avons aidés à optimiser leur usage de BigQuery.
Passons en revue plusieurs bonnes pratiques BigQuery et la manière de les mettre en œuvre avec BigQuery Lens.
" Grâce aux recommandations de BigQuery Lens, nous avons investi du temps dans le partitionnement de nos tables clés et avons pu réduire nos dépenses BigQuery de 25 % par mois. "
- Daniel Rimon, Head of Data Engineering, Resident
Comment BigQuery Lens vous aide à optimiser vos coûts
BigQuery Lens analyse vos jobs BigQuery et les métadonnées de vos tables pour produire des recommandations d'optimisation concrètes, accompagnées d'une vue détaillée des statistiques d'usage de votre équipe.
Vous pouvez bien sûr passer des heures à explorer audit logs et requêtes pour tenter de bâtir des dashboards via Cloud Monitoring ou en interrogeant INFORMATION_SCHEMA.JOBS, mais vous n'obtiendrez que des métriques de haut niveau. Il vous restera ensuite à tirer vos propres conclusions sur les actions à mener.
BigQuery Lens simplifie la mise en œuvre des bonnes pratiques.
Concrètement, ses recommandations sont conçues pour vous aider à :
- Réduire le volume de données scannées en clusterisant ou en partitionnant vos tables
- Réduire le coût de vos jobs planifiés
- Tirer parti de la tarification forfaitaire (flat-rate) lorsque c'est pertinent
- Diminuer les coûts de stockage en supprimant les tables inutilisées
- Imposer l'usage des champs partitionnés dans vos requêtes
- Décaler les jobs récurrents pour réduire le nombre de slots à acheter
Réduire les octets traités en clusterisant et en partitionnant les tables
Que vous interrogiez un projet en tarification on-demand ou flat-rate, vous y gagnerez côté coûts comme côté performance en réduisant le nombre d'octets traités par vos requêtes. Pour les projets en on-demand, cela diminue directement les coûts d'analyse. La tarification flat-rate étant fixée par le nombre de slots achetés, réduire les octets traités contribue indirectement à baisser les coûts en réduisant l'usage moyen de slots. Vous diminuez ainsi le nombre de slots à acheter (nous y reviendrons plus bas).
Un bon point de départ : clusteriser et/ou partitionner vos tables.
Clusteriser les tables (et comment en tirer le maximum)
Le clustering améliore les performances de vos requêtes en organisant votre table en blocs de données, en fonction de la ou des colonnes choisies pour le clustering. BigQuery peut alors scanner uniquement les blocs pertinents — à condition que vos requêtes soient correctement structurées.
Cependant, le bénéfice du clustering dépend de la ou des colonnes choisies — et de leur ordre — ainsi que de la façon dont vous structurez vos requêtes sur les tables clusterisées.
Mieux vaut clusteriser vos tables sur les colonnes fréquemment interrogées, en particulier lorsqu'elles contiennent de nombreuses valeurs distinctes. Dans ce cas, BigQuery interroge vos tables plus efficacement en exploitant l'ordre des colonnes défini par votre stratégie de clustering.
Comme le montre le schéma ci-dessous, il est tout aussi important de structurer vos requêtes selon l'ordre des champs de clustering retenus (autrement dit, de filtrer sur ces champs dans l'ordre du clustering). Vous tirerez ainsi pleinement parti de la stratégie de clustering définie sur vos tables dans vos jobs BigQuery.
BigQuery Lens identifie les tables à clusteriser et met en évidence la ou les colonnes à utiliser ainsi que leur ordre. Il vous suffit de cliquer sur le nom de la table dans la fenêtre de recommandation pour l'ouvrir dans votre Google Cloud Console et clusteriser la table.
Il peut aussi être utile de comparer vos requêtes antérieures sur la table concernée à celles exécutées après clustering. Vous constaterez très probablement des gains à la fois sur le coût et sur le temps d'exécution des jobs lancés sur cette table.
Partitionner les tables (et pourquoi le faire)
Le partitionnement des tables aide à maîtriser les coûts en découpant une grande table en segments plus petits. Il est particulièrement efficace lorsqu'il est associé au partition pruning — c'est-à-dire au filtrage de partitions spécifiques dans vos requêtes pour ne pas scanner la table entière.
Il vous permet aussi de gérer vos données à un niveau plus fin. Vous pouvez fixer une expiration sur certaines partitions ou gérer plus efficacement l'arrivée de nouvelles données via les partitions de vos tables BigQuery.
Comme pour les tables clusterisées, pour bénéficier du partitionnement votre requête doit appliquer un filtre éligible sur la valeur de la colonne de partitionnement.
Remarque : BigQuery Lens identifie également les requêtes sur des tables partitionnées qui n'utilisent pas de filtre éligible, alors qu'elles le pourraient (voir " Imposer les champs de partitionnement dans vos requêtes " ci-dessous).
Et comme pour le clustering, BigQuery Lens met en évidence les tables à partitionner et le champ à utiliser. C'est utile en général, mais si vous avez des dashboards BI alimentés par BigQuery, le partitionnement peut accélérer vos dashboards et rendre vos requêtes moins coûteuses.
Quand clusteriser ET partitionner une table
Dans certains cas, il peut être judicieux d'adopter une stratégie combinant à la fois partitionnement et clustering sur vos tables BigQuery.
Cette approche est particulièrement pertinente lorsque vous souhaitez un tri très fin au sein de vos tables (voir le schéma ci-dessous), tout en bénéficiant d'une meilleure visibilité sur le coût probable de vos requêtes avant exécution, grâce au partition pruning de BigQuery.
Gardez toutefois à l'esprit que combiner les deux stratégies entraîne davantage de métadonnées à maintenir, et que les bénéfices du clustering risquent d'être moindres si vos tables ne sont pas régulièrement interrogées sur les mêmes champs. L'intérêt de cette stratégie pour la structuration de vos tables BigQuery s'en trouverait annulé.
Passer à la tarification flat-rate
À mesure que votre usage et vos volumes de données BigQuery progressent, vous pourriez atteindre un seuil où passer du modèle on-demand au flat-rate devient plus économique.
Lorsque BigQuery Lens détecte une opportunité d'économies à ce changement, il affiche une recommandation d'engagement sur des slots. Dans l'exemple ci-dessous, BigQuery Lens montre que notre usage moyen quotidien maximal est de 169 slots, et recommande donc d'en réserver 200, l'achat se faisant par incréments de 100 slots. On observe également un pic d'usage bien plus élevé, à 2 238 slots.
Remarque : les BigQuery reservations et le modèle on-demand ne sont pas mutuellement exclusifs. Vous pouvez basculer entre les deux via BigQuery Reservations , et même y intégrer des Flex Slots.
Les slots impliquant un engagement minimum d'un mois, soyez particulièrement vigilant à l'achat si vous êtes incertain quant à votre activité future, à d'éventuels pics extrêmes ou à la saisonnalité de votre usage de BigQuery. C'est là que les Flex Slots entrent en jeu : ils vous permettent d'acheter des slots pour de courtes durées — à partir de 60 secondes seulement.
Par exemple, si vous lancez tous vos jobs de chargement/reporting à 3 h du matin, vous pouvez monter et descendre en charge facilement en planifiant le provisionnement et le déprovisionnement des Flex Slots avec Cloud Composer. Pour éviter que la demande ne dépasse la disponibilité des slots, l'un de nos clients utilise même Cloud Functions pour vérifier toutes les cinq minutes si son usage de slots dépasse 90 % de son engagement, en provisionnant automatiquement des Flex Slots le cas échéant.
Réduire la fréquence de vos jobs planifiés et autres jobs récurrents
Vous avez peut-être des jobs planifiés qui n'ont pas besoin d'être exécutés aussi souvent qu'ils le sont — voire qui n'ont plus lieu d'être exécutés du tout. BigQuery Lens fait remonter les jobs fréquemment exécutés et affiche les économies potentielles liées à une réduction de leur fréquence d'exécution de 10 à 50 %.
Cette recommandation alimente des discussions plus pertinentes sur la maîtrise des coûts au sein de votre équipe et garantit que les jobs particulièrement coûteux ne tournent que lorsque c'est nécessaire.
Par exemple, un client a remarqué plusieurs jobs qui n'avaient pas besoin de tourner aussi souvent. Il a soulevé le sujet auprès de l'équipe élargie pour en réduire la fréquence et a estimé pouvoir économiser 10 à 15 % sur les coûts de requêtes en réduisant légèrement le nombre d'exécutions.
Un autre client a repéré des requêtes planifiées devenues obsolètes. Avant BigQuery Lens, il n'en avait pas la visibilité. Le mois suivant l'annulation de ces requêtes inutiles, il a vu ses dépenses BigQuery - Analysis chuter de plus de 50 %.
Enfin, si ces requêtes récurrentes proviennent d'un dashboard BI (par exemple Looker), vous pouvez réduire les coûts en les faisant passer par BI Engine. BI Engine est idéal pour les requêtes de dashboard, car il met intelligemment en cache les données BigQuery en mémoire, ce qui accélère les requêtes. Comme BI Engine met les données en cache en mémoire, l'étape de lecture des données de table est gratuite. Vous ne payez que la capacité mémoire réservée. En revanche, si votre projet est en flat-rate, les étapes suivantes consomment des slots de votre BigQuery reservation.
Réduire les coûts de stockage en sauvegardant et en supprimant les tables inutilisées
Les requêtes ne sont pas le seul poste sur lequel économiser : vous payez aussi le stockage dans BigQuery ! D'après notre expérience, les tables inutilisées constituent un levier d'économies trop souvent négligé.
BigQuery Lens met en évidence les tables (et les partitions, le cas échéant) restées inutilisées sur les 30 derniers jours. Vous pouvez réduire vos coûts de stockage en sauvegardant ces tables sur Cloud Storage puis en les supprimant de BigQuery (ou en ajustant les paramètres d'expiration).
Récemment, un client s'est appuyé sur cette recommandation pour identifier diverses tables contenant des données vieilles de plus de 3 ans qui n'étaient plus interrogées. Après les avoir sauvegardées et supprimées, il a vu ses coûts BigQuery diminuer d'environ 30 %.
Imposer les champs de partitionnement dans vos requêtes
Partitionner vos tables ne représente que la moitié du chemin. Une fois le partitionnement en place, encore faut-il que ces tables soient interrogées efficacement, en utilisant le champ sur lequel la table est partitionnée. Vous gagnez ainsi en maîtrise des coûts en ne scannant que de plus petites portions de la table plutôt que l'intégralité.
Or, lorsque vous gérez une équipe d'analystes de données, il est difficile de savoir si chacun inclut bien le champ partitionné dans ses requêtes. BigQuery Lens identifie les jobs qui interrogent des tables partitionnées sans utiliser le champ partitionné.
Réduire les coûts flat-rate en décalant les jobs récurrents
Optimiser ses coûts flat-rate, c'est un peu comme jouer à Tetris. L'objectif : stabiliser votre usage et obtenir des " blocs " plats de consommation horaire de slots.
Or, la plupart du temps, votre usage horaire moyen de slots présente des pics et des creux (voir le graphique ci-dessous). Vous risquez de baser vos achats de slots sur cet usage irrégulier et de dépenser plus que nécessaire.
Pour réduire vos coûts flat-rate, repérez les jobs récurrents qui s'exécutent à ces heures de pointe et déplacez-les (si possible) vers des heures où l'usage moyen est faible, ou provisionnez des Flex Slots pour absorber la charge supplémentaire.
Vous lissez ainsi les pics et obtenez un usage de slots plus bas et plus régulier. Résultat : vous achetez moins de slots et vos coûts flat-rate baissent sur la durée.
BigQuery Lens affiche les requêtes exécutées plus de 30 fois par mois sur les projets en flat-rate, avec leur heure d'exécution et le nombre de slots consommés.
Vous pouvez ensuite repérer les requêtes exécutées en heures de pointe et déterminer si vous pouvez les déplacer vers des heures creuses. En reprenant le graphique ci-dessus, vous devriez identifier les requêtes exécutées à 4 h ou 16 h et, si possible, les décaler à 7 h ou 20 h.
Comment obtenir BigQuery Lens
Comme pour tout ce qui touche au cloud public, si vous n'êtes pas attentif à votre usage de BigQuery, les coûts peuvent grimper rapidement. Et comme BigQuery est au cœur de la stratégie data de nombreuses entreprises, il n'est guère étonnant qu'il fasse partie des sujets qui reviennent le plus dans les tickets de nos clients.
Il est donc essentiel d'optimiser en permanence coûts et performances. Et il est tout aussi crucial de comprendre comment votre équipe utilise BigQuery, car on ne peut pas optimiser ce que l'on ne connaît pas. C'est précisément ce que BigQuery Lens vous permet de faire.
Si vous n'êtes pas client DoiT et souhaitez accéder à BigQuery Lens et à nos experts BigQuery, contactez-nous.
Si vous êtes déjà client DoiT, pensez à activer BigQuery Lens si ce n'est pas déjà fait.