Architecture Medallion Lakehouse sur GCP

L’architecture medallion — couches bronze, argent, or avec une qualité de données croissante — se mappe aux types de tables disponibles dans BigQuery. Différentes couches optimisent pour différents objectifs, et BigQuery permet de mélanger les types de tables au sein d’un même projet : flexibilité là où c’est nécessaire (étapes initiales du pipeline) et performance là où ça compte (couches de service analytique).

Couche Bronze : atterrissage des données brutes

Les données brutes atterrissent dans des tables BigLake Iceberg. Les jobs Spark ou Flink écrivent directement au format Iceberg sur Cloud Storage. Le BigLake Metastore suit les métadonnées des tables, les rendant découvrables à la fois par BigQuery et les moteurs de calcul externes.

Cette couche privilégie le débit d’écriture et la flexibilité de schéma à la performance des requêtes.

-- Couche Bronze : table BigLake Iceberg pour l'ingestion d'événements bruts
CREATE TABLE `project.bronze.raw_events`
(
  event_id STRING,
  event_timestamp TIMESTAMP,
  payload JSON,
  source_system STRING,
  ingestion_time TIMESTAMP
)
CLUSTER BY source_system
WITH CONNECTION `project.us.biglake_connection`
OPTIONS (
  file_format = 'PARQUET',
  table_format = 'ICEBERG',
  storage_uri = 'gs://data-lake-bronze/raw_events'
);

Pourquoi Iceberg au niveau bronze :

• Écritures multi-moteurs : Spark et Flink peuvent écrire directement au format Iceberg sans passer par BigQuery
• Évolution du schéma : les schémas de données brutes changent fréquemment ; Iceberg gère les ajouts de colonnes, renommages et promotions de types
• Voyage dans le temps : relire ou auditer les données brutes à tout état antérieur
• Portabilité : si vous devez migrer hors de GCP un jour, vos données brutes sont dans un format ouvert

Les tables bronze sont typiquement à écriture intensive. Les nouvelles données arrivent continuellement, et les corrections sont rares. Activez Autoclass sur le bucket Cloud Storage sous-jacent afin que les données plus anciennes migrent automatiquement vers des niveaux de stockage moins coûteux en fonction des patterns d’accès réels.

Couche Argent : nettoyage et harmonisation

Les modèles dbt transforment les données bronze en datasets nettoyés et harmonisés. Ces transformations s’exécutent dans BigQuery via SQL, lisant depuis les tables Iceberg et écrivant soit dans d’autres tables Iceberg, soit dans des tables BigQuery natives selon les exigences en aval.

La couche argent correspond directement aux couches base et intermédiaire dans un projet dbt. Les modèles base nettoient les données bronze brutes (renommage de colonnes, cast de types, déduplication). Les modèles intermédiaires joignent et enrichissent les différentes entités.

-- Modèle dbt couche Argent lisant depuis le Bronze Iceberg, écrivant dans BigQuery
-- models/intermediate/int__events__enriched.sql
{{ config(
    materialized='incremental',
    incremental_strategy='insert_overwrite',
    partition_by={'field': 'event_date', 'data_type': 'date'},
    cluster_by=['user_id', 'event_name']
) }}

SELECT
    event_id,
    DATE(event_timestamp) AS event_date,
    event_timestamp,
    user_id,
    JSON_VALUE(payload, '$.event_name') AS event_name,
    JSON_VALUE(payload, '$.page_url') AS page_url,
    source_system
FROM {{ source('bronze', 'raw_events') }}

{% if is_incremental() %}
WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 3 DAY)
{% endif %}

QUALIFY ROW_NUMBER() OVER (
    PARTITION BY event_id
    ORDER BY ingestion_time DESC
) = 1

Le choix entre tables Iceberg et natives pour la couche argent dépend de qui d’autre a besoin de les lire :

• Iceberg : quand des pipelines ML basés sur Spark ou d’autres moteurs lisent directement les données argent
• BigQuery natif : quand seuls BigQuery et dbt consomment les tables argent (meilleure performance des requêtes, gestion plus simple)

