Tables Apache Iceberg

Les tables Apache Iceberg gérées par BigQuery (anciennement les tables BigLake pour Apache Iceberg dans BigQuery) constituent la base de la création de lakehouses au format ouvert sur Google Cloud. Les tables Iceberg gérées 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 Iceberg gérées sont compatibles avec le format de table Spark ouvert pour une meilleure interopérabilité avec les moteurs de calcul open source et tiers sur une seule copie des données.

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

Architecture

Les tables Iceberg gérées 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 les tables Iceberg gérées.

Les tables Iceberg gérées utilisent le catalogue du runtime Lakehouse comme catalogue de runtime unifié pour toutes les données Spark. Le catalogue d'exécution Lakehouse fournit une source unique de référence pour la gestion des métadonnées provenant de plusieurs moteurs et permet l'interopérabilité des moteurs.

L'utilisation de tables Apache 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.
  • La compaction et le clustering automatiques sont effectués sur les fichiers de données du bucket. Une fois la fenêtre temporelle expirée, les fichiers de données sont collectés par le garbage collector. 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 Spark 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 de 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 décrit 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 Iceberg gérées.
Création d'une table Spark 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 Iceberg gérées que dans des préfixes vides.
Modification ou remplacement de fichiers de données associés à des tables Spark. 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 Iceberg gérées.
Création de deux tables Iceberg gérées 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 Iceberg gérées. 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 Spark.

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é, la sécurité et la gouvernance de vos tables Iceberg gérées. Voici quelques bonnes pratiques pour vous aider à effectuer cette configuration :

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

  • Choisissez des buckets Cloud Storage à région unique qui se trouvent 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 classes de stockage. La classe automatique commence par la classe de stockage Standard et déplace les objets auxquels vous n'accédez pas vers des classes de stockage de plus en plus froides afin de réduire les coûts de stockage. Lorsque l'objet est lu à nouveau, 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 comptes de service appropriés.

  • Pour éviter toute suppression ou corruption accidentelle des données Spark 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 règle 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 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 Spark ont été supprimées, contactez l'assistance au lieu de restaurer les objets manuellement. En effet, 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 les coûts des fichiers.

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

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 de tables Spark

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

Avant de commencer

Avant de créer et d'utiliser des tables Iceberg gérées, assurez-vous d'avoir configuré une connexion à une ressource 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 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 Iceberg gérées

Pour créer une table Spark, 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 de la chaîne de connexion contenant PROJECT_ID.REGION.CONNECTION_ID.

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 Iceberg gérées

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

Chargement standard de données à partir de fichiers plats

Les tables Iceberg gérées utilisent des jobs de chargement BigQuery pour charger des fichiers externes dans des tables Iceberg gérées. Si vous disposez d'une table Spark, 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 Spark 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, 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 Spark 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 Apache 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 Apache Hive dans des tables Iceberg gérées à l'aide de jobs de chargement BigQuery standards. Pour en savoir plus, consultez Charger des données partitionnées externes.

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 Iceberg gérées à l'aide d'un abonnement Pub/Sub BigQuery.

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

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

Exporter des données vers des formats de fichiers plats

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

Créer des instantanés de métadonnées de table Spark

Pour créer un instantané des métadonnées de table Spark, procédez comme suit :

  1. Exportez les métadonnées au format Spark V2 avec l'instruction SQL EXPORT TABLE METADATA.

  2. Facultatif : Planifiez l'actualisation des instantanés de métadonnées Spark. Pour actualiser un instantané de métadonnées Spark 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 Spark à chaque modification de la table. Pour activer l'actualisation automatique des métadonnées, contactez bigquery-tables-for-apache-iceberg-help@google.com. Les coûts 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 DDL 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 un instantané des métadonnées d'une table Spark

