ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Anti-patterns de migration vers les Editions BigQuery

Cinq erreurs commises par les équipes lors de la migration de BigQuery à la demande vers les Editions — et comment les éviter.

Planté
bigquerygcpcost optimizationdata engineering

La migration de BigQuery à la demande vers les Editions est techniquement simple — créer une réservation, créer une affectation. Réussir la configuration est plus difficile. Les mêmes anti-patterns apparaissent systématiquement et entraînent des dépassements de coûts significatifs ou des régressions de performance.

Anti-pattern 1 : Surprovisionnement du nombre maximum de slots

L’autoscaler optimise la vitesse des requêtes, pas le coût. Configurez max_slots à 1 600 et BigQuery montera régulièrement à 1 600 même pour des requêtes qui s’exécuteraient correctement à 400. Il utilise le plafond que vous lui donnez pour minimiser la latence.

L’expérience d’une équipe d’ingénierie : elle a défini max_slots = 1600 car les charges de pointe en avaient parfois besoin. En pratique, BigQuery montait fréquemment à 1 600 slots, souvent pour des requêtes où seules les requêtes P99 avaient réellement besoin de cette capacité.

La solution : Définissez le nombre maximum de slots sur votre utilisation historique P90, pas P99 ni votre pic absolu. Utilisez la requête d’histogramme de slots pour comprendre votre distribution :

