Sélection du moteur de traitement GCP : Dataflow, Dataproc et BigQuery

GCP propose quatre moteurs de traitement distincts pour les workloads de transformation de données : BigQuery SQL, Dataflow, Dataproc et Dataproc Serverless. Le bon choix dépend de l’expertise de l’équipe et des caractéristiques du workload, et non uniquement des seuils de volume de données.

Les quatre options

BigQuery SQL couvre une part plus importante des workloads de transformation que les équipes ne l’anticipent généralement. La tarification BigQuery Editions avec l’autoscaler provisionne des slots en temps réel avec une facturation à la seconde, rendant BigQuery compétitif en coût face à Spark pour de nombreux patterns de transformation. Les caractéristiques opérationnelles sont plus simples : pas de gestion de cluster, pas de maintenance d’image Docker pour la couche de calcul, pas de tuning Spark.

L’architecture dbt à trois couches (base, intermédiaire, mart) se mappe directement aux patterns de transformation que BigQuery exécute efficacement :

-- BigQuery gère des transformations complexes pour lesquelles les équipes pourraient réflexivement se tourner vers Spark
SELECT
    user_id,
    DATE(event_timestamp) AS event_date,
    COUNT(DISTINCT session_id) AS sessions,
    ARRAY_AGG(
        STRUCT(event_name, event_timestamp)
        ORDER BY event_timestamp
        LIMIT 100
    ) AS event_sequence,
    SUM(revenue) AS total_revenue
FROM events
WHERE event_date BETWEEN '2026-01-01' AND CURRENT_DATE()
GROUP BY 1, 2

BigQuery gère le scaling du calcul automatiquement. Vous ne configurez pas le parallélisme, les comptages de partitions ou les partitions de shuffle.

Dataflow excelle pour les nouveaux pipelines construits sur Apache Beam, notamment quand vous avez besoin d’un traitement unifié batch et streaming depuis le même code. Son modèle serverless élimine entièrement la gestion de cluster — vous déployez une définition de pipeline, Dataflow gère le provisionnement, le scaling et le teardown.

Cas d’usage principaux :

Pipelines batch/stream unifiés où la même logique traite les backfills historiques et les événements en temps réel
Fenêtrage complexe (fenêtres glissantes, fenêtres de session, déclencheurs personnalisés) où le modèle Beam est plus propre que SQL
Pipelines où vous voulez une base de code unique pour batch et streaming sans maintenir des systèmes séparés

# Pipeline Dataflow avec Apache Beam — le même code s'exécute en batch et en streaming
import apache_beam as beam
from apache_beam.options.pipeline_options import PipelineOptions

options = PipelineOptions(
    runner='DataflowRunner',
    project='my-project',
    region='us-central1',
    temp_location='gs://my-bucket/temp',
    streaming=False  # Passer à True pour le mode streaming
)

with beam.Pipeline(options=options) as p:
    events = (
        p
        | 'ReadFromBigQuery' >> beam.io.ReadFromBigQuery(
            query='SELECT * FROM `project.dataset.raw_events`',
            use_standard_sql=True
        )
        | 'EnrichEvents' >> beam.Map(enrich_event)
        | 'WriteToBigQuery' >> beam.io.WriteToBigQuery(
            table='project:dataset.enriched_events',
            write_disposition=beam.io.BigQueryDisposition.WRITE_APPEND
        )
    )

Dataproc est le bon choix lors de la migration de workloads Spark existants, de l’exécution de workflows ML avec Spark MLlib, ou quand des configurations de cluster personnalisées que les options serverless ne supportent pas sont nécessaires. Il provisionne des clusters Hadoop/Spark entièrement gérés sur GCP, vous donnant un contrôle sur la taille du cluster, la configuration et les packages installés.

Cas d’usage clés de Dataproc :

