Accueil›Blog›Test technique optimisation des coûts cloud data : FinOps pour la data

Guide recrutement data

Test technique optimisation des coûts cloud data : FinOps pour la data

Les coûts cloud data peuvent exploser sans contrôle. En entretien Senior et Lead, on évalue la capacité à architecturer pour la performance ET l économie.

Data Builder·Juin 2025·6 min de lecture·Data Engineer · Data Architect

Sommaire

Optimiser Snowflake
Optimiser BigQuery
Optimiser Databricks
Optimiser le stockage S3/GCS
Monitorer et alerter sur les coûts
Culture FinOps data
Grille

1Réduire les coûts Snowflake

Question discriminante

Quelles sont les 5 leviers principaux pour réduire les coûts Snowflake ?

1. Auto-suspend agressif — 1 minute pour les warehouses ETL (jobs courts), 5-10 minutes pour les warehouses BI (utilisateurs en session)
2. Incremental models dbt — éviter les full refreshes sur les grandes tables. Économise 80-90% du compute de transformation
3. Warehouse sizing approprié — commencer petit (XS) et scaler uniquement si les requêtes sont lentes. Un M ne va pas 2x plus vite qu un S
4. Result cache — les requêtes identiques retournent le cache 24h. Standardiser les requêtes BI pour maximiser les hits
5. Resource monitors — configurer des alertes et des limites de dépenses par warehouse et par mois

2Réduire les coûts BigQuery

Question discriminante

Quels sont les pièges de coûts BigQuery les plus fréquents et comment les éviter ?

-- PIÈGE 1 : SELECT * sur une table partitionnée
-- Mauvais : scanne toutes les colonnes et toutes les partitions
SELECT * FROM project.dataset.orders;

-- Bon : sélectionner les colonnes nécessaires + filtrer la partition
SELECT order_id, amount, customer_id
FROM project.dataset.orders
WHERE DATE(order_date) >= '2025-01-01';  -- filtre la partition

-- PIÈGE 2 : Pas de require_partition_filter
-- Un utilisateur peut scanner 1TB par accident
ALTER TABLE orders
SET OPTIONS (require_partition_filter = TRUE);

-- PIÈGE 3 : Jointure sans filtre préalable
-- Mauvais : jointure sur les tables entières
SELECT * FROM big_table JOIN other_big_table USING (id);

-- Bon : filtrer avant de joindre
SELECT * FROM
(SELECT * FROM big_table WHERE date > '2025-01-01') a
JOIN (SELECT * FROM other_big_table WHERE active = TRUE) b
USING (id);

3Optimiser Databricks / Spark

Question discriminante

Comment réduisez-vous les coûts Databricks en production ?

Spot/Preemptible nodes — utiliser des instances spot pour les workers des jobs batch. 60-80% moins cher. Configurer le retry automatique
Job clusters vs interactive — toujours utiliser des job clusters pour la production (créés/détruits à chaque job). Ne pas laisser des clusters all-purpose tourner
Photon engine — active sur les clusters SQL. 2-5x plus rapide = moins de DBU consommées
Instance pools — pré-allouer des instances en stand-by pour réduire le startup time sans laisser tourner des clusters
Auto-termination — configurer une terminaison automatique après N minutes d inactivité sur tous les clusters

4Optimiser le stockage S3/GCS

Question discriminante

Le stockage S3 semble cheap mais peut coûter cher. Quels sont les pièges ?

Requêtes LIST sur S3 — les opérations LIST sont facturées. Un job Spark qui liste des milliers de partitions peut coûter cher
Small files — des millions de fichiers de 1KB = millions de requêtes S3 = coût élevé + lenteur. Compacter régulièrement
Storage classes — S3 Intelligent-Tiering pour les données rarement accédées. S3 Glacier pour l archivage
Data transfer — les transferts inter-région et vers internet sont facturés. Garder les données et le compute dans la même région
Versioning non contrôlé — S3 Versioning + beaucoup d écritures = accumulation silencieuse. Configurer des lifecycle rules

5Monitorer les coûts en temps réel

Question discriminante

Comment mettez-vous en place un monitoring des coûts cloud pour votre équipe data ?

Resource monitors Snowflake — alertes à 50%, 75%, 90% du budget mensuel par warehouse
BigQuery INFORMATION_SCHEMA — requêter les octets facturés par utilisateur et par projet quotidiennement
AWS Cost Explorer / GCP Billing — labels sur les ressources (équipe, projet, environnement) pour ventiler les coûts
Budget alerts — alertes email/Slack quand le budget prévisionnel dépasse X% du budget mensuel
Dashboard FinOps — un dashboard hebdomadaire partagé avec l équipe : coûts par outil, trend, anomalies