WITH hourly_slots AS (
  SELECT
    TIMESTAMP_TRUNC(period_start, HOUR) AS hour,
    SUM(period_slot_ms) / 1000 / 3600 AS slots_consumed
  FROM `region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
  WHERE
    job_creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
    AND (statement_type != 'SCRIPT' OR statement_type IS NULL)
  GROUP BY hour
)
SELECT
  ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(90)]) AS p90_slots,
  ROUND(APPROX_QUANTILES(slots_consumed, 100)[OFFSET(99)]) AS p99_slots,
  ROUND(MAX(slots_consumed)) AS max_slots
FROM hourly_slots;

Commencez au P90. L’autoscaler gère les pics occasionnels de manière acceptable ; vous n’avez pas besoin d’une capacité permanente pour chaque pic possible. Augmentez le maximum plus tard si vous observez une contention de slots persistante. L’augmentation est immédiate, alors que la réduction d’un nombre de slots engagés nécessite d’attendre le renouvellement.

Anti-pattern 2 : Ignorer la fenêtre de facturation minimale de 60 secondes

Une requête de 100 slots qui se termine en 5 secondes est facturée pour 100 slot-minutes, pas 8,3 slot-secondes. C’est la fenêtre d’autoscaling de 60 secondes — les slots restent alloués pendant au minimum 60 secondes après un événement de mise à l’échelle avant que BigQuery ne réduise la capacité.

Cela rend les Editions relativement coûteuses pour les charges composées de nombreuses requêtes courtes. Si votre pattern habituel est constitué de milliers d’opérations inférieures à la minute — outils BI interactifs, exploration de données, micro-requêtes pilotées par API — le minimum de 60 secondes gonfle considérablement les coûts par rapport aux calculs théoriques. L’écart entre la théorie et la réalité s’accentue à mesure que la durée des requêtes diminue.

La solution : Identifiez la distribution des durées de vos requêtes avant de migrer :

SELECT
  EXTRACT(HOUR FROM creation_time) AS hour_of_day,
  COUNT(*) AS query_count,
  ROUND(AVG(TIMESTAMP_DIFF(end_time, start_time, SECOND)), 1) AS avg_duration_sec,
  COUNTIF(TIMESTAMP_DIFF(end_time, start_time, SECOND) < 60) AS queries_under_60sec,
  ROUND(COUNTIF(TIMESTAMP_DIFF(end_time, start_time, SECOND) < 60) / COUNT(*) * 100, 1) AS pct_under_60sec
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
GROUP BY hour_of_day
ORDER BY hour_of_day;

Si plus de 50 % de vos requêtes se terminent en moins de 60 secondes, appliquez un multiplicateur de 2× ou plus aux coûts théoriques en slots plutôt que le multiplicateur standard de 1,5×. Pour les charges dominées par des requêtes inférieures à la minute, rester sur la tarification à la demande ou maintenir cette population de requêtes en mode à la demande via une approche hybride est généralement la bonne décision.

Anti-pattern 3 : Migrer sans optimiser les requêtes au préalable

Les requêtes inefficaces consommant trop de slots ne s’améliorent pas avec les Editions. Elles consomment simplement plus rapidement votre capacité réservée. Une requête scannant 10 TiB alors qu’elle pourrait en scanner 100 GiB avec un bon partitionnement gaspille des slots tout comme elle gaspille des octets.

Avec la tarification à la demande, chaque requête inefficace apparaît comme une ligne sur votre facture — vous ressentez directement le gaspillage. Avec les Editions, les requêtes inefficaces consomment silencieusement votre capacité de réservation, ralentissant les autres requêtes par contention de slots plutôt que d’apparaître comme des coûts explicites. Le gaspillage est plus difficile à voir et plus facile à ignorer.

La solution : Optimisez avant de migrer. Mettez en place le partitionnement, le clustering et la sélection de colonnes sur vos tables les plus coûteuses. Le travail d’optimisation des requêtes paie des dividendes quel que soit le modèle tarifaire, mais c’est particulièrement important avec les Editions car vous payez pour la capacité de compute qu’elle soit utilisée efficacement ou non.

Exécutez cette requête sur votre INFORMATION_SCHEMA pour trouver les meilleurs candidats :

SELECT
  user_email,
  job_id,
  SUBSTR(query, 1, 200) AS query_preview,
  ROUND(total_bytes_billed / POW(1024, 4) * 6.25, 2) AS estimated_cost_usd,
  ROUND(total_slot_ms / 1000 / 3600, 3) AS slot_hours,
  TIMESTAMP_DIFF(end_time, start_time, SECOND) AS duration_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
ORDER BY total_bytes_billed DESC
LIMIT 25;

Corrigez les requêtes les plus coûteuses avant de migrer. Les requêtes qui coûtent le plus en mode à la demande consommeront le plus de slots avec les Editions — et le retour d’information sur les coûts est plus visible en mode à la demande.

Anti-pattern 4 : Souscrire des engagements sans tester au préalable

Les engagements d’un et trois ans offrent respectivement 20 % et 40 % de réduction, mais ils vous bloquent sur des nombres de slots qui peuvent ne pas correspondre aux besoins réels. Un engagement souscrit sur la base d’estimations s’avère souvent incorrect en pratique — soit trop important (vous payez trop pour une capacité inutilisée) soit trop faible (générant une contention que vous n’aviez pas anticipée).

La remise et le blocage sont tous deux réels. Un engagement d’un an pour 500 slots Enterprise à 0,048 $/slot-heure vous coûte 210 240 $ sur l’année. Si vous découvrez après le deuxième mois que vous n’aviez en réalité besoin que de 300 slots, vous avez contracté 0,048 × 200 slots excédentaires × ~9 000 heures restantes = ~86 400 $ de surcoût dont vous ne pouvez pas vous défaire.

La solution : Testez d’abord avec le paiement à l’usage pendant 30 jours ou plus. Exécutez des charges représentatives (pas seulement un échantillon — incluez vos fenêtres ETL, vos heures de pointe BI, vos jobs par lots mensuels) et observez la consommation réelle de slots. Souscrivez ensuite des engagements sur la base de données observées, non d’estimations. Voir Tester les Editions BigQuery sans engagement pour le workflow complet test-puis-engagement.

Si votre analyse montre que vous avez besoin de 200 slots de base avec des pics à 600, engagez-vous sur 150 à 200 slots et laissez l’autoscaling gérer le reste. La remise d’engagement sur les slots de base plus le paiement à l’usage pour les pics bat souvent un engagement sur la capacité de pointe que vous utilisez rarement.

Anti-pattern 5 : Faire passer toutes les charges par une seule réservation

Les jobs ETL, les tableaux de bord BI et l’exploration ad hoc ont des caractéristiques de consommation de slots fondamentalement différentes. L’ETL s’exécute sur des plannings prévisibles avec un compute soutenu et intensif. Les tableaux de bord nécessitent une faible latence mais une capacité sporadique. Les requêtes ad hoc sont imprévisibles en termes de timing et de besoins en ressources.

Quand toutes ces charges partagent une seule réservation, elles se disputent le même pool de slots. Un job ETL lourd peut affamer les requêtes interactives des tableaux de bord. Un analyste exécutant un scan ad hoc coûteux peut retarder un pipeline planifié. La réservation devient un goulot d’étranglement plutôt qu’une garantie de capacité.

La solution : Séparez les projets par type de charge et appliquez les modèles tarifaires ou configurations de réservation appropriés à chacun :

  • À la demande pour les requêtes ad hoc et le développement : les patterns sporadiques favorisent la tarification par TiB. Les projets sans affectation de réservation utilisent automatiquement la tarification à la demande.
  • Enterprise Edition avec slots engagés pour l’ETL planifié : le compute soutenu avec un timing prévisible est là où les Editions offrent le plus d’économies.
  • Une réservation séparée avec pondération de priorité pour les tableaux de bord BI : capacité modérée avec autoscaling pour gérer la charge utilisateur concurrente.

Vous pouvez également créer plusieurs réservations au sein d’un même setup Editions, en affectant différents maximums de slots et priorités à différents types de charges. Cela empêche un job ETL coûteux d’affamer les requêtes interactives tout en bénéficiant des avantages tarifaires des slots pour vos charges les plus lourdes.

La hiérarchie des réservations — engagements → réservations → affectations — est conçue exactement pour ce pattern. La couche d’affectation achemine différents projets GCP vers différentes réservations sans aucune modification au niveau de l’application. Votre projet dbt de production utilise les slots de la réservation ETL ; votre projet Looker utilise la réservation BI. Aucun des deux projets ne connaît ni ne se soucie du routage.