Accueil›Blog›Test technique GCP stack data : BigQuery, Dataflow, Pub/Sub, Vertex AI

Guide recrutement data

Test technique GCP stack data : BigQuery, Dataflow, Pub/Sub, Vertex AI

Google Cloud Platform est la stack data cloud la plus cohérente. En entretien, on évalue la capacité à choisir et intégrer les bons services GCP selon le cas d usage.

Data Builder·Juin 2025·7 min de lecture·Data Engineer

Sommaire

Architecture data sur GCP
BigQuery : le centre de gravité
Dataflow : streaming et batch
Pub/Sub : messagerie temps réel
Cloud Composer : orchestration
Vertex AI : ML sur GCP
Grille

1Architecture data de référence sur GCP

Question discriminante

Décrivez une architecture data end-to-end sur GCP.

# Architecture GCP typique

SOURCES
├── Cloud SQL / AlloyDB (bases transactionnelles)
├── APIs tierces
├── Fichiers (GCS)
└── Streaming (IoT, events)

INGESTION
├── Pub/Sub (streaming)
├── Cloud Storage Transfer (batch)
├── Datastream (CDC depuis Cloud SQL)
└── Fivetran / Airbyte (connecteurs SaaS)

ORCHESTRATION
└── Cloud Composer (Airflow managé)

TRANSFORMATION
├── Dataflow (streaming + batch)
├── BigQuery SQL + dbt
└── Spark sur Dataproc

STOCKAGE ANALYTIQUE
└── BigQuery

CONSOMMATION
├── Looker / Looker Studio
├── Vertex AI (ML)
└── APIs via Cloud Run

2BigQuery : le centre de gravité GCP

Question discriminante

Quelles fonctionnalités BigQuery utilisez-vous au-delà du SQL de base ?

Partitionnement + clustering — réduire les coûts et améliorer les performances sur les grandes tables
Materialized Views — pré-calculer les agrégations fréquentes avec refresh incrémental automatique
BigQuery ML — entraîner des modèles ML directement en SQL (régression, clustering, time series)
BigQuery Omni — requêter des données dans AWS S3 ou Azure Blob sans les déplacer
BigQuery Biglake — tables sur GCS avec sécurité centralisée, compatible Iceberg
Connected Sheets — analyser des milliards de lignes BigQuery directement dans Google Sheets

3Dataflow : traitement batch et streaming unifié

Question discriminante

Quelle est la différence entre Dataflow et Spark ? Quand choisissez-vous Dataflow ?

import apache_beam as beam
from apache_beam.options.pipeline_options import PipelineOptions

options = PipelineOptions(
    runner='DataflowRunner',
    project='mon-projet-gcp',
    region='europe-west1',
    temp_location='gs://mon-bucket/temp',
    staging_location='gs://mon-bucket/staging'
)

with beam.Pipeline(options=options) as p:
    (
        p
        | 'ReadFromBQ' >> beam.io.ReadFromBigQuery(
            query='SELECT * FROM dataset.orders WHERE date >= "2024-01-01"'
        )
        | 'Transform' >> beam.Map(lambda row: {
            'order_id': row['order_id'],
            'revenue': row['quantity'] * row['unit_price']
        })
        | 'WriteToBQ' >> beam.io.WriteToBigQuery(
            'mon-projet:dataset.fct_revenue'
        )
    )

Dataflow — service managé basé sur Apache Beam. Serverless, autoscaling. Idéal pour les pipelines streaming vers BigQuery
Quand Dataflow — streaming (Pub/Sub → BigQuery), pipelines batch sur GCS, intégration native GCP
Quand Spark/Dataproc — code Spark existant à migrer, besoins avancés (ML Spark, Delta Lake)

4Pub/Sub : messagerie temps réel

Question discriminante

Comment intégrez-vous Pub/Sub dans un pipeline de streaming data ?

from google.cloud import pubsub_v1
import json

# Publisher : émettre des événements
publisher = pubsub_v1.PublisherClient()
topic_path = 'projects/mon-projet/topics/orders-events'

def publish_order_event(order: dict):
    data = json.dumps(order).encode('utf-8')
    future = publisher.publish(topic_path, data)
    return future.result()

# Pattern typique : API → Pub/Sub → Dataflow → BigQuery
# Pub/Sub garantit la livraison at-least-once
# Dataflow déduplique avec les windows et watermarks

At-least-once — Pub/Sub garantit la livraison mais peut livrer en double. Gérer la déduplication en aval
Pull vs Push — Pull : le subscriber tire les messages. Push : Pub/Sub envoie vers un endpoint HTTP
Dead Letter Topic — messages non traités après N tentatives → DLT pour investigation

5Cloud Composer : Airflow managé GCP

Question discriminante

Pourquoi Cloud Composer plutôt qu Airflow self-hosted sur K8s ?

Cloud Composer — Airflow entièrement managé sur GKE. Pas de maintenance du cluster, mises à jour automatiques
Intégrations GCP natives — BigQueryOperator, DataflowOperator, GCSOperator, VertexAIOperator pré-configurés
Workload Identity — les DAGs s authentifient sur GCP sans credentials explicites
Coût — plus cher que self-hosted mais zéro maintenance. Composer 2 (basé sur KubernetesExecutor) est plus économique

6Vertex AI : plateforme ML GCP

Question discriminante

Quels composants Vertex AI utilisez-vous dans un projet ML end-to-end ?

Vertex AI Training — entraîner des modèles avec GPU managés, monitoring intégré, hyperparameter tuning
Vertex AI Model Registry — versionner et promouvoir les modèles en production
Vertex AI Endpoints — déployer un modèle comme API REST avec autoscaling
Feature Store — stocker et partager les features ML entre projets
Vertex AI Pipelines — orchestrer les pipelines ML avec Kubeflow Pipelines ou TFX
BigQuery ML — entraîner directement dans BigQuery pour les modèles simples

7Grille par niveau

Niveau	Maitrise	Signal GO	NO-GO
Confirmé	BigQuery, GCS, Cloud Composer, IAM basique	A déployé des pipelines sur Cloud Composer, optimise BigQuery avec partitionnement	Ne sait pas ce qu est Workload Identity sur GCP
Senior	Dataflow, Pub/Sub, Vertex AI, architecture end-to-end	A construit un pipeline streaming Pub/Sub → Dataflow → BigQuery, connaît Vertex AI	Ne sait pas la différence entre Dataflow et Spark/Dataproc

Vous recrutez un Data Engineer GCP ?

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

Tester gratuitement Reserver un appel