6Culture FinOps : rendre les coûts visibles

Question discriminante

Comment diffusez-vous la culture FinOps dans une équipe data ?

Rendre les coûts visibles — afficher les coûts par job dbt, par modèle, par utilisateur. Les gens optimisent ce qu ils voient
Attribution des coûts — facturer les coûts cloud aux équipes métier qui consomment les données. Crée une pression naturelle à l optimisation
Code review FinOps — inclure une revue des coûts estimés dans le processus de PR pour les gros modèles dbt
Champion FinOps — désigner un référent FinOps dans l équipe data qui suit les tendances et propose des optimisations

-- BigQuery : couts par equipe via labels
SELECT
    labels.value AS team,
    SUM(total_bytes_billed) / POW(1024, 4) AS tb_billed,
    SUM(total_bytes_billed) / POW(1024, 4) * 5 AS cost_usd_estimated,
    COUNT(*) AS query_count
FROM `region-eu`.INFORMATION_SCHEMA.JOBS_BY_PROJECT,
    UNNEST(labels) AS labels
WHERE labels.key = 'team'
  AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY 1 ORDER BY 3 DESC;

-- Snowflake : Resource Monitor par departement
CREATE RESOURCE MONITOR data_team_budget
    WITH CREDIT_QUOTA = 500
    TRIGGERS ON 80 PERCENT DO NOTIFY
             ON 100 PERCENT DO SUSPEND_IMMEDIATE;
ALTER WAREHOUSE DATA_TEAM_WH SET RESOURCE_MONITOR = data_team_budget;

FinOps pilliers - Visibility (qui depense quoi), Optimization (reduire le gaspillage), Governance (budgets et alertes). Impossible d optimiser sans visibilite
Tagging obligatoire - tagger toutes les ressources cloud des la creation (team, project, environment). Impossible a rattraper apres coup
Spot/preemptible pour le batch - economie 60-90% pour les jobs Spark, Dataflow, EMR qui peuvent etre interrompus. Configurer un checkpoint et fallback on-demand
Rightsizing - analyser l utilisation CPU/memoire reelle sur 30 jours. Un warehouse M utilise a 20% en CPU = redimensionner en XS
Reserved vs on-demand - reserver 1 ou 3 ans pour les ressources stables. Economie 30-60% vs on-demand

7Grille par niveau

Niveau	Maitrise	Signal GO	NO-GO
Confirmé	Auto-suspend Snowflake, évite SELECT *, partitionnement BigQuery	Configure l auto-suspend, filtre toujours les partitions BigQuery	Ne sait pas combien coûtent ses requêtes BigQuery
Senior	Spot nodes, resource monitors, incremental models, monitoring coûts	A réduit les coûts de son équipe de façon mesurable, monitore les coûts hebdomadairement	N a jamais regardé les coûts cloud de ses pipelines

1Reducing Snowflake Costs

Discriminating question

What are the 5 main levers to reduce Snowflake costs?

1. Aggressive auto-suspend — 1 minute for ETL warehouses (short jobs), 5-10 minutes for BI warehouses (users in session)
2. dbt incremental models — avoid full refreshes on large tables. Saves 80-90% of transformation compute
3. Appropriate warehouse sizing — start small (XS) and scale only if queries are slow. An M is not 2x faster than an S
4. Result cache — identical queries return the cache for 24h. Standardize BI queries to maximize cache hits
5. Resource monitors — configure alerts and spending limits per warehouse and per month

2Reducing BigQuery Costs

Discriminating question

What are the most common BigQuery cost pitfalls and how do you avoid them?

-- PIÈGE 1 : SELECT * sur une table partitionnée
-- Mauvais : scanne toutes les colonnes et toutes les partitions
SELECT * FROM project.dataset.orders;

-- Bon : sélectionner les colonnes nécessaires + filtrer la partition
SELECT order_id, amount, customer_id
FROM project.dataset.orders
WHERE DATE(order_date) >= '2025-01-01';  -- filtre la partition

-- PIÈGE 2 : Pas de require_partition_filter
-- Un utilisateur peut scanner 1TB par accident
ALTER TABLE orders
SET OPTIONS (require_partition_filter = TRUE);

-- PIÈGE 3 : Jointure sans filtre préalable
-- Mauvais : jointure sur les tables entières
SELECT * FROM big_table JOIN other_big_table USING (id);

