Tables gérées Apache Iceberg

Les tables gérées Apache Iceberg (anciennement tables BigLake pour Apache Iceberg dans BigQuery) constituent la base de la création de lakehouses au format ouvert sur Google Cloud. Les tables gérées par Iceberg offrent la même expérience entièrement gérée que les tables BigQuery standards, mais stockent les données dans des buckets de stockage détenus par le client. Les tables gérées Iceberg sont compatibles avec le format de table Iceberg ouvert pour une meilleure interopérabilité avec les moteurs de calcul Open Source et tiers sur une seule copie de données.

Les tables gérées Iceberg sont compatibles avec les fonctionnalités suivantes :

Architecture

Les tables gérées Iceberg proposent les atouts de la gestion de ressources BigQuery, pour les tables qui se trouvent dans vos propres buckets cloud. Vous pouvez utiliser BigQuery et des moteurs de calcul Open Source sur ces tables sans déplacer les données hors des buckets que vous contrôlez. Vous devez configurer un bucket Cloud Storage avant de commencer à utiliser des tables gérées Iceberg.

L'utilisation de tables gérées Iceberg a les implications suivantes sur votre bucket :

  • BigQuery crée des fichiers de données dans le bucket en réponse aux requêtes d'écriture et aux optimisations de l'espace de stockage en arrière-plan, telles que les instructions LMD et le traitement par flux.
  • Le compactage et le clustering automatiques sont effectués sur les fichiers de données du bucket. Après l'expiration de la fenêtre temporelle, les fichiers de données sont récupérés. Toutefois, si la table est supprimée, les fichiers de données associés ne sont pas récupérés. Pour en savoir plus, consultez Optimisation du stockage.

La création d'une table gérée Iceberg est semblable à la création de tables BigQuery. Comme une table gérée stocke les données dans des formats ouverts sur Cloud Storage, vous devez effectuer les opérations suivantes :

  • Spécifiez la connexion aux ressources Cloud avec WITH CONNECTION pour configurer les identifiants de connexion de BigQuery afin d'accéder à Cloud Storage.
  • Spécifiez le format de fichier pour le stockage de données en tant que PARQUET avec l'instruction file_format = PARQUET.
  • Spécifiez le format de la table de métadonnées Open Source en tant que ICEBERG avec l'instruction table_format = ICEBERG.

Bonnes pratiques

La modification ou l'ajout direct de fichiers au bucket en dehors de BigQuery peut entraîner une perte de données ou des erreurs irrécupérables. Le tableau suivant présente les scénarios possibles :

Opération Conséquences Prévention
Ajout de fichiers au bucket en dehors de BigQuery. Perte de données : les nouveaux fichiers ou objets ajoutés en dehors de BigQuery ne sont pas intégrés au processus de suivi assuré par BigQuery. Les fichiers non suivis sont supprimés par les processus de récupération de mémoire en arrière-plan. Ajout de données exclusivement via BigQuery. Cela permet à BigQuery de suivre les fichiers et d'empêcher leur suppression par le processus de récupération de mémoire.
Pour éviter les ajouts accidentels et la perte de données, nous vous recommandons également de limiter les autorisations d'écriture des outils externes sur les buckets contenant des tables gérées Iceberg.
Créer une table gérée Iceberg dans un préfixe non vide. Perte de données : les données existantes ne sont pas soumis au suivi effectué par BigQuery. Ces fichiers sont donc considérés comme non suivis et supprimés par les processus de récupération de mémoire en arrière-plan. Ne créez des tables gérées Iceberg que dans des préfixes vides.
Modification ou remplacement de fichiers de données associés à des tables gérées Iceberg. Perte de données : en cas de modification ou de remplacement externe, la table ne passe pas la vérification de la cohérence et devient illisible. Les requêtes sur la table échouent.
Il n'existe alors aucun moyen permettant de revenir à une situation normale en autonomie. Contactez l'assistance pour obtenir de l'aide sur la récupération des données.		 Modifiez les données exclusivement via BigQuery. Cela permet à BigQuery de suivre les fichiers et d'empêcher leur suppression par le processus de récupération de mémoire.
Pour éviter les ajouts accidentels et la perte de données, nous vous recommandons également de limiter les autorisations d'écriture des outils externes sur les buckets contenant des tables gérées Iceberg.
Création de deux tables gérées Iceberg sur les mêmes URI ou sur des URI qui se chevauchent. Perte de données : BigQuery ne crée pas de pont entre des instances d'URI identiques de tables gérées Iceberg. Les processus de récupération de mémoire en arrière-plan pour chaque table considèrent les fichiers de la table opposée comme étant non suivis, et vont donc les supprimer, ce qui entraîne une perte de données. Utilisez des URI uniques pour chaque table gérée Iceberg.