Une fois que vous avez actualisé l'instantané des métadonnées de la table Spark, vous pouvez le trouver dans l'URI Cloud Storage dans lequel la table Spark a été créée à l'origine. Le dossier /data contient les partitions de données du fichier Parquet, et le dossier /metadata contient l'instantané des métadonnées de la table Spark.

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 tableau réels.

Lire les tables Iceberg gérées 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 Spark 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 Spark. Téléchargez la dernière version sur la page Spark Releases.
  • CATALOG_NAME : catalogue permettant de référencer votre table Spark.
  • 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 Iceberg gérées

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

Utiliser des transactions multi-instructions

Pour accéder aux transactions multi-instructions pour les tables Iceberg gérées, remplissez le formulaire d'inscription.

Utiliser le partitionnement

Pour accéder au partitionnement des tables Apache Iceberg, remplissez le formulaire d'inscription.

Pour partitionner une table, spécifiez une colonne de partition permettant de la segmenter. Les types de colonnes suivants sont acceptés pour les tables Iceberg gérées :

  • DATE
  • DATETIME
  • TIMESTAMP

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

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

Limites de partitionnement

Créer une table Spark partitionnée

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

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

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

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

Pour renforcer la sécurité, les informations de partitionnement des tables Iceberg gérées sont dissociées du chemin d'accès aux données et sont entièrement gérées par la couche de métadonnées.

Tarifs

La tarification des tables Spark comprend le stockage, l'optimisation du stockage, ainsi que les requêtes et les jobs.

Stockage

Les tables Iceberg gérées 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 Cloud Storage peuvent également s'appliquer. Certains frais d'opération Cloud Storage peuvent être supprimé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 Iceberg gérées effectuent une gestion automatique des tables, y compris la compaction, le clustering, la récupération de mémoire et la génération/l'actualisation des métadonnées BigQuery, afin d'optimiser les performances des requêtes et de 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 des données (DCU) au fil du temps, par incréments d'une seconde. Pour en savoir plus, consultez Tarifs des tables Apache 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 du 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 Iceberg gérées présentent les limites suivantes :

  • Les tables Iceberg gérées ne sont pas compatibles avec les opérations de renommage ni les instructions ALTER TABLE RENAME TO.
  • Schéma vide
  • Les tables Iceberg gérées 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 Iceberg gérées affichent une taille de stockage de 0 octet lorsqu'elles sont interrogées par la console ou les API.
  • Les tables Iceberg gérées ne sont pas compatibles avec les vues matérialisées.
  • Les tables Iceberg gérées ne sont pas compatibles avec les vues autorisées, mais le contrôle des accès au niveau des colonnes est accepté.
  • Les tables Iceberg gérées ne sont pas compatibles avec les mises à jour de capture des données modifiées (CDC).
  • Les tables Iceberg gérées ne sont pas compatibles avec la reprise après sinistre gérée.
  • Les tables Iceberg gérées ne sont pas compatibles avec la sécurité au niveau des lignes.
  • Les tables Iceberg gérées ne sont pas compatibles avec les périodes de prévention des défaillances.
  • Les tables Iceberg gérées ne sont pas compatibles avec les jobs d'extraction.
  • La vue INFORMATION_SCHEMA.TABLE_STORAGE n'inclut pas les tables Spark.
  • Les tables Iceberg gérées 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 comme destination des résultats de la requête.
  • L'instruction CREATE OR REPLACE ne permet pas de remplacer des tables standards par des tables Apache Iceberg, ni des tables Iceberg gérées par des tables standards.
  • Le chargement par lot et les instructions LOAD DATA ne permettent que d'ajouter des données aux tables Iceberg gérées 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 Iceberg gérées. 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 Iceberg gérées.
  • Il est possible que les métadonnées Spark ne contiennent pas les données diffusées dans 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 Apache Iceberg.
  • Une seule instruction LMD en mutation simultanée (UPDATE, DELETE et MERGE) s'exécute pour chaque table Spark. Les autres instructions LMD en mutation sont mises en file d'attente.