Migration de jobs Spark on-premises vers GCP sans les réécrire
Pipelines de feature engineering ML qui utilisent déjà PySpark et MLlib
Workloads nécessitant des configurations Spark spécifiques, des bibliothèques personnalisées ou des versions de packages non standards
Jobs nécessitant des patterns de stockage compatibles HDFS

Dataproc Serverless comble l’écart — il exécute des jobs batch Spark sans gestion de cluster, en acceptant moins de configurabilité en échange d’une charge de provisionnement nulle. Vous soumettez un job PySpark, il s’exécute, vous payez pour la durée. Aucun cluster à créer, dimensionner ou arrêter.

# Soumettre un job batch Spark à Dataproc Serverless
gcloud dataproc batches submit pyspark my_transformation.py \
    --region=us-central1 \
    --deps-bucket=gs://my-staging-bucket \
    --jars=gs://my-bucket/jars/custom-lib.jar \
    -- \
    --input-table=project.dataset.raw_data \
    --output-table=project.dataset.processed_data

Le cadre décisionnel

Équipe SQL et dbt, sans workloads Spark existants : BigQuery comme option par défaut pour la transformation. Rester en SQL évite les changements de contexte, le débogage de clusters et la gestion de clusters. La plupart des problèmes de performance avec BigQuery sont résolubles par l’optimisation des requêtes et le partitionnement plutôt que par le changement de moteur.
Workloads Spark existants à migrer : Dataproc. Réécrire des jobs Spark qui fonctionnent en SQL pour l’uniformité de la plateforme est rarement rentable ; migrez l’infrastructure, pas le code.
Traitement batch/stream unifié depuis une base de code unique : Dataflow avec Apache Beam. Pour des besoins de streaming plus simples — ingestion append-only, filtrage basique — l’API de Streaming BigQuery ou les abonnements Pub/Sub + BigQuery sont moins coûteux.
Spark occasionnel sans gestion de cluster : Dataproc Serverless pour les jobs batch.

Pourquoi les seuils de volume sont le mauvais signal

Le volume de données et la lenteur des requêtes sont des symptômes qui méritent un diagnostic avant d’ajouter un nouveau moteur :

« Nous avons beaucoup de données » → Commencez par le partition pruning, vérifiez si require_partition_filter est défini, assurez-vous que les requêtes ne scannent pas des tables entières.
« Cette requête est lente » → Vérifiez la consommation de slots, examinez le plan de requête, cherchez des jointures croisées non intentionnelles ou une prédicats pushdown manquants.
« SQL ne peut pas effectuer cette transformation » → Les fonctions tableau, les opérations struct et les fonctions de fenêtre de BigQuery gèrent la plupart de la logique de transformation complexe.

Introduire Spark pour résoudre un problème de performance BigQuery ajoute une seconde surface de tuning (nombre d’exécuteurs, mémoire par exécuteur, partitions de shuffle, seuils de broadcast) que les équipes à l’aise avec SQL ne savent généralement pas naviguer.

Intégration avec l’architecture Medallion

Dans un medallion lakehouse, la sélection du moteur de traitement se mappe naturellement aux couches :

Ingestion couche Bronze : Dataflow (pour le streaming) ou Dataproc Serverless (pour les workloads batch Spark provenant de systèmes amont)
Transformation couche Silver : BigQuery SQL via dbt — lit depuis les tables BigLake Iceberg bronze, écrit des datasets conformés
Agrégation couche Gold : BigQuery SQL via dbt — analytique pure, performance de requête maximale pour les outils BI

Ce découpage n’exige pas que chaque équipe utilise chaque moteur. De nombreuses équipes opèrent entièrement dans BigQuery pour le silver et le gold, et n’introduisent Dataflow ou Dataproc que si leur ingestion bronze le requiert véritablement (streaming avec fenêtrage complexe, ou migration depuis un pipeline Spark existant).

Le principe architectural : choisissez le moteur le plus simple qui répond à vos besoins. Chaque moteur supplémentaire augmente la complexité opérationnelle et la charge d’astreinte.