Bonnes pratiques de configuration des bucket Cloud Storage

La configuration de votre bucket Cloud Storage et sa connexion à BigQuery ont un impact direct sur les performances, le coût, l'intégrité des données, la sécurité et la gouvernance de vos tables gérées Iceberg. Voici quelques bonnes pratiques pour vous aider à configurer cette fonctionnalité :

  • Sélectionnez un nom qui indique clairement que le bucket est destiné uniquement aux tables gérées Iceberg.

  • Choisissez des buckets Cloud Storage à région unique colocalisés dans la même région que votre ensemble de données BigQuery. Cette coordination améliore les performances et réduit les coûts en évitant les frais de transfert de données.

  • Par défaut, Cloud Storage stocke les données dans la classe de stockage Standard, qui offre des performances suffisantes. Pour optimiser les coûts de stockage des données, vous pouvez activer la classe automatique afin de gérer automatiquement les transitions de classe de stockage. La classe automatique commence par la classe de stockage Standard et déplace les objets qui ne sont pas consultés vers des classes progressivement plus froides afin de réduire les coûts de stockage. Lorsque l'objet est de nouveau lu, il est replacé dans la classe Standard.

  • Activez l'accès uniforme au niveau du bucket et la protection contre l'accès public.

  • Vérifiez que les rôles requis sont attribués aux utilisateurs et aux comptes de service appropriés.

  • Pour éviter toute suppression ou corruption accidentelle de données dans votre bucket Cloud Storage, limitez les autorisations d'écriture et de suppression pour la plupart des utilisateurs de votre organisation. Pour ce faire, vous pouvez définir une stratégie d'autorisation de bucket avec des conditions qui refusent les requêtes PUT et DELETE pour tous les utilisateurs, à l'exception de ceux que vous spécifiez.

  • Appliquez des clés de chiffrement gérées par Google ou gérées par le client pour renforcer la protection des données sensibles.

  • Activez la journalisation d'audit pour assurer la transparence opérationnelle, le dépannage et la surveillance de l'accès aux données.

  • Conservez la règle de suppression réversible par défaut (conservation de sept jours) pour vous protéger contre les suppressions accidentelles. Toutefois, si vous constatez que des données ont été supprimées, contactez l'assistance plutôt que de restaurer les objets manuellement, car les objets ajoutés ou modifiés en dehors de BigQuery ne sont pas suivis par les métadonnées BigQuery.

  • La mise à l'échelle adaptative des fichiers, le clustering automatique et la récupération de mémoire sont activés automatiquement et permettent d'optimiser les performances et le coût des fichiers.

  • Évitez les fonctionnalités Cloud Storage suivantes, car elles ne sont pas compatibles avec les tables gérées Iceberg :

Vous pouvez mettre en œuvre ces bonnes pratiques en créant votre bucket à l'aide de la commande suivante :

gcloud storage buckets create gs://BUCKET_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --enable-autoclass \
    --public-access-prevention \
    --uniform-bucket-level-access

Remplacez les éléments suivants :

  • BUCKET_NAME : nom de votre nouveau bucket
  • PROJECT_ID : ID de votre projet.
  • LOCATION : emplacement de votre nouveau bucket.

Workflows associés aux tables gérées Iceberg

Les sections suivantes expliquent comment créer, charger, gérer et interroger des tables gérées Iceberg.

Avant de commencer

