Aller au contenu principal

Module 3 — Données sur Cloud Storage et BigQuery

Vertex AI ne stocke pas vos données. Il les lit dans les deux magasins natifs de GCP : Cloud Storage pour les objets (fichiers, images, artefacts) et BigQuery pour les tables analytiques. Ce module apprend à faire circuler les données entre les deux, sans exploser la facture et sans matérialiser inutilement.

Buckets et formats​

Un bucket est un espace nommé, unique dans l'univers Google. Notre équipe fraude en tient trois, chacun dans la même région que Vertex :

BucketContenuCycle de vie
gs://paiement-fraude-donneesExtractions d'entraînement, jeux figésRetention 90 jours
gs://paiement-fraude-modelesArtefacts de modèle, poidsRetention permanente
gs://paiement-fraude-logsJournaux de prédictionNearline après 30 jours

Une règle simple : un bucket par usage. Cela permet de fixer des politiques IAM et des cycles de vie différents, et de retrouver ce qui coûte quoi dans la facture. Créer un bucket :

gcloud storage buckets create gs://paiement-fraude-donnees \
  --location=europe-west1 \
  --uniform-bucket-level-access \
  --public-access-prevention

Les deux dernières options ne sont pas optionnelles. --uniform-bucket-level-access empêche que quelqu'un applique des ACL par objet, incompatibles avec l'audit. --public-access-prevention interdit toute exposition publique, même par erreur.

Pour le format, Parquet l'emporte pour l'entraînement : compressé, orienté colonnes, lu directement par pandas, Spark et Vertex sans conversion. CSV reste courant pour l'échange mais coûte trois à cinq fois plus en stockage et transferts. TFRecord s'impose pour les gros jeux d'images en TensorFlow.

Le jeu de données Vertex​

Vertex propose un concept de Dataset managé qui catalogue les jeux d'entraînement. Ce n'est pas une base : c'est une entrée de registre qui pointe vers un chemin GCS ou une table BigQuery, avec un schéma déclaré. L'utilité est essentiellement traçable — l'entraînement du module 4 y sera rattaché, le lignage remonte jusqu'au jeu utilisé.

from google.cloud import aiplatform

aiplatform.init(project="paiement-fraude-prod", location="europe-west1")

dataset = aiplatform.TabularDataset.create(
    display_name="transactions-2026-q3",
    bq_source="bq://paiement-fraude-prod.transactions.entrainement_2026_q3",
)

Notre plateforme préfère souvent gérer les jeux à la main, mais l'inscription en Dataset reste utile pour l'audit interne du régulateur.

Requêter BigQuery vers un DataFrame​

Le module 2 a montré la magic %%bigquery pour l'exploration. Pour un usage programmatique, le client Python est plus flexible :

from google.cloud import bigquery

client = bigquery.Client(project="paiement-fraude-prod")

requete = """
SELECT
  id_transaction,
  montant,
  pays_carte,
  pays_marchand,
  canal,
  age_compte_jours,
  nb_transactions_24h,
  est_fraude
FROM `paiement-fraude-prod.transactions.transactions_enrichies`
WHERE DATE(horodatage) BETWEEN '2026-06-01' AND '2026-08-31'
  AND est_fraude IS NOT NULL
"""

df = client.query(requete).to_dataframe(progress_bar_type="tqdm")

Sur une plage de trois mois, la requête ramène environ douze millions de lignes dans le carnet. C'est encore raisonnable pour pandas sur n1-standard-4 (16 Go de RAM), pas au-delà.

Le coût, à connaître à l'avance​

BigQuery facture à la donnée scannée, pas au temps ni au résultat. Le tarif standard est de 6,25 $ par téraoctet scanné. Notre table transactions_enrichies fait 900 Go ; un SELECT * sur toute la table coûterait 5,60 $ — à chaque exécution. Le même SELECT filtré sur trois mois et sept colonnes ne scanne que 42 Go, soit 0,26 $.

Deux réflexes découlent de cette règle :

  • Nommer les colonnes, jamais SELECT *. BigQuery est en colonnes : lire trois colonnes sur quarante divise le coût par presque quinze.
  • Partitionner par DATE(horodatage) à la création de la table. Un filtre sur WHERE horodatage BETWEEN ... élague alors les partitions non concernées, ce qui devient l'économie principale sur une table de plusieurs téraoctets.

La commande bq query --dry_run estime le coût sans exécuter :

bq query --nouse_legacy_sql --dry_run \
  'SELECT * FROM `paiement-fraude-prod.transactions.transactions_enrichies` LIMIT 10'

À utiliser en réflexe avant toute requête qui pourrait être coûteuse.

Exporter pour l'entraînement​

Le CustomTrainingJob du module 4 lira ses données depuis Cloud Storage, pas depuis BigQuery — c'est plus rapide et surtout reproductible (l'entraînement du 3 octobre doit lire les mêmes données que celui du 4 octobre). L'export se fait en une commande :

job_export = client.query("""
EXPORT DATA
OPTIONS(
  uri='gs://paiement-fraude-donnees/entrainement/2026-q3/*.parquet',
  format='PARQUET',
  overwrite=true,
  compression='SNAPPY'
) AS
SELECT * FROM `paiement-fraude-prod.transactions.entrainement_2026_q3`
""").result()

Le * dans l'URI est indispensable : BigQuery écrit en plusieurs fichiers, un par fragment interne, ce qui accélère la lecture parallèle par l'entraînement.

Découpage train / validation / test​

Une erreur fréquente est de découper aléatoirement un jeu chronologique. Pour la fraude, un train_test_split classique fuit l'avenir dans le passé — le modèle voit à l'entraînement des transactions postérieures à celles qu'il devra prédire. Le découpage doit être temporel :

CREATE TABLE `paiement-fraude-prod.transactions.entrainement_2026_q3` AS
SELECT *, 
  CASE
    WHEN DATE(horodatage) < '2026-08-15' THEN 'train'
    WHEN DATE(horodatage) < '2026-08-24' THEN 'valid'
    ELSE 'test'
  END AS split
FROM `paiement-fraude-prod.transactions.transactions_enrichies`
WHERE DATE(horodatage) BETWEEN '2026-06-01' AND '2026-08-31'
  AND est_fraude IS NOT NULL
Le coût de BigQuery n'est pas dans la facture Vertex

Un pipeline qui recharge trois fois par jour un jeu de 900 Go ajoute 500 $ par mois à la facture BigQuery, jamais à celle de Vertex AI. Le contrôle de coût passe par la table partitionnée, la matérialisation (CREATE TABLE ... AS SELECT une fois, requête plusieurs fois), et le cache de résultats de BigQuery, gratuit pendant 24 h pour une requête à texte identique.

En résumé​

  • Un bucket par usage avec uniform-bucket-level-access et public-access-prevention dès la création.
  • Le format Parquet est le défaut pour l'entraînement tabulaire ; TFRecord pour les gros jeux d'images.
  • Le Dataset Vertex est un catalogue traçable, pas un magasin ; utile pour l'audit et le lignage.
  • BigQuery facture au scan : nommer les colonnes, partitionner par date, --dry_run avant toute requête coûteuse.
  • L'entraînement lit un export Parquet figé sur GCS ; le découpage train/valid/test est temporel pour un problème temporel.

Module suivant : nous lançons l'entraînement personnalisé dans un conteneur, en lisant précisément l'export que nous venons d'écrire.