-- Bon : filtrer avant de joindre
SELECT * FROM
(SELECT * FROM big_table WHERE date > '2025-01-01') a
JOIN (SELECT * FROM other_big_table WHERE active = TRUE) b
USING (id);

3Optimizing Databricks / Spark

Discriminating question

How do you reduce Databricks costs in production?

Spot/Preemptible nodes — use spot instances for batch job workers. 60-80% cheaper. Configure automatic retry
Job clusters vs interactive — always use job clusters for production (created/destroyed for each job). Do not leave all-purpose clusters running
Photon engine — enabled on SQL clusters. 2-5x faster = fewer DBUs consumed
Instance pools — pre-allocate standby instances to reduce startup time without leaving clusters running
Auto-termination — configure automatic termination after N minutes of inactivity on all clusters

4Optimizing S3/GCS Storage

Discriminating question

S3 storage seems cheap but can get expensive. What are the pitfalls?

LIST requests on S3 — LIST operations are billed. A Spark job that lists thousands of partitions can be costly
Small files — millions of 1KB files = millions of S3 requests = high cost + slowness. Compact regularly
Storage classes — S3 Intelligent-Tiering for rarely accessed data. S3 Glacier for archiving
Data transfer — cross-region and internet transfers are billed. Keep data and compute in the same region
Uncontrolled versioning — S3 Versioning + heavy writes = silent accumulation. Configure lifecycle rules

5Monitoring Costs in Real Time

Discriminating question

How do you set up cloud cost monitoring for your data team?

Snowflake resource monitors — alerts at 50%, 75%, 90% of the monthly budget per warehouse
BigQuery INFORMATION_SCHEMA — query billed bytes per user and per project on a daily basis
AWS Cost Explorer / GCP Billing — labels on resources (team, project, environment) to break down costs
Budget alerts — email/Slack alerts when the projected budget exceeds X% of the monthly budget
FinOps dashboard — a weekly dashboard shared with the team: costs per tool, trend, anomalies

6FinOps Culture: Making Costs Visible

Discriminating question

How do you spread FinOps culture within a data team?

Making costs visible — display costs per dbt job, per model, per user. People optimize what they can see
Cost attribution — charge cloud costs to the business teams consuming the data. Creates natural pressure to optimize
FinOps code review — include an estimated cost review in the PR process for large dbt models
FinOps champion — designate a FinOps lead within the data team who tracks trends and proposes optimizations

-- BigQuery : couts par equipe via labels
SELECT
    labels.value AS team,
    SUM(total_bytes_billed) / POW(1024, 4) AS tb_billed,
    SUM(total_bytes_billed) / POW(1024, 4) * 5 AS cost_usd_estimated,
    COUNT(*) AS query_count
FROM `region-eu`.INFORMATION_SCHEMA.JOBS_BY_PROJECT,
    UNNEST(labels) AS labels
WHERE labels.key = 'team'
  AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY 1 ORDER BY 3 DESC;

-- Snowflake : Resource Monitor par departement
CREATE RESOURCE MONITOR data_team_budget
    WITH CREDIT_QUOTA = 500
    TRIGGERS ON 80 PERCENT DO NOTIFY
             ON 100 PERCENT DO SUSPEND_IMMEDIATE;
ALTER WAREHOUSE DATA_TEAM_WH SET RESOURCE_MONITOR = data_team_budget;

FinOps pillars - Visibility (who spends what), Optimization (reduce waste), Governance (budgets and alerts). Impossible to optimize without visibility
Mandatory tagging - tag all cloud resources at creation time (team, project, environment). Impossible to catch up on afterwards
Spot/preemptible for batch - 60-90% savings for Spark, Dataflow, EMR jobs that can be interrupted. Configure checkpointing and on-demand fallback
Rightsizing - analyze actual CPU/memory usage over 30 days. An M warehouse used at 20% CPU = resize to XS
Reserved vs on-demand - reserve 1 or 3 years for stable resources. 30-60% savings vs on-demand

7Level Grid

Level	Mastery	GO Signal	NO-GO
Mid-level	Snowflake auto-suspend, avoids SELECT *, BigQuery partitioning	Configures auto-suspend, always filters BigQuery partitions	Does not know how much their BigQuery queries cost
Senior	Spot nodes, resource monitors, incremental models, cost monitoring	Has measurably reduced their team's costs, monitors costs weekly	Has never looked at the cloud costs of their pipelines

Vous recrutez un Data Engineer FinOps ?

Premier entretien gratuit. Rapport GO/NO-GO sous 48h.

Tester gratuitement Reserver un appel