Avant de créer et d'utiliser des tables gérées Iceberg, assurez-vous d'avoir configuré une connexion aux ressources cloud sur un bucket de stockage. Votre connexion a besoin d'autorisations en écriture sur le bucket de stockage, comme indiqué dans la section Rôles requis ci-dessous. Pour en savoir plus sur les rôles et les autorisations requis pour les connexions, consultez Gérer les connexions.

Rôles requis

Pour obtenir les autorisations nécessaires pour autoriser BigQuery à gérer les tables de votre projet, demandez à votre administrateur de vous accorder les rôles IAM suivants :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour permettre à BigQuery de gérer les tables de votre projet. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour autoriser BigQuery à gérer les tables de votre projet :

  • Tous :
    • bigquery.connections.delegate sur votre projet
    • bigquery.jobs.create sur votre projet
    • bigquery.readsessions.create sur votre projet
    • bigquery.tables.create sur votre projet
    • bigquery.tables.get sur votre projet
    • bigquery.tables.getData sur votre projet
    • storage.buckets.get sur votre bucket
    • storage.objects.create sur votre bucket
    • storage.objects.delete sur votre bucket
    • storage.objects.get sur votre bucket
    • storage.objects.list sur votre bucket

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Créer des tables gérées Iceberg

Pour créer une table gérée Iceberg, sélectionnez l'une des méthodes suivantes :

SQL 

CREATE TABLE [PROJECT_ID.]DATASET_ID.TABLE_NAME (
COLUMN DATA_TYPE[, ...]
)
CLUSTER BY CLUSTER_COLUMN_LIST
WITH CONNECTION {CONNECTION_NAME | DEFAULT}
OPTIONS (
file_format = 'PARQUET',
table_format = 'ICEBERG',
storage_uri = 'STORAGE_URI');

Remplacez les éléments suivants :

  • PROJECT_ID : projet contenant l'ensemble de données. Si cet élément n'est pas défini, la commande utilise le projet par défaut.
  • DATASET_ID : ensemble de données existant.
  • TABLE_NAME : nom de la table que vous créez.
  • DATA_TYPE : type de données des informations contenues dans la colonne.
  • CLUSTER_COLUMN_LIST (facultatif) : liste de quatre colonnes au maximum, séparées par des virgules. Ces colonnes doivent être des colonnes uniques de premier niveau.
  • CONNECTION_NAME : nom de la connexion. Exemple : myproject.us.myconnection. Pour utiliser une connexion par défaut, spécifiez DEFAULT au lieu du nom de la connexion.
  • STORAGE_URI : URI Cloud Storage complet. Exemple : gs://mybucket/table.

bq 

bq --project_id=PROJECT_ID mk \
    --table \
    --file_format=PARQUET \
    --table_format=ICEBERG \
    --connection_id=CONNECTION_NAME \
    --storage_uri=STORAGE_URI \
    --schema=COLUMN_NAME:DATA_TYPE[, ...] \
    --clustering_fields=CLUSTER_COLUMN_LIST \
    DATASET_ID.MANAGED_TABLE_NAME

Remplacez les éléments suivants :

  • PROJECT_ID : projet contenant l'ensemble de données. Si cet élément n'est pas défini, la commande utilise le projet par défaut.
  • CONNECTION_NAME : nom de la connexion. Exemple : myproject.us.myconnection.
  • STORAGE_URI : URI Cloud Storage complet. Exemple : gs://mybucket/table.
  • COLUMN_NAME : nom de la colonne.
  • DATA_TYPE : type de données des informations contenues dans la colonne.
  • CLUSTER_COLUMN_LIST (facultatif) : liste de quatre colonnes au maximum, séparées par des virgules. Ces colonnes doivent être des colonnes uniques de premier niveau.
  • DATASET_ID : ID d'un ensemble de données existant.
  • MANAGED_TABLE_NAME : nom de la table que vous créez.

API

Appelez la méthode tables.insert avec une ressource de table définie, comme suit :

{
"tableReference": {
  "tableId": "TABLE_NAME"
},
"biglakeConfiguration": {
  "connectionId": "CONNECTION_NAME",
  "fileFormat": "PARQUET",
  "tableFormat": "ICEBERG",
  "storageUri": "STORAGE_URI"
},
"schema": {
  "fields": [
    {
      "name": "COLUMN_NAME",
      "type": "DATA_TYPE"
    }
    [, ...]
  ]
}
}

