Comment réduire ses coûts Google BigQuery?
4 exemples pratiques du Modern Data Network avec BlaBlaCar, Nickel, Toucan Toco et Libeo.
Réduire la facture de son infrastructure data est une priorité des équipes Data. Le data warehouse constitue le cœur de cette infrastructure, et souvent, le levier le plus important pour réduire ses coûts.
Les tarifs BigQuery, comme ceux de la plupart des data warehouse, se composent de deux éléments principaux : l’usage (coût de l’exécution des requêtes) et le stockage (coûts de l’entreposage des données). A titre d’exemple, 1 Tb de données coûte environ $5–6 pour une requête et $20 en stockage. Néanmoins, le stockage est un coût fixe mensuel, alors que l’exécution croît en fonction de l’usage (duh logique ?), ce qui en fait le composant le plus important de la facture.
Le Modern Data Network a réuni 4 témoignages pour vous inspirer et vous aider à réduire vos coûts BigQuery. BlaBlaCar, Nickel, Toucan Toco et Libeo partagent comment suivre précisément ces coûts et les optimiser.
Contrôler les coûts opérationnels de la data par BlaBlaCar
Contrôler les coûts opérationnels au sein d’un département Data n’est pas une tâche facile. Ceci est particulièrement vrai pour les coûts associés à BigQuery, car nos utilisateurs ne sont pas toujours conscients du coût de leurs actions. Par exemple, l’exécution d’une requête sur 1 To de données dans BigQuery coûte 6,25 dollars. Lorsque vous avez des dizaines ou plus d’utilisateurs de la plateforme, le problème peut rapidement devenir incontrôlable.
En juillet 2022, nous avons remarqué une augmentation significative de nos coûts liés à BigQuery — d’environ 10% par mois. Nous dépassions alors de 25% notre budget mensuel Google Cloud Platform (GCP), et BigQuery représentait 80% de ces coûts. La cause principale identifiée : beaucoup de nos pipelines et ETL reposaient sur un code hérité ou obsolète, et ne se sont pas bien adaptés à l’évolution des besoins. Par exemple, seulement certains de nos pipelines étaient incrémentiels. Nous étions donc confrontés à une mauvaise gestion de notre base de code entraînant un manque de scalabilité.
Pour résoudre ce problème, nous avons cherché à obtenir une meilleure visibilité sur les facteurs de coûts. Nous avons réalisé que les outils existants pour monitorer nos coûts manquaient de granularité, ce qui rendait difficile l’identification de possibles réductions de coûts. En conséquence, nous avons lancé un projet, appelé Big Savings, dont l’objectif est à terme de réduire le volume de données que nous traitons, ce qui nous permettra une réduction durable des coûts à long terme.
Afin d’obtenir cette meilleure visibilité, nous nous sommes concentrés sur le labelling (clés/valeurs dans les métadonnées) de nos ETLs et des requêtes utilisées pour nos dashboards Tableau. Nous avons établi des conventions pour définir notamment des catégories et des sous-catégories, l’objectif étant de répartir les coûts en fonction de catégories spécifiques et de suivre plus efficacement notre consommation de données.
Pour les ETLs, nous avons mis à jour nos workflows dans Airflow pour incorporer automatiquement ces labels. Pour Tableau, où le labelling était plus complexe en raison de l’absence de fonctionnalité intégrée, nous avons utilisé des requêtes SQL personnalisées pour inclure des commentaires au début des requêtes, indiquant la catégorie et la sous-catégorie associées. Nous retrouvons ensuite ces informations dans les métadonnées des logs de BigQuery. De plus, nous avons créé des services accounts dédiés à chaque équipe, simplifiant ainsi la compréhension et le suivi de nos coûts.
Grâce à ce labelling complet, nous avons pu créer un dashboard de suivi des coûts, offrant aux consommateurs de données une visibilité claire des volumes de données traités, et permettant d’être alertés en cas de dépassement de notre budget. La nouvelle observabilité nous permettra d’optimiser les processus coûteux et de réagir rapidement et efficacement lors de tout changement entraînant une augmentation du volume de données traitées.
Les premiers résultats nous ont par exemple révélé que certains utilisateurs effectuaient des requêtes très coûteuses (> 30$). Une des nos premières actions a été de les informer et de les éduquer sur les bonnes pratiques Data. Nous avons également identifié certains pipelines très coûteux, que nous avons notamment optimisés en rendant leur processus de rafraîchissement incremental.
En plus du labelling, nous avons entrepris d’autres initiatives d’économies de coûts. Nous avons étudié l’utilisation des réservations et des slots de BigQuery, mais l’analyse a montré que nous ne bénéficierions probablement pas d’une réduction de coûts, et ce changement impliquait une configuration beaucoup plus complexe que celle que nous avons actuellement. Nous avons également envisagé de modifier le modèle de tarification du stockage de BigQuery, ce qui pourrait nous faire économiser 30% sur les coûts de stockage.
Nous avons réussi à réduire les coûts en nettoyant nos buckets GCS et en modifiant la classe de stockage des objets. Nous avons identifié de manière programmatique les plus gros dossiers dans les buckets GCS et supprimé des backups qui n’étaient plus nécessaires. Nous avons ainsi économisé des coûts substantiels liés au stockage de données inutilisées. En migrant les fichiers vers des classes de stockage moins chères en fonction de leur fréquence d’accès, nous avons réussi à réduire les coûts de plus de 50%.
En conclusion, il est indispensable d’avoir une vision claire et une compréhension approfondie des coûts liés au traitement des données afin de pouvoir les optimiser de manière efficace. Cela nécessite la mise en place d’une stratégie de gouvernance solide et l’utilisation d’outils appropriés. L’objectif final étant de mieux contrôler les dépenses et de prévoir avec plus de confiance les budgets futurs.
Organiser un tournoi FinOps pour réduire ses coûts dbt de 30% par Nickel
Nous avons chez Nickel plus de 1200 modèles dbt créés et maintenus par 26 data analysts répartis dans 11 équipes métiers.
Cette organisation comporte des avantages évidents pour les data analysts mais également certains risques, notamment en termes de coûts.
À mesure que le nombre de Pull Requests grandit, la quantité de modèles non optimisés ou obsolètes augmente, et représente des coûts non négligeables.
En tant qu’analytics engineer, j’ai [Remi Benoist] donc organisé un tournoi FinOps mettant en compétition les data analysts, afin d’optimiser les modèles de notre organisation.
Les modalités du tournoi
- Toutes les optimisations de modèles sont proposées via des Pull Requests.
- L’optimisation réalisée en GB/mois est calculée grâce aux logs BQ et dbt.
- Le data analyst qui pousse la Pull Request remporte les GB/mois optimisés.
Chaque data analyst peut optimiser le modèle de l’organisation qu’il souhaite, à condition que l’owner du modèle puisse vérifier si la Pull Request lui convient.
Le top 3 du tournoi remporte des prix : un repas offert pour le 3ème et le 2ème, un Google Nest pour le 1er ainsi que son portrait sous forme de poster dans nos bureaux.
Le tournoi dure 2 mois et la remise des prix se fera à l’occasion d’un événement bi-annuel réunissant tous les professionnels de la data chez Nickel.
Déroulement et résultats
Pendant le tournoi, j’ai envoyé des communications hebdomadaires par mail, afin de donner des conseils d’optimisation aux data analysts (partitionnement, clustering, modèles incrémentaux, optimisation des cron…).
Assurer un suivi avec les data analysts s’est avéré constructif. Leur donner des idées, des challenges, voire les aider à optimiser des modèles ensemble a permis de réaliser un travail conséquent. Un dashboard recensant le coût de nos modèles nous permettait de prioriser nos actions.
Au final, plus de 46 modèles ont été optimisés en 2 mois, représentant une optimisation de 288 To/mois soit 30% de la consommation de dbt. Ce tournoi a également permis de sensibiliser les data analysts aux pratiques FinOps et aux différentes techniques pour créer des modèles optimisés.
Aujourd’hui les coûts des modèles sont en permanence surveillés via un dashboard dédié et la CI/CD de nos Pull Requests.
Suivre les coûts de son data warehouse par Toucan Toco
Chez Toucan, on s’est simplement concentrés pour le moment sur la mise en place d’un tableau de bord plutôt simple pour suivre l’évolution de nos coûts de notre data warehouse BigQuery.
Pour cela nous avons rassemblé plusieurs sources de données concernant :
- Le stockage: liste de toutes les tables et datasets qui composent notre data warehouse.
- L’usage: les informations concernant les requêtes effectuées par des utilisateurs ou comptes de service.
- La facturation: les données de facturation par service et produit.
Cela nous permet de suivre notre usage et coûts associés de manière régulière. Nous avons également ajouté plusieurs autres reportings pour avoir le détails dont notamment un qui nous permet de lister les requêtes les plus coûteuses. On peut alors regarder le contenu de chaque requête et essayer de les optimiser.
Par exemple, nous nous sommes rendus compte que certains outils faisaient un scan de tout le data warehouse lors de la configuration ou modification des informations de connexion. Ce genre de requête est très coûteuse surtout lorsqu’on a un data warehouse qui contient un grand nombre de tables et de colonnes. Une optimisation simple mise en place a consisté à limiter l’accès à un nombre restreint de datasets.
Nous essayons aussi de vérifier l’application de quelques bonnes pratiques (dont notamment celles partagées par Google Cloud).
- Eviter au maximum dans les requêtes de sélectionner toutes les colonnes de chaque table via `SELECT *`
- Créer des partitions sur les tables et utiliser ces partitions pour filtrer.
- Utiliser le cache au maximum et donc éviter les `WHERE date = NOW()`.
Nous avons aussi mis en place un système d’alerte lorsque :
- Un compte de service requête subitement plus de données d’un jour à l’autre.
- Un utilisateur dépasse son quota de requête pour la journée (valeur que l’on définit arbitrairement, mais nous ne pouvons pas bloquer l’utilisateur sur BigQuery).
Réduire de 40% ses coûts avec un monitoring simple par Libeo
Au début de l’année 2023, l’équipe Data de Libeo s’est pour la première fois fixée comme objectif de réduire les coûts de sa stack.
L’équipe Data est composée de 5 personnes (1 manager, 2 Data Analyst, 1 Data Engineer et 1 Data Scientist). La stack est assez standard pour une scale-up :
- Ingestion : Fivetran.
- Data warehouse : BigQuery.
- Modélisation : dbt (version core) avec Airflow comme scheduler.
- BI : Metabase (version open source).
Sans surprise, le levier avec le plus d’impact (hors ingestion car nous étions engagés) est de réduire les coûts de notre BigQuery, et en particulier les coûts liés à nos modèles dbt (environ 700 à l’époque).
La première initiative a été de mettre en place un monitoring simple sur Metabase pour suivre précisément le coût des modèles dbt et savoir par où commencer pour maximiser notre impact.
Nous avons construit un dashboard pour suivre chaque semaine :
- Le volume moyen (gbyte) processé à chaque run pour chacun de nos modèles dbt.
- Le volume total processé par modèle et son poids parmis tous nos modèles dbt.
Avec ces 3 informations, nous avons classé nos modèles du plus cher au moins cher. Et sans surprise aussi ici, une minorité de modèles représentait une part importante des coûts. C’est donc par eux que nous avons commencé !
La seconde initiative a été de refactorer la modélisation des modèles identifiés précédemment afin de les optimiser ou de les supprimer si leur utilisation ne justifiait pas le coût. Nous avions par exemple un modèle agrégeant plusieurs events de tracking pour éviter les multiples jointures pour les data analysts et les utilisateurs self-service. Or ce modèle était majoritairement utilisé pour filtrer sur un event unique sans clustering qui aurait limité le volume de données traitées… Ce modèle a donc été supprimé.
Pour les modèles restants, la troisième initiative a consisté à réduire le nombre de run des modèles trop gourmands à un par jour maximum.
Dans notre processus de développement, chaque analyste peut tester et lancer tous nos modèles dbt plusieurs fois par jour. Notre CI/CD lance également beaucoup de modèles dbt dès qu’une modification est effectuée dans la codebase. Ce système fonctionne bien si les modèles sont petits et rapides à exécuter, mais pour les plus conséquents cela coûte cher (en plus de ralentir la pipeline). Nous avons donc fait le choix de ne les lancer qu’une seule fois par jour : ils sont désormais exclus par défaut des runs des environnements en local des analystes et de la CI/CD.
Un nouveau standard pour l’équipe
Nous partions de loin et ces premières initiatives ont permis de réduire nos coûts BigQuery de 40% mais surtout d’inclure ce monitoring dans nos standards d’équipe. Il est maintenant regardé de manière hebdomadaire et les modèles dbt sont optimisés régulièrement.
Aller plus loin
Maîtriser sa facture BigQuery est un sujet complexe. Nous espérons que ces techniques peuvent aider votre équipe à économiser de l’argent et à éviter les surprises en fin de mois. Qui ne souhaite pas annoncer à son équipe Finance et aux autres équipes une réduction de sa facture infra ?
N’hésitez pas à partager vos approches et feedback — surtout si vous utilisez Snowflake ;)
PS : Mixpanel a partagé un super article sur le même sujet.
