BigLake Metastore et stratégie de catalogue

Sur GCP, deux services constituent la pile de catalogue : BigLake Metastore pour les métadonnées au niveau table, et Dataplex Universal Catalog pour la gouvernance à travers les data products. À mesure que Delta Lake et Iceberg convergent vers l’interopérabilité, l’infrastructure de catalogue devient l’investissement le plus durable — elle indique à chaque moteur quelles tables existent, où elles se trouvent et qui peut y accéder, indépendamment du format.

Le Problème que les Catalogues Résolvent

Sans catalogue unifié, différents moteurs maintiennent des vues incohérentes de vos données. Spark connaît des tables que BigQuery ignore. BigQuery dispose de datasets que Trino ne peut pas découvrir. Un nouvel analyste rejoint l’équipe et n’a aucun moyen de trouver quelles données existent, ce qu’elles contiennent, ou s’il est autorisé à les utiliser.

C’est le « problème des métadonnées fragmentées », et il s’aggrave à mesure que votre plateforme grandit. Chaque nouveau moteur, chaque nouvelle équipe, chaque nouveau data product crée davantage de métadonnées vivant dans un système différent. Les catalogues centralisent cela de sorte qu’il existe une source de vérité unique pour la découverte de tables, les informations de schéma et le contrôle d’accès.

BigLake Metastore

BigLake Metastore fournit un catalogue serverless qui remplace les déploiements Hive Metastore auto-gérés. Si vous avez déjà eu affaire à un Hive Metastore — la charge opérationnelle d’un backend MySQL ou PostgreSQL, la gestion du service Thrift, la gestion des migrations de schéma — BigLake Metastore élimine tout cela.

La capacité clé est l’API REST Catalog Iceberg. Cette API standard permet à Spark, Flink, Trino et BigQuery de découvrir et gérer les mêmes tables via une interface unifiée. Un job Spark peut créer une table Iceberg, et BigQuery peut immédiatement l’interroger. Une instruction DML BigQuery peut mettre à jour des données, et la prochaine lecture Spark voit les modifications.

# Session Spark configurée pour utiliser BigLake Metastore
spark = SparkSession.builder \
    .config("spark.sql.catalog.biglake",
            "org.apache.iceberg.spark.SparkCatalog") \
    .config("spark.sql.catalog.biglake.catalog-impl",
            "org.apache.iceberg.gcp.biglake.BigLakeCatalog") \
    .config("spark.sql.catalog.biglake.gcp_project", "my-project") \
    .config("spark.sql.catalog.biglake.gcp_location", "us-central1") \
    .config("spark.sql.catalog.biglake.warehouse",
            "gs://my-bucket/warehouse") \
    .getOrCreate()

# Créer une table dans Spark -- immédiatement interrogeable depuis BigQuery
spark.sql("""
    CREATE TABLE biglake.bronze.raw_events (
        event_id STRING,
        event_timestamp TIMESTAMP,
        user_id STRING,
        payload STRING
    )
    USING iceberg
    PARTITIONED BY (days(event_timestamp))
""")

-- La même table est maintenant accessible depuis BigQuery
SELECT event_id, event_timestamp, user_id
FROM `my-project.bronze.raw_events`
WHERE DATE(event_timestamp) = '2026-03-25';

Cette visibilité inter-moteurs est ce qui rend le pattern de lakehouse en médaillon pratique. Sans catalogue partagé, la couche bronze (écrite par Spark) et la couche silver (transformée par BigQuery/dbt) seraient des systèmes déconnectés qui lisent par hasard depuis les mêmes chemins Cloud Storage.

Dataplex Universal Catalog

Dataplex Universal Catalog se situe au-dessus de BigLake Metastore, assurant la gouvernance à travers les data products, les modèles IA et les actifs analytiques. Tandis que BigLake Metastore répond à la question mécanique de « quelles tables existent et où », Dataplex répond aux questions organisationnelles :

Règles de qualité des données : définir et appliquer des attentes de qualité à travers les datasets
Suivi de la lignée : tracer comment les données circulent de la source à la consommation
Gestion des accès : gouverner qui peut lire, écrire ou administrer des données couvrant les datasets BigQuery, les buckets Cloud Storage et les modèles Vertex AI
Organisation en data products : regrouper tables, vues et modèles apparentés en data products découvrables

Pour les organisations construisant des architectures data mesh, Dataplex fournit le plan de contrôle. Les équipes de domaine possèdent leurs data products, les publient via Dataplex, et les consommateurs les découvrent et y souscrivent via une interface unifiée.

Dataplex s’intègre également avec la sécurité au niveau des colonnes de BigQuery et les politiques d’accès au niveau des lignes. Vous définissez les règles de gouvernance une fois dans Dataplex, et elles s’appliquent quel que soit le moteur — BigQuery, Spark ou Trino — qui accède aux données via la connexion BigLake.

La Convergence des Formats Rend les Catalogues Plus Importants

L’argument en faveur de l’investissement dans l’infrastructure de catalogue se renforce à mesure que les formats convergent. Considérez ce qui s’est déjà passé :

Delta Lake UniForm expose des métadonnées compatibles Iceberg, ce qui signifie que les lecteurs Iceberg peuvent interroger des tables Delta sans conversion
BigQuery prend en charge Delta Lake avec des fonctionnalités de premier ordre incluant les vecteurs de suppression, le mapping de colonnes et le liquid clustering
Apache XTable (anciennement OneTable) permet la traduction de métadonnées entre Iceberg, Delta Lake et Hudi

Quand vos jobs Spark écrivent en Delta Lake et que vos requêtes BigQuery lisent Iceberg, la distinction de format commence à s’estomper. Ce qui compte, c’est que votre catalogue connaisse toutes ces tables, puisse appliquer la gouvernance de manière cohérente, et fournisse une interface de découverte unique.

Standardiser sur BigLake Metastore comme couche de catalogue est agnostique au format — cela fonctionne que la pile soit entièrement Iceberg, qu’elle utilise Delta Lake avec Databricks, ou qu’elle mélange les formats.

Recommandations Pratiques

Commencer par BigLake Metastore pour toutes les nouvelles tables BigLake Iceberg. La configuration est minimale et les bénéfices inter-moteurs sont immédiats. Même si vous n’utilisez que BigQuery aujourd’hui, avoir des tables enregistrées dans un catalogue standard signifie qu’ajouter Spark ou Trino plus tard est une question de configuration, pas de migration.

Ajouter Dataplex quand les exigences de gouvernance émergent. Les petites équipes interrogeant leurs propres données n’ont pas besoin d’une couche de gouvernance formelle. Mais dès que vous avez plusieurs équipes, des exigences de conformité ou des consommateurs de données externes, Dataplex fournit une structure que les permissions ad-hoc ne peuvent pas offrir.

Investir tôt dans les conventions de nommage. Les catalogues ne sont utiles qu’à hauteur des métadonnées qu’ils contiennent. Un nommage cohérent (hiérarchie base de données/schéma/table claire), des descriptions significatives et une propriété identifiée font la différence entre un catalogue que les gens utilisent réellement et un qu’ils ignorent. C’est l’investissement organisationnel qui se capitalise — de la même façon que les conventions de nommage des projets dbt portent leurs dividendes à mesure que les projets grandissent.

Éviter les couches de catalogue personnalisées. BigLake Metastore est serverless, s’intègre nativement avec BigQuery et Spark, et prend en charge le standard Iceberg REST Catalog. Les alternatives basées sur des feuilles de calcul ou des wikis manquent de cette intégration avec les moteurs.

Un nommage cohérent, une propriété claire et des vérifications de qualité automatisées dans le catalogue rendent les décisions de type de table tactiques plutôt qu’architecturales.