Pour la plupart des équipes axées sur l’analytique, les tables BigQuery natives au niveau argent fonctionnent bien. L’avantage multi-moteurs d’Iceberg est surtout utile au niveau bronze (où des systèmes externes écrivent) et moins au niveau argent (où BigQuery fait le travail).

Activez le re-clustering automatique pour les tables argent fréquemment interrogées afin de maintenir la performance au fur et à mesure que les données s’accumulent. BigQuery gère cela automatiquement pour les tables natives ; pour les tables Iceberg, BigQuery gère la compaction en arrière-plan.

Couche Or : analytique prête pour le métier

Les datasets agrégés et prêts pour le métier résident dans des tables BigQuery natives optimisées pour les workloads BI. Ces tables alimentent les tableaux de bord, supportent les requêtes ad hoc des analystes et sous-tendent l’analytique embarquée. C’est la couche mart en termes de dbt.

-- Modèle mart couche Or : performance quotidienne par canal
-- models/marts/marketing/mrt__marketing__daily_channel_performance.sql
{{ config(
    materialized='incremental',
    incremental_strategy='insert_overwrite',
    partition_by={'field': 'event_date', 'data_type': 'date'},
    cluster_by=['channel', 'source']
) }}

SELECT
    event_date,
    channel,
    source,
    COUNT(DISTINCT user_id) AS unique_users,
    COUNT(DISTINCT session_id) AS sessions,
    SUM(conversions) AS total_conversions,
    SAFE_DIVIDE(SUM(conversions), COUNT(DISTINCT session_id)) AS conversion_rate
FROM {{ ref('int__sessions__attributed') }}

{% if is_incremental() %}
WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 3 DAY)
{% endif %}

GROUP BY 1, 2, 3

Les tables natives sont logiques au niveau or parce que :

• La performance compte le plus ici — ce sont les tables que les utilisateurs touchent réellement
• L’accès multi-moteurs est rarement nécessaire pour les métriques agrégées
• Les insertions en streaming fonctionnent avec une latence inférieure à la seconde pour les tableaux de bord en temps réel
• Les vues matérialisées peuvent accélérer davantage les requêtes de tableaux de bord répétées (voir BigQuery Materialized Views)

L’avantage hybride

La vraie puissance de ce schéma est l’optionnalité. Vous n’êtes pas enfermé dans un seul format de table sur toute votre plateforme.

• Bronze (Iceberg) : n’importe quel moteur peut écrire, n’importe quel moteur peut lire. Vous pouvez ajouter du traitement Spark plus tard ou migrer vers une autre plateforme sans réexporter les données brutes.
• Argent (Iceberg ou natif) : choisissez selon si des moteurs non-BigQuery ont besoin d’accéder aux données argent.
• Or (natif) : vitesse de requête maximale pour les tables qui pilotent les décisions métier.

Cette approche hybride préserve la flexibilité dans les étapes initiales du pipeline tout en maximisant la vitesse pour les tables avec lesquelles les utilisateurs interagissent quotidiennement. La couche catalogue relie le tout, fournissant une vue unifiée sur tous les types de tables.

Quand ne pas utiliser le schéma medallion complet

Tous les datasets n’ont pas besoin du traitement medallion complet. Les tables de reporting simples peuvent aller directement de la source aux tables BigQuery natives sans couches Iceberg intermédiaires. Le schéma lakehouse apporte de la valeur pour les données qui nécessitent :

• Un accès multi-moteurs à n’importe quelle étape
• Des garanties de portabilité à long terme
• Une ingestion complexe depuis des systèmes de streaming (Spark, Flink)
• Une séparation réglementaire entre données brutes et données transformées

Pour les données que seul BigQuery touchera jamais, un projet dbt simple avec des tables natives à chaque couche est plus simple et plus performant. Sur-compliquer l’architecture est l’une des erreurs les plus courantes dans les implémentations de data lake BigQuery. Adaptez la complexité de votre infrastructure à la complexité de vos exigences réelles.