Remplacez les éléments suivants :

  • TABLE_NAME : nom de la table que vous créez.
  • CONNECTION_NAME : nom de la connexion. Exemple : myproject.us.myconnection.
  • STORAGE_URI : URI Cloud Storage complet. Les caractères génériques sont également acceptés. Par exemple, gs://mybucket/table.
  • COLUMN_NAME : nom de la colonne.
  • DATA_TYPE : type de données des informations contenues dans la colonne.

Importer des données dans des tables gérées Iceberg

Les sections suivantes expliquent comment importer des données depuis des tables de différents formats dans des tables gérées Iceberg.

Chargement standard de données à partir de fichiers plats

Les tables gérées Iceberg utilisent des jobs de chargement BigQuery pour charger des fichiers externes dans des tables gérées Iceberg. Si vous disposez d'une table gérée Iceberg, suivez le guide de la CLI bq load ou le guide SQL LOAD pour charger des données externes. Après le chargement des données, de nouveaux fichiers Parquet sont écrits dans le dossier STORAGE_URI/data.

Si les instructions précédentes sont utilisées sans table gérée Iceberg existante, une table BigQuery est créée à la place.

Consultez les sections suivantes pour obtenir des exemples de chargement par lot dans des tables gérées Iceberg, spécifiques aux différents outils :

SQL 

LOAD DATA INTO MANAGED_TABLE_NAME
FROM FILES (
uris=['STORAGE_URI'],
format='FILE_FORMAT');

Remplacez les éléments suivants :

  • MANAGED_TABLE_NAME : nom d'une table gérée Iceberg existante.
  • STORAGE_URI : URI Cloud Storage complet ou liste d'URI séparés par des virgules. Les caractères génériques sont également acceptés. Par exemple, gs://mybucket/table.
  • FILE_FORMAT : format de la table source. Pour connaître les formats acceptés, consultez la ligne format de load_option_list.

bq 

bq load \
  --source_format=FILE_FORMAT \
  MANAGED_TABLE \
  STORAGE_URI

Remplacez les éléments suivants :

  • FILE_FORMAT : format de la table source. Pour connaître les formats acceptés, consultez la ligne format de load_option_list.
  • MANAGED_TABLE_NAME : nom d'une table gérée Iceberg existante.
  • STORAGE_URI : URI Cloud Storage complet ou liste d'URI séparés par des virgules. Les caractères génériques sont également acceptés. Par exemple, gs://mybucket/table.

Chargement standard à partir de fichiers partitionnés avec Apache Hive

Vous pouvez charger des fichiers partitionnés avec Hive dans des tables gérées Iceberg à l'aide de jobs de chargement BigQuery standards. Pour en savoir plus, consultez Charger des données partitionnées en externe.

Charger des données de traitement par flux à partir de Pub/Sub

Vous pouvez charger des données de traitement par flux dans des tables gérées Iceberg à l'aide d'un abonnement Pub/Sub BigQuery.

Charger des données de streaming à l'aide de requêtes continues

Vous pouvez traiter et écrire en continu des données en flux continu de BigQuery dans des tables gérées Iceberg à l'aide d'une requête continue BigQuery avec l'instruction LMD INSERT. Vous pouvez ainsi effectuer des opérations d'ETL inversé, d'enrichissement des données et de filtrage en temps réel dans votre lakehouse au format ouvert.

Avant d'exécuter la requête continue, assurez-vous que la table gérée Iceberg cible existe et que l'utilisateur ou le compte de service dispose des autorisations requises sur la table, sa connexion aux ressources Google Cloud et le bucket Cloud Storage sous-jacent.

Pour obtenir des instructions de configuration et des exemples SQL, consultez Écrire des données dans des tables gérées BigQuery ou Apache Iceberg.

Exporter des données depuis des tables gérées Iceberg

Les sections suivantes décrivent comment exporter des données à partir de tables gérées Iceberg vers différents formats de table.

Exporter des données vers des formats de fichiers plats

Pour exporter une table gérée Iceberg vers un format de fichier plat, utilisez l'instruction EXPORT DATA et sélectionnez un format de destination. Pour en savoir plus, consultez la section Exporter des données.

Créer des instantanés de métadonnées de table gérée Iceberg

Pour créer un instantané de métadonnées de table gérée Iceberg, procédez comme suit :

  1. Exportez les métadonnées au format Iceberg V2 à l'aide de l'instruction SQL EXPORT TABLE METADATA.

  2. Facultatif : Planifiez l'actualisation des instantanés de métadonnées Iceberg. Pour actualiser un instantané de métadonnées Iceberg en fonction d'un intervalle de temps défini, utilisez une requête programmée.

  3. Facultatif : Activez l'actualisation automatique des métadonnées pour votre projet afin de mettre à jour automatiquement l'instantané des métadonnées de votre table Iceberg à chaque modification de la table. Pour activer l'actualisation automatique des métadonnées, contactez bigquery-tables-for-apache-iceberg-help@google.com. Des frais EXPORT METADATA s'appliquent à chaque opération d'actualisation.

L'exemple suivant crée une requête programmée nommée My Scheduled Snapshot Refresh Query à l'aide de l'instruction LDD EXPORT TABLE METADATA FROM mydataset.test. L'instruction LDD s'exécute toutes les 24 heures.

bq query \
    --use_legacy_sql=false \
    --display_name='My Scheduled Snapshot Refresh Query' \
    --schedule='every 24 hours' \
    'EXPORT TABLE METADATA FROM mydataset.test'

Afficher l'instantané des métadonnées d'une table gérée Iceberg

Après avoir actualisé l'instantané de métadonnées de la table gérée Iceberg, vous pouvez le trouver dans l'URI Cloud Storage dans lequel la table gérée Iceberg a été créée à l'origine. Le dossier /data contient les segments de données du fichier Parquet, et le dossier /metadata contient l'instantané des métadonnées de la table gérée Iceberg.

SELECT
  table_name,
  REGEXP_EXTRACT(ddl, r"storage_uri\s*=\s*\"([^\"]+)\"") AS storage_uri
FROM
  `mydataset`.INFORMATION_SCHEMA.TABLES;

Notez que mydataset et table_name sont des espaces réservés pour votre ensemble de données et votre table réels.

Lire des tables gérées Iceberg avec Spark

L'exemple suivant configure votre environnement pour utiliser Spark SQL avec Spark, puis exécute une requête pour extraire les données d'une table gérée Iceberg spécifiée.

spark-sql \
  --packages org.apache.iceberg:iceberg-spark-runtime-ICEBERG_VERSION_NUMBER \
  --conf spark.sql.catalog.CATALOG_NAME=org.apache.iceberg.spark.SparkCatalog \
  --conf spark.sql.catalog.CATALOG_NAME.type=hadoop \
  --conf spark.sql.catalog.CATALOG_NAME.warehouse='BUCKET_PATH' \

# Query the table
SELECT * FROM CATALOG_NAME.FOLDER_NAME;

Remplacez les éléments suivants :

  • ICEBERG_VERSION_NUMBER : version actuelle de l'environnement d'exécution. Téléchargez la dernière version sur la page Iceberg releases (versions Iceberg).
  • CATALOG_NAME : catalogue permettant de référencer votre table gérée Iceberg.
  • BUCKET_PATH : chemin d'accès au bucket contenant les fichiers de table. Exemple :gs://mybucket/
  • FOLDER_NAME : dossier contenant les fichiers de table. Exemple : myfolder.

Modifier des tables gérées Iceberg

Pour modifier une table gérée Iceberg, suivez la procédure décrite dans la section Modifier des schémas de table.

Utiliser des transactions multi-instructions

Vous pouvez utiliser des transactions à plusieurs instructions avec des tables gérées Iceberg de la même manière qu'avec des tables BigQuery standards. Les transactions multi-instructions sont couramment utilisées pour effectuer des mutations sur plusieurs tables en même temps ou pour effectuer des mutations sur une seule table en plusieurs étapes. Les transactions multi-instructions garantissent les propriétés ACID et prennent en charge l'isolation d'instantané.

Les limites standards des transactions multi-instructions s'appliquent.

Utiliser le partitionnement

Vous pouvez utiliser le partitionnement de table avec les tables gérées Iceberg de la même manière qu'avec les tables BigQuery standards. Pour partitionner une table, spécifiez une colonne de partition permettant de la segmenter. Les types de colonnes suivants sont compatibles avec les tables gérées Iceberg :

  • DATE
  • DATETIME
  • TIMESTAMP

Le partitionnement d'une table sur une colonne DATE, DATETIME ou TIMESTAMP est appelé partitionnement par colonnes d'unités de temps. Vous pouvez choisir le type de partitionnement : horaire, quotidien, mensuel ou annuel.

Les tables gérées Iceberg sont également compatibles avec le clustering et la combinaison de tables en cluster et tables partitionnées.

Limites du partitionnement

Créer une table gérée Iceberg partitionnée

Pour créer une table gérée Iceberg partitionnée, suivez les instructions permettant de créer une table gérée Iceberg standard et incluez l'un des éléments suivants, en fonction de votre environnement :

Vous pouvez définir et mettre à jour l'expiration de la partition de la même manière que pour les tables BigQuery standards. Les partitions arrivées à expiration sont récupérées après la fenêtre de fonctionnalité temporelle. Si vous ajoutez des données à une partition expirée, elles expirent instantanément.

Modifier et interroger des tables gérées Iceberg partitionnées

Les instructions et les requêtes du langage de manipulation de données (LMD) BigQuery pour les tables gérées Iceberg partitionnées sont les mêmes que pour les tables gérées Iceberg standards. BigQuery limite automatiquement le job aux partitions appropriées, de la même manière que le partitionnement masqué d'Iceberg. De plus, toutes les nouvelles données que vous ajoutez à la table sont automatiquement partitionnées.

Vous pouvez également interroger des tables gérées Iceberg partitionnées avec d'autres moteurs, de la même manière que les tables gérées Iceberg standards. Pour une expérience optimale, nous vous recommandons d'activer les instantanés de métadonnées.

Pour une sécurité renforcée, les informations de partitionnement des tables gérées Iceberg sont dissociées du chemin des données et sont entièrement gérées par la couche de métadonnées.

Tarifs

La tarification des tables gérées Iceberg comprend le stockage, l'optimisation du stockage, ainsi que les requêtes et les jobs.

Stockage

Les tables gérées par Iceberg stockent toutes les données dans Cloud Storage. Vous êtes facturé pour toutes les données stockées, y compris les données historiques des tables. Des frais de traitement des données et de transfert, liés à Cloud Storage, peuvent également s'appliquer. Certains frais d'opération Cloud Storage peuvent être annulés pour les opérations traitées via BigQuery ou l'API BigQuery Storage. Il n'y a pas de frais de stockage spécifiques à BigQuery. Pour en savoir plus, consultez la page Tarifs de Cloud Storage.

Optimisation du stockage

Les tables gérées Iceberg effectuent une gestion automatique des tables, y compris le compactage, le clustering, la récupération de mémoire et la génération/l'actualisation des métadonnées BigQuery pour optimiser les performances des requêtes et réduire les coûts de stockage. L'utilisation des ressources de calcul pour la gestion des tables est facturée en unités de calcul de données (DCU) au fil du temps, par incréments d'une seconde. Pour en savoir plus, consultez Tarifs des tables gérées Iceberg.

Les opérations d'exportation de données qui ont lieu lors du traitement par flux via l'API Storage Write sont incluses dans les tarifs de l'API Storage Write, et ne sont pas facturées comme des opérations de maintenance en arrière-plan. Pour en savoir plus, consultez les Tarifs d'ingestion de données.

Pour afficher les journaux et l'utilisation des ressources de calcul pour ces opérations en arrière-plan, interrogez la vue INFORMATION_SCHEMA.JOBS. Pour obtenir des exemples de requêtes, consultez les ressources suivantes :

Requêtes et jobs

Comme pour les tables BigQuery, vous êtes facturé pour les requêtes et les octets lus (par Tio), si vous utilisez la tarification à la demande de BigQuery, ou bien pour la consommation d'emplacements (par emplacement et par heure), si vous utilisez la tarification par capacité de calcul de BigQuery.

Les tarifs BigQuery s'appliquent également à l'API BigQuery Storage Read et à l'API Storage Write.

Les opérations de chargement et d'exportation (telles que EXPORT METADATA) utilisent des emplacements Enterprise Edition soumis au paiement à l'usage. Cela diffère des tables BigQuery, pour lesquelles ces opérations ne sont pas facturées. Si des réservations PIPELINE avec des emplacements Enterprise ou Enterprise Plus sont disponibles, les opérations de chargement et d'exportation utilisent de préférence ces emplacements de réservation.

Limites

Les tables gérées Iceberg présentent les limites suivantes :

  • Les tables gérées Iceberg ne sont pas compatibles avec les opérations de renommage ni les instructions ALTER TABLE RENAME TO.
  • Les tables gérées Iceberg ne sont pas compatibles avec les copies de tables ni avec les instructions CREATE TABLE COPY.
  • Les tables gérées Iceberg ne sont pas compatibles avec les clones de table ni avec les instructions CREATE TABLE CLONE.
  • Les tables gérées Iceberg ne sont pas compatibles avec les instantanés de table ni les instructions CREATE SNAPSHOT TABLE.
  • Les tables gérées Iceberg ne sont pas compatibles avec les schémas de table suivants :
  • Les tables gérées Iceberg ne sont pas compatibles avec les cas d'évolution de schéma suivants :
    • Coercitions du type NUMERIC en type FLOAT
    • Coercitions du type INT en type FLOAT
    • Ajout de champs imbriqués à des colonnes RECORD existantes à l'aide d'instructions LDD SQL
  • Les tables gérées Iceberg affichent une taille de stockage de 0 octet lorsqu'elles sont interrogées par la console ou les API.
  • Les tables gérées Iceberg ne sont pas compatibles avec les vues matérialisées.
  • Les tables gérées Iceberg ne sont pas compatibles avec les vues autorisées, mais le contrôle des accès au niveau des colonnes est possible.
  • Les tables gérées Iceberg ne sont pas compatibles avec la reprise après sinistre gérée.
  • Les tables gérées Iceberg ne sont pas compatibles avec la sécurité au niveau des lignes.
  • Les tables gérées Iceberg ne sont pas compatibles avec les périodes de prévention des défaillances.
  • Les tables gérées Iceberg ne sont pas compatibles avec les jobs d'extraction.
  • La vue INFORMATION_SCHEMA.TABLE_STORAGE n'inclut pas les tables gérées Iceberg.
  • Les tables gérées Iceberg ne sont pas acceptées en tant que destinations de résultats de requête. Vous pouvez utiliser l'instruction CREATE TABLE avec l'argument AS query_statement pour créer une table en tant que destination du résultat de la requête.
  • L'instruction CREATE OR REPLACE ne permet pas de remplacer des tables standards par des tables gérées Iceberg, ni des tables gérées Iceberg par des tables standards.
  • Le chargement par lot et les instructions LOAD DATA ne permettent que d'ajouter des données aux tables gérées Iceberg existantes.
  • Le chargement par lot et les instructions LOAD DATA ne sont pas compatibles avec les mises à jour de schéma.
  • TRUNCATE TABLE n'est pas compatible avec les tables gérées Iceberg. Il existe deux alternatives :
    • CREATE OR REPLACE TABLE, en utilisant les mêmes options de création de table.
    • L'instruction DELETE FROM table WHERE true.
  • La fonction de valeur de table APPENDS n'est pas compatible avec les tables gérées Iceberg.
  • Les métadonnées Iceberg peuvent ne pas contenir les données qui ont été diffusées vers BigQuery par l'API Storage Write au cours des 90 dernières minutes.
  • L'accès paginé basé sur les enregistrements à l'aide de tabledata.list n'est pas compatible avec les tables gérées Iceberg.
  • Une seule instruction LMD en mutation simultanée (UPDATE, DELETE et MERGE) s'exécute pour chaque table gérée Iceberg. Les instructions LMD en mutation supplémentaires sont mises en file d'attente.