ServicesÀ proposNotesContact Me contacter →
EN FR
Note

Types de tables BigQuery

Tables BigQuery natives, tables externes BigLake, et tables BigLake Iceberg — ce que chacune optimise, quand les utiliser, et un cadre de décision pour choisir.

Planté
bigquerygcpdata engineeringdata modeling

BigQuery propose trois approches distinctes pour stocker et interroger des données. Chacune optimise pour des contraintes différentes, et le bon choix dépend de vos patterns d’accès, de vos exigences de gouvernance, et de la nécessité que d’autres moteurs que BigQuery accèdent aux mêmes données. Comprendre les compromis est le point de départ de toute conception de plateforme data sur GCP.

Tables BigQuery natives

Les tables natives stockent les données dans le format propriétaire en colonnes de BigQuery (Capacitor sur Colossus, comme présenté dans BigQuery Architecture for Analytics Engineers). Elles offrent les meilleures performances de requête, prennent en charge les insertions en streaming avec une latence inférieure à la seconde, et gèrent les workloads à haute concurrence sans nécessiter de tuning.

Le compromis est la portabilité. Les données n’existent que dans BigQuery. Si Spark, Trino ou un autre moteur a besoin d’y accéder, vous devez exporter des données ou exécuter des federated queries. Pour les équipes qui opèrent entièrement dans BigQuery, ce n’est pas une limitation. Pour les équipes construisant des architectures multi-moteurs, c’est une contrainte ferme.

Les tables natives sont le bon choix par défaut pour :

  • Les tables analytiques de la couche gold servant les tableaux de bord et les outils BI
  • Les workloads à haute concurrence avec des centaines d’utilisateurs simultanés
  • Les tableaux de bord opérationnels en temps réel nécessitant une latence d’insertion en streaming inférieure à la seconde
  • Les tables que seul BigQuery interrogera jamais

Tables externes BigLake

Les tables BigLake interrogent des données situées dans Cloud Storage tout en appliquant la couche de gouvernance de BigQuery. Vous bénéficiez de la sécurité au niveau des lignes, du masquage au niveau des colonnes et d’un contrôle d’accès précis sur des données stockées dans des fichiers Parquet, ORC, Avro ou CSV. Les données restent dans le stockage objet — BigQuery les lit au moment de la requête via une connexion Cloud Resource.

Les performances des requêtes dépendent fortement de la disposition des fichiers et de la configuration du cache de métadonnées. Sans la mise en cache des métadonnées activée, chaque requête scanne Cloud Storage pour découvrir les statistiques de fichiers, ce qui ajoute une latence significative. Avec la mise en cache, les performances se rapprochent à 20-30 % près des tables natives pour la plupart des patterns analytiques.

Les tables BigLake conviennent quand :

  • Plusieurs moteurs doivent interroger les mêmes données (Spark, Trino, Presto aux côtés de BigQuery)
  • Les exigences de conformité restreignent le déplacement des données — certains cadres réglementaires imposent que les données restent dans des systèmes de stockage spécifiques
  • Vous avez besoin de la gouvernance BigQuery sur des données Cloud Storage existantes sans les copier dans le stockage géré
  • L’optimisation des coûts via le tiering de stockage est prioritaire pour les grands datasets rarement interrogés

Les tables BigLake prennent en charge le partitionnement de style Hive. Définissez require_partition_filter = true sur les tables partitionnées par date ou d’autres colonnes à haute cardinalité pour éviter que les analystes ne déclenchent accidentellement des scans complets sur des téraoctets de données. C’est l’une des erreurs les plus courantes dans les implémentations data lake BigQuery — consultez BigQuery Partition Pruning Patterns pour l’histoire complète.

Tables BigLake Iceberg

Les tables BigLake Iceberg représentent la direction stratégique de Google pour BigQuery. Ces tables stockent les données au format Apache Iceberg dans Cloud Storage mais prennent en charge le DML BigQuery complet — INSERT, UPDATE, DELETE, et MERGE. Elles gèrent l’ingestion en streaming, prennent en charge les requêtes time travel, et maintiennent des métadonnées que tout moteur compatible Iceberg peut lire.

-- Création d'une table BigLake Iceberg
CREATE TABLE `project.dataset.events`
(
  event_id STRING,
  event_timestamp TIMESTAMP,
  user_id STRING,
  event_name STRING,
  event_params JSON
)
CLUSTER BY user_id
WITH CONNECTION `project.region.connection_id`
OPTIONS (
  file_format = 'PARQUET',
  table_format = 'ICEBERG',
  storage_uri = 'gs://bucket/path/to/table'
);

BigQuery gère automatiquement la compaction et l’optimisation des tables. Vous n’avez pas besoin d’exécuter OPTIMIZE ni de gérer les petits fichiers comme vous le feriez avec un déploiement Iceberg auto-géré sur Spark.

Caractéristiques clés :

  • Support DML complet : contrairement aux tables BigLake standard, vous pouvez exécuter des opérations INSERT, UPDATE, DELETE et MERGE
  • Ingestion en streaming : streaming à haut débit, bien que la latence par enregistrement soit plus élevée que les tables natives
  • Time travel : interroger les données telles qu’elles étaient à un moment précédent
  • Accès multi-moteurs : tout moteur compatible Iceberg (Spark, Flink, Trino) peut lire les données via le BigLake Metastore
  • Compaction automatique : BigQuery gère la compaction des fichiers et l’optimisation en arrière-plan

Pour la plupart des nouveaux projets, les tables BigLake Iceberg éliminent le besoin de choisir entre tables natives et externes. Vous bénéficiez de la flexibilité du format ouvert avec des caractéristiques opérationnelles proches d’un entrepôt de données. La pénalité de performance est acceptable pour la plupart des cas d’usage, et vous conservez la capacité d’exporter des données vers tout système compatible Iceberg.

Cadre de décision

Pour évaluer quel type de table utiliser pour un dataset spécifique, parcourez ces questions dans l’ordre :

1. Un autre moteur que BigQuery doit-il 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 BigQuery natives nécessitent d’exporter des données ou d’utiliser l’écosystème de connecteurs BigQuery.

2. Avez-vous besoin d’insertions en streaming avec une latence inférieure à la seconde ? Les tables BigQuery natives gèrent cela le mieux. BigLake Iceberg prend en charge le streaming mais avec une latence plus élevée par enregistrement. Pour les tableaux de bord opérationnels en temps réel ou les alertes, commencez par les tables natives.

3. 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 vous permettent d’interroger les données en place sans les copier dans le stockage géré de BigQuery.

4. Quelle est l’importance des performances de requête pour cette table spécifique ? Les tables de la couche gold servant les tableaux de bord bénéficient des performances des tables natives. Les tables de la couche bronze qui n’alimentent que des pipelines batch en ont rarement besoin. Consultez BigLake Performance Characteristics pour les détails sur l’endroit où l’écart compte.

5. Ce dataset existera-t-il dans cinq ans ? Les formats ouverts comme Iceberg offrent une meilleure portabilité à long terme. Si vous construisez des actifs de données centraux qui survivront à votre architecture actuelle, la valeur d’assurance des formats ouverts compte.

Le choix par défaut pour les nouveaux projets en 2026 : les tables BigLake Iceberg sauf si une exigence spécifique pointe ailleurs. Les tables BigQuery natives restent le bon choix pour les couches de service haute performance. Une architecture hybride — Iceberg pour la flexibilité, native pour la vitesse — est ce que le pattern medallion lakehouse met en œuvre.