Accueil›Blog›Test BigQuery

Tests prêts à l'emploi

Test BigQuery : optimiser une requête coûteuse (avec la logique de coût derrière)

Sur BigQuery, on paie les données lues. Ce test vérifie la compétence la plus critique — et la plus rare — : la conscience du coût. On donne une requête qui « marche » mais scanne des téraoctets inutiles, et on regarde si le candidat sait la rendre économe. Corrigé et logique de coût inclus.

Data Builder·Juillet 2025·10 min de lecture·Test BigQuery · coût / performance · clé en main

Sommaire

La requête à optimiser
Les deux problèmes de coût
Le corrigé
Grille par niveau

Le principe à comprendre : BigQuery facture les octets scannés, pas le temps. Deux leviers réduisent la facture — sélectionner uniquement les colonnes utiles, et filtrer sur la colonne de partition. Un candidat qui l'ignore peut générer de grosses factures.

1La requête à optimiser

La consigne

« Cette requête coûte cher à chaque exécution. Réduis son coût sans changer le résultat. »

La table des commandes est partitionnée par date et contient de nombreuses colonnes. La requête ci-dessous ignore les deux leviers de coût de BigQuery.

-- Table commandes : partitionnee par date_commande, ~50 colonnes, plusieurs To
SELECT *
FROM commandes
WHERE EXTRACT(YEAR FROM date_commande) = 2024   -- fonction : ignore la partition
-- SELECT * : scanne les ~50 colonnes ; le filtre par fonction lit TOUTES les partitions

2Les deux problèmes de coût

La consigne

Chacun multiplie inutilement les octets scannés.

Un bon candidat identifie précisément pourquoi cette requête est chère, en raisonnant en octets scannés — pas en temps d'exécution.

SELECT * scanne toutes les colonnes, même celles inutiles (BigQuery est en colonnes).
EXTRACT(YEAR FROM ...) sur la date empêche l'élagage de partitions : toutes sont lues.
Bon réflexe : estimer les octets scannés avant de lancer (dry run).

3Le corrigé

La consigne

Colonnes utiles + filtre par plage de dates.

La version optimisée ne lit que les colonnes nécessaires et filtre par plage de dates, ce qui active l'élagage de partitions. Le coût peut chuter de plusieurs ordres de grandeur.

SELECT client_id, montant, date_commande     -- colonnes utiles seulement
FROM commandes
WHERE date_commande >= '2024-01-01'
  AND date_commande <  '2025-01-01'            -- filtre de partition -> elagage
-- Resultat identique, une fraction des octets scannes.

Lister les colonnes utiles au lieu de SELECT *.
Filtrer par plage de dates pour n'ouvrir que les partitions 2024.
Le candidat sait estimer/comparer le coût avant/après.

Signal d'alerte : le vrai marqueur : le candidat raisonne spontanément en octets scannés et vérifie le coût estimé (dry run) avant de lancer. Celui qui traite BigQuery comme une base classique représente un risque financier réel.

4Grille par niveau

Niveau	Maîtrise attendue	Signal GO	NO-GO
Junior	Écrit une requête correcte	Obtient le bon résultat	Lance SELECT * sans filtre
Confirmé	Sélectionne les colonnes utiles	Réduit les colonnes scannées	Ignore le partitionnement
Senior	Active l'élagage de partitions	Raisonne en octets scannés	Ne relie jamais requête et facture
Lead	Met en place des garde-fous coût	Anticipe le coût avant d'exécuter	Traite BigQuery comme une base classique

Home›Blog›BigQuery test

Ready-to-use tests

BigQuery test: optimize a costly query (with the cost logic behind it)

On BigQuery, you pay for data read. This test checks the most critical — and rarest — skill: cost-awareness. You give a query that ‘works’ but scans useless terabytes, and watch whether the candidate can make it economical. Answer and cost logic included.

Data Builder·July 2025·10 min read·BigQuery test · cost / performance · turnkey

Contents

The query to optimize
The two cost problems
The answer
Level grid

The principle to grasp: BigQuery bills scanned bytes, not time. Two levers cut the bill — selecting only useful columns, and filtering on the partition column. A candidate who ignores this can generate big bills.

1The query to optimize

The task

‘This query is expensive on every run. Cut its cost without changing the result.’

The orders table is partitioned by date and has many columns. The query below ignores both of BigQuery's cost levers.

-- Table commandes : partitionnee par date_commande, ~50 colonnes, plusieurs To
SELECT *
FROM commandes
WHERE EXTRACT(YEAR FROM date_commande) = 2024   -- fonction : ignore la partition
-- SELECT * : scanne les ~50 colonnes ; le filtre par fonction lit TOUTES les partitions

2The two cost problems

The task

Each needlessly multiplies scanned bytes.

A good candidate identifies precisely why this query is expensive, reasoning in scanned bytes — not execution time.

SELECT * scans every column, even useless ones (BigQuery is columnar).
EXTRACT(YEAR FROM ...) on the date prevents partition pruning: all are read.
Good reflex: estimate scanned bytes before running (dry run).

3The answer

The task

Useful columns + date-range filter.

The optimized version reads only the needed columns and filters by date range, enabling partition pruning. The cost can drop by several orders of magnitude.

SELECT client_id, montant, date_commande     -- colonnes utiles seulement
FROM commandes
WHERE date_commande >= '2024-01-01'
  AND date_commande <  '2025-01-01'            -- filtre de partition -> elagage
-- Resultat identique, une fraction des octets scannes.

List useful columns instead of SELECT *.
Filter by date range to open only the 2024 partitions.
The candidate can estimate/compare the cost before/after.

Warning signal : the real marker: the candidate spontaneously reasons in scanned bytes and checks the estimated cost (dry run) before running. One who treats BigQuery like a classic database is a real financial risk.

4Level grid

Level	Expected proficiency	Signal GO	NO-GO
Junior	Writes a correct query	Gets the right result	Runs SELECT * with no filter
Mid-level	Selects useful columns	Reduces scanned columns	Ignores partitioning
Senior	Enables partition pruning	Reasons in scanned bytes	Never links query to bill
Lead	Sets up cost guardrails	Anticipates cost before running	Treats BigQuery like a classic DB

Test BigQuery : optimiser une requête coûteuse (avec la logique de coût derrière)

1La requête à optimiser

2Les deux problèmes de coût

3Le corrigé

4Grille par niveau

BigQuery test: optimize a costly query (with the cost logic behind it)

1The query to optimize

2The two cost problems

3The answer

4Level grid

Vous recrutez un profil data ?