BigLake ne désigne plus exactement ce que beaucoup de tutoriels présentent. Depuis avril 2026, Google Cloud appelle sa plateforme Lakehouse, tandis que les tables BigLake restent disponibles dans BigQuery.
Derrière ce changement de nom se cache une question très concrète pour les entreprises : comment analyser des fichiers ouverts, les protéger et les partager entre BigQuery et Apache Spark sans multiplier les copies ? La réponse dépend du type de table, du catalogue utilisé et des opérations attendues. Voici les mécanismes, les bénéfices, les limites et les coûts à examiner avant de bâtir un lakehouse sur Google Cloud.
Points clés :
- BigLake est désormais associé à la plateforme Lakehouse
- Les tables externes classiques sont en lecture seule
- Apache Iceberg permet une autre interopérabilité, à tester selon les moteurs
BigLake n’est plus exactement le nom de la plateforme
Google a rebaptisé BigLake en Lakehouse le 20 avril 2026. Le changement ne fait pas disparaître les tables BigLake, toujours documentées dans BigQuery, ni les API qui conservent des noms historiques. Il signale surtout un repositionnement et Google ne vend plus seulement un moyen de consulter des fichiers externes. La plateforme propose désormais un ensemble de services pour exploiter des tables ouvertes, des catalogues et plusieurs moteurs de calcul.
Cette nuance évite une erreur fréquente dans les comparatifs. Il ne faut pas confondre les tables BigLake classiques, les tables Iceberg gérées par BigQuery et le catalogue d’exécution Lakehouse. Ces trois briques se complètent, mais leurs possibilités d’écriture, leurs coûts et leurs contraintes ne sont pas identiques. Pour une entreprise qui prépare une migration, le premier travail consiste donc à identifier le produit réellement utilisé, plutôt qu’à cocher une case « BigLake » dans son inventaire.
Pourquoi le Lakehouse intéresse les entreprises ?
Un data warehouse traditionnel organise les données pour les analyses structurées, souvent après ingestion et transformation. Un data lake conserve des fichiers plus variés, à moindre contrainte de format. Mais, il peut aussi compliquer les permissions, la qualité et la découverte des jeux de données. Le lakehouse cherche à réunir ces avantages sans obliger chaque équipe à fabriquer une nouvelle copie des mêmes informations. Dans Google Cloud, Cloud Storage peut héberger les fichiers tandis que BigQuery assure les requêtes SQL.
Des moteurs comme Spark interviennent dans les traitements distribués. Un analyste et un ingénieur de données travaillent sur un socle commun pour créer un bénéfice concret. Cela ne signifie pas que toutes les copies disparaissent automatiquement. Les pipelines, les besoins de performance, les transformations et les règles de conservation peuvent toujours justifier des tables dérivées. Le lakehouse réduit certaines frontières techniques ; il ne supprime pas les arbitrages d’architecture.
Comment fonctionnent les tables BigLake classiques ?
Une table BigLake classique représente des données situées dans un stockage objet externe. BigQuery s’appuie sur une connexion liée à un compte de service pour lire les fichiers. Les utilisateurs reçoivent des autorisations sur la table, sans devoir nécessairement disposer d’un accès direct au bucket. Cette délégation est un élément déterminant de la sécurité. Elle permet d’appliquer des restrictions par ligne ou colonne et, dans certains cas sur Cloud Storage, un masquage dynamique.
Les formats documentés comprennent notamment Parquet, ORC, Avro, CSV, JSON, Delta Lake et Iceberg, avec des limites selon le type de table. Les sources peuvent inclure Cloud Storage et via BigQuery Omni, Amazon S3 ou Azure Blob Storage. Toutefois, les tables BigLake classiques décrites dans la documentation BigQuery sont en lecture seule. Une commande SQL qui modifie les lignes ne fonctionne pas comme sur une table BigQuery native. C’est précisément pourquoi il faut distinguer cette famille des tables Iceberg gérées.
Apache Iceberg apporte une autre logique
Apache Iceberg est un format de table ouvert qui organise les métadonnées, les instantanés et les références aux fichiers de données. Il rend possible une gestion plus robuste de grands ensembles de fichiers que de simples dossiers remplis de Parquet. Google propose des tables Iceberg gérées dans BigQuery, auparavant présentées comme BigLake tables for Apache Iceberg in BigQuery.
Elles stockent les données dans des buckets contrôlés par le client, tout en conservant une expérience d’administration proche de BigQuery. Contrairement aux tables externes classiques, ces tables prennent en charge des mutations DML, des transactions, l’évolution du schéma et des mécanismes d’optimisation automatique.
L’interopérabilité est l’argument majeur surtout que plusieurs moteurs compatibles peuvent exploiter une représentation ouverte des données. Elle ne dispense pas de tester les versions du format, les mécanismes de verrouillage, les autorisations et les opérations concurrentes. Le fait qu’un moteur sache lire Iceberg ne garantit pas qu’il prenne en charge chaque fonction d’écriture ou de maintenance.
BigQuery, Spark et le catalogue Lakehouse
BigQuery est le moteur analytique SQL managé de Google, tandis que Spark sert fréquemment à préparer, enrichir et transformer les données à grande échelle. Pour orchestrer cet écosystème, le Lakehouse runtime catalog (qui remplace l’ancien BigLake metastore) fournit une couche de métadonnées partagées. Google documente des interfaces compatibles avec le catalogue REST Iceberg et les API Hive, mais la plateforme va désormais plus loin en s’ouvrant au multi-cloud : elle permet de fédérer des catalogues externes comme AWS Glue, Databricks Unity Catalog ou Snowflake Horizon Catalog pour requêter des données distantes sans les copier.
Cette architecture sépare ainsi quatre responsabilités fondamentales :
- Où résident les données enregistrées (y compris sur AWS ou Azure via BigQuery Omni) ?
- Quel catalogue tiers ou natif décrit les tables ?
- Comment le catalogue Lakehouse centralise ces métadonnées ?
- Quel moteur exécute le calcul ?
Une telle ouverture limite drastiquement les exportations fastidieuses entre systèmes, mais une architecture multi-cloud et multi-moteur réclame une discipline de fer. Cela implique des conventions de nommage unifiées, un suivi rigoureux des versions, des droits cohérents sur chaque cloud et des tests de compatibilité permanents. L’ancien catalogue BigLake metastore (classic) étant désormais déconseillé au profit du Lakehouse runtime catalog. Les équipes qui s’appuient sur d’anciens tutoriels doivent impérativement réviser leurs commandes et l’architecture de leurs connexions avant tout déploiement.
Gouvernance et sécurité, la promesse à éprouver
La délégation d’accès des tables Lakehouse évite de distribuer des droits directs sur chaque objet de stockage aux analystes. C’est utile pour appliquer le principe du moindre privilège. Mais la sécurité ne se résume pas à une politique IAM correctement affichée dans la console.
Il faut contrôler le compte de service associé à la connexion, les autorisations sur les buckets, les droits des moteurs externes et les possibilités d’accès hors du chemin gouverné. Les politiques de lignes, de colonnes et de masquage n’ont pas nécessairement le même périmètre selon le moteur ou le type de table. Un utilisateur qui possède une voie d’accès directe aux fichiers peut contourner des contrôles appliqués seulement au niveau SQL.
Les journaux d’audit, la classification des données sensibles et les tests de droits réels sont essentiels. Pour les secteurs réglementés, il faut aussi vérifier la localisation des données, les transferts éventuels et les responsabilités contractuelles. « Gouvernance unifiée » reste un objectif d’architecture à démontrer, pas un substitut à un audit.
Performances, cache de métadonnées et petits fichiers
Les requêtes sur un stockage objet peuvent perdre du temps à découvrir des fichiers avant de lire les données utiles. Lakehouse propose une mise en cache des métadonnées pour certaines tables externes, notamment dans Cloud Storage et S3. Elle aide lorsque les datasets contiennent énormément de fichiers ou utilisent un partitionnement de type Hive.
Un paramètre fixe la fraîcheur maximale tolérée du cache ; la documentation mentionne une plage de trente minutes à sept jours. Des rafraîchissements automatiques ou manuels sont possibles. Par ailleurs, un cache ancien peut ne pas refléter immédiatement des fichiers ajoutés, modifiés ou supprimés. Pour les tables externes Iceberg, Google indique que BigQuery exploite déjà les métadonnées du format et que ce cache spécifique n’est pas pris en charge.
Les tables Iceberg gérées ajoutent des optimisations de stockage, dont le redimensionnement des fichiers et le clustering automatique. Néanmoins, le résultat dépend du partitionnement, du volume, du moteur, de la concurrence et de la forme des requêtes. Aucun gain de vitesse universel ne peut être promis.
Combien coûte réellement Lakehouse sur GCP
La facture ne se limite pas au stockage des fichiers. Elle peut combiner la capacité Cloud Storage, les requêtes BigQuery, les traitements Spark, les opérations de catalogue et les tâches de maintenance ou d’optimisation. Avec BigQuery à la demande, les octets traités contribuent à la facturation ; avec des réservations, les requêtes consomment des slots.
Les rafraîchissements de métadonnées peuvent également utiliser des ressources facturables. Google publie séparément les tarifs du Lakehouse table management et du Lakehouse runtime catalog, avec des différences selon les régions et les opérations. Une comparaison sérieuse doit intégrer les coûts réseau, notamment lorsqu’une architecture traverse plusieurs clouds ou régions.
Elle doit aussi mesurer le coût humain et prendre en compte l’administration des permissions, la surveillance des pipelines et la résolution des incidents de compatibilité. Le meilleur test reste un pilote représentatif, avec des requêtes et des volumes proches de la production. Comparer seulement le prix au téraoctet stocké conduirait à sous-estimer la dépense réelle.
Trois cas d’usage où la solution a du sens
Voici trois cas d’utilisation de Lakehouse que vous pouvez découvrir :
- Premier scénario : une entreprise conserve ses données brutes et nettoyées dans Cloud Storage, puis donne aux analystes un accès SQL contrôlé sans leur ouvrir directement les buckets. Les tables Lakehouse classiques peuvent répondre à ce besoin de lecture gouvernée.
- Deuxième scénario : une équipe de data engineering transforme de gros volumes avec Spark, tandis que les métiers interrogent les résultats avec BigQuery. Un socle Iceberg et un catalogue partagé peuvent limiter les transferts et les divergences de métadonnées.
- Troisième scénario : une organisation possède plusieurs clouds et souhaite interroger certains ensembles de données sans rapatrier systématiquement tous les fichiers. Les options multicloud existent, mais leurs limites de disponibilité, de sécurité et de coût doivent être vérifiées.
Dans chacun de ces cas, le choix dépend de la fréquence des mises à jour, des SLA, de la souveraineté, des moteurs utilisés et du niveau de compétence des équipes. Une petite base exclusivement interrogée par SQL peut rester plus simple à exploiter dans BigQuery natif.
- Partager l'article :
