Pendant des années, le choix de plateforme de données se résumait à une alternative : les data lakes offraient flexibilité et formats ouverts au détriment de la performance des requêtes, tandis que les data warehouses garantissaient la vitesse mais enfermaient les données dans un stockage propriétaire. Sur GCP, cet arbitrage n’existe plus.
Les tables BigLake Iceberg dans BigQuery combinent la portabilité des formats ouverts avec un support complet du DML, l’ingestion en streaming et des performances de requêtes à 20-30 % des tables natives. Le pattern lakehouse en médaillon (données brutes en Iceberg, transformations via dbt dans BigQuery, analytics servies depuis des tables natives) offre aux équipes la flexibilité là où elles en ont besoin et la performance là où elle compte.
Ce guide propose un cadre de décision pour choisir entre les tables natives BigQuery, les tables externes BigLake et les tables BigLake Iceberg. La bonne réponse dépend de vos patterns d’accès, de vos exigences de gouvernance, et du besoin éventuel d’autres moteurs à accéder aux mêmes données.
Trois types de tables pour trois usages différents
BigQuery propose aujourd’hui trois approches distinctes pour stocker et interroger les données (pour une vue d’ensemble de leur articulation, consultez mon guide d’architecture BigQuery). Chacune optimise des contraintes différentes.
Les tables natives BigQuery stockent les données dans le format colonnaire propriétaire de BigQuery. Elles offrent les meilleures performances de requêtes, supportent les insertions en streaming avec une latence inférieure à la seconde et gèrent les workloads à haute concurrence sans tuning. La contrepartie : les données ne vivent que dans BigQuery. Si Spark, Trino ou un autre moteur a besoin d’y accéder, il faut exporter les données ou passer par des requêtes fédérées.
Les tables BigLake (tables externes avec une connexion Cloud Resource) interrogent des données stockées dans Cloud Storage tout en appliquant la couche de gouvernance BigQuery. Vous bénéficiez de la sécurité au niveau des lignes, du masquage au niveau des colonnes et du contrôle d’accès granulaire sur des données en Parquet, ORC, Avro ou CSV. Les performances de requêtes dépendent fortement de l’organisation des fichiers et de la configuration du cache de métadonnées. Ces tables conviennent bien aux données auxquelles plusieurs moteurs doivent accéder ou qui ne peuvent pas quitter le stockage objet pour des raisons de conformité.
Les tables BigLake Iceberg dans BigQuery représentent la direction stratégique de Google. Ces tables stockent les données au format Apache Iceberg sur Cloud Storage mais supportent l’intégralité du DML BigQuery (INSERT, UPDATE, DELETE et MERGE). Elles gèrent l’ingestion en streaming, supportent les requêtes time travel et maintiennent des métadonnées lisibles par tout moteur compatible Iceberg. BigQuery gère automatiquement la compaction et l’optimisation des tables.
Les tables BigLake Iceberg éliminent la plupart des raisons de choisir entre les deux autres options pour les nouveaux projets. Vous obtenez la flexibilité des formats ouverts avec les caractéristiques opérationnelles d’un data warehouse.
Le pattern lakehouse en médaillon s’adapte bien à GCP
L’architecture en médaillon (couches bronze, silver, gold avec une qualité de données croissante) se transpose naturellement aux types de tables BigQuery.
Couche bronze : les données brutes arrivent dans des tables BigLake Iceberg. Des jobs Spark ou Flink écrivent directement au format Iceberg sur Cloud Storage. Le BigLake Metastore suit les métadonnées des tables, les rendant accessibles à BigQuery comme aux moteurs de calcul externes. Cette couche privilégie le débit en écriture et la flexibilité de schéma par rapport aux performances de requêtes.
Couche silver : les modèles de couches dbt transforment les données bronze en datasets nettoyés et normalisés. Ces transformations s’exécutent dans BigQuery en SQL, lisant depuis les tables Iceberg et écrivant vers d’autres tables Iceberg ou des tables natives BigQuery selon les besoins en aval. Activez l’auto-reclustering sur les tables silver fréquemment interrogées pour maintenir les performances à mesure que les données s’accumulent.
Couche gold : les datasets agrégés, prêts pour le métier, vivent dans des tables natives BigQuery optimisées pour les workloads BI. Ces tables alimentent les dashboards, supportent les requêtes ad-hoc des analystes et servent l’analytics embarquée. Les tables natives sont le choix évident ici parce que la performance compte avant tout et que l’accès multi-moteurs est rarement nécessaire pour des métriques agrégées.
Cette approche hybride préserve l’optionalité dans les premières étapes du pipeline. Vous pouvez toujours ajouter du traitement Spark ou migrer vers une autre plateforme, tout en maximisant la vitesse de requête pour les tables que les utilisateurs consultent réellement.
La stratégie de catalogue compte plus que le choix de format
Les formats de tables ouverts convergent, ce qui signifie qu’investir massivement dans un format plutôt qu’un autre importe moins que construire une infrastructure de catalogue solide.
Les tables Delta Lake fonctionnent dans BigQuery avec un support natif incluant les deletion vectors, le column mapping et le liquid clustering. La fonctionnalité UniForm de Delta Lake expose des métadonnées compatibles Iceberg, ce qui permet aux lecteurs Iceberg d’interroger les tables Delta.
BigLake Metastore fournit un catalogue serverless qui remplace les déploiements Hive Metastore auto-gérés. L’API Iceberg REST Catalog permet à Spark, Flink, Trino et BigQuery de découvrir et gérer les mêmes tables via une interface unifiée. Cela élimine le problème de métadonnées fragmentées où différents moteurs maintiennent des vues incohérentes des tables existantes et de leur contenu.
Dataplex Universal Catalog se positionne au-dessus du BigLake Metastore et assure la gouvernance des data products, modèles d’IA et assets analytiques. Il gère les règles de qualité des données, le suivi de lineage et la gestion des accès couvrant les datasets BigQuery, les buckets Cloud Storage et les modèles Vertex AI. Pour les organisations qui construisent des architectures data mesh, Dataplex fournit le control plane.
Standardisez-vous sur BigLake Metastore comme couche de catalogue quel que soit le format de tables utilisé. Cet investissement est rentable que vous soyez à 100 % sur Iceberg, que vous utilisiez Delta Lake avec Databricks, ou que vous combiniez des formats selon les cas d’usage.
Les écarts de performance se sont considérablement réduits
Le reproche historique fait aux tables externes concernait les performances de requêtes. Elles étaient 3 à 5 fois plus lentes que les tables natives pour les workloads analytiques classiques. Cet écart s’est réduit.
Avec le cache de métadonnées activé, les tables BigLake atteignent des performances de requêtes à 20-30 % des tables natives BigQuery pour la plupart des patterns analytiques. Les benchmarks TPC-DS montrent une amélioration de 4x du temps d’exécution lorsque le cache de métadonnées est actif, principalement grâce à une planification de requêtes optimisée qui utilise les statistiques de fichiers en cache pour le partition pruning et le predicate pushdown.
L’écart de performance restant compte pour :
- Les dashboards à haute concurrence servant des centaines d’utilisateurs simultanés
- Les exigences de latence inférieure à la seconde pour l’analytics opérationnelle
- Les jointures complexes sur de nombreuses grandes tables où chaque milliseconde se cumule
Pour le reporting batch, l’analyse ad-hoc et l’exploration data science, la différence de performance affecte rarement l’expérience utilisateur. Une requête qui s’exécute en 3 secondes au lieu de 4 ne change pas la façon dont les analystes travaillent.
Les performances en streaming diffèrent plus significativement. Les tables natives BigQuery acceptent les insertions en streaming avec une latence inférieure à la seconde et sans overhead de batching. Les tables BigLake Iceberg supportent le streaming à haut débit, mais la latence par enregistrement est plus élevée. Pour les dashboards opérationnels en temps réel, les tables natives restent le meilleur choix.
L’architecture des coûts se joue sur trois dimensions
Optimiser les coûts de stockage nécessite de penser ensemble le tiering, l’efficacité des requêtes et le choix du modèle tarifaire. Chaque dimension interagit avec les autres.
Le tiering de stockage segmente les données par fréquence d’accès :
- Données chaudes (0-90 jours) : tables natives BigQuery ou tables BigLake Iceberg avec Cloud Storage en classe Standard
- Données tièdes (90 jours à 1 an) : tables BigLake sur Cloud Storage Nearline
- Données froides (1+ an) : tables BigLake sur Coldline, interrogées uniquement en cas de besoin
Les politiques de cycle de vie Cloud Storage automatisent les transitions entre niveaux. Une configuration classique déplace les objets de Standard vers Nearline à 30 jours, de Nearline vers Coldline à 90 jours, et les supprime à 365 jours (ajustez la rétention selon vos exigences de conformité). Pour les tables Iceberg, activez Autoclass sur le bucket sous-jacent. Il déplace automatiquement les fichiers de données et de métadonnées vers les classes de stockage optimales en fonction des patterns d’accès réels.
La facturation au stockage physique réduit les coûts de manière significative (je détaille d’autres tactiques d’optimisation des coûts BigQuery dans un guide séparé). Au lieu de payer pour la taille logique des données, vous payez pour les octets compressés. La compression colonnaire de BigQuery atteint généralement un ratio de 3-4x. Combinée à la tarification long-term storage (réduction de 50 % pour les données non modifiées depuis 90 jours), les datasets matures coûtent environ 0,005 $/Go/mois. C’est moins cher que la plupart des stockages objet quand on tient compte des capacités de requêtes incluses.
La tarification Editions modifie l’économie des workloads de transformation. Les projets de pipelines avec des patterns de requêtes prévisibles bénéficient de l’autoscaler avec des slots facturés à la seconde. Les projets analytiques avec des requêtes ad-hoc imprévisibles fonctionnent mieux en tarification on-demand avec des quotas de coûts journaliers. N’appliquez pas le même modèle tarifaire aux deux cas d’usage.
Un cadre de décision pour le choix du type de table
Pour évaluer quel type de table utiliser pour un dataset spécifique, parcourez ces questions :
Un autre moteur que BigQuery a-t-il besoin d’interroger ces données ? Si Spark, Trino, Presto ou un autre moteur de calcul a besoin d’un accès direct, les tables BigLake (standard ou Iceberg) sont vos seules options. Les tables natives BigQuery nécessitent d’exporter les données ou d’utiliser l’écosystème de connecteurs de BigQuery.
Avez-vous besoin d’insertions en streaming avec une latence inférieure à la seconde ? Les tables natives BigQuery gèrent cela le mieux. BigLake Iceberg supporte le streaming mais avec une latence plus élevée par enregistrement. Si votre cas d’usage implique des dashboards opérationnels en temps réel ou de l’alerting, commencez par les tables natives.
Ces données sont-elles soumises à des exigences de conformité restreignant leur déplacement ? Certains cadres réglementaires exigent que les données restent dans des systèmes de stockage ou des régions spécifiques. Les tables BigLake permettent d’interroger les données sur place sans les copier dans le stockage managé de BigQuery.
Quelle importance ont les performances de requêtes pour cette table spécifique ? Les tables de la couche gold qui alimentent les dashboards bénéficient des performances des tables natives. Les tables de la couche bronze qui ne servent qu’à alimenter des pipelines batch en ont rarement besoin.
Ce dataset existera-t-il dans cinq ans ? Les formats ouverts comme Iceberg offrent une meilleure portabilité à long terme. Si vous construisez des assets de données fondamentaux qui survivront à votre architecture actuelle, la valeur d’assurance des formats ouverts compte.
Pour la plupart des nouveaux projets, la réponse par défaut est les tables BigLake Iceberg sauf raison spécifique de choisir autrement. La pénalité de performance est acceptable pour la majorité des cas d’usage, et vous conservez la possibilité d’exporter les données vers tout système compatible Iceberg.
Les erreurs courantes révèlent les écarts entre intention et exécution
Trois patterns causent le plus de problèmes dans les implémentations data lake sur BigQuery.
Oublier le cache de métadonnées : les performances des tables BigLake dépendent de l’activation du cache de métadonnées. Sans lui, chaque requête scanne Cloud Storage pour découvrir les statistiques de fichiers. Ce changement de configuration prend quelques minutes mais affecte considérablement la latence des requêtes.
Ne pas imposer les filtres de partition : les tables externes avec un partitionnement de type Hive devraient exiger des filtres de partition dans les paramètres de requête. Sans cela, les analystes peuvent accidentellement déclencher des full table scans sur des téraoctets de données. Définissez require_partition_filter = true sur les tables partitionnées par date ou d’autres colonnes à haute cardinalité.
Trop complexifier l’architecture : tous les datasets n’ont pas besoin du traitement complet en médaillon. Les tables de reporting simples peuvent aller directement de la source aux tables natives BigQuery sans couche Iceberg intermédiaire. Le pattern lakehouse apporte de la valeur pour les données qui nécessitent un accès multi-moteurs ou une portabilité à long terme, mais c’est de l’overhead pour les données que seul BigQuery utilisera.
Le pari stratégique porte sur l’infrastructure de catalogue
Le paysage data lake sur GCP a véritablement changé. Les tables BigLake Iceberg offrent des capacités qui n’existaient pas il y a deux ans, et l’écart de performance avec les tables natives continue de se réduire. Les guerres de formats importent moins à mesure que Delta Lake et Iceberg convergent vers l’interopérabilité.
L’investissement qui se compose avec le temps, c’est l’infrastructure de catalogue. BigLake Metastore combiné à Dataplex fournit une couche de gouvernance qui couvre les formats, les moteurs et les data products. Les équipes qui instaurent une discipline de catalogue rigoureuse (nommage cohérent, propriété claire, contrôles qualité automatisés) constatent que les décisions de type de table deviennent tactiques plutôt que stratégiques.
Pour les nouvelles plateformes de données sur GCP en 2026, le pattern lakehouse en médaillon avec BigLake Iceberg comme format de table par défaut offre le meilleur équilibre entre flexibilité, performance et optionalité future. Les tables natives BigQuery restent précieuses pour les couches de service à haute performance. L’architecture qui combine les deux, gouvernée par un catalogue unifié, positionne les équipes pour s’adapter à mesure que la plateforme continue d’évoluer.