Tables BigQuery pour Apache Iceberg

Pour obtenir de l'aide pendant la période de disponibilité en version preview, envoyez un e-mail à bigquery-tables-for-apache-iceberg-help@google.com.

Les tables BigQuery pour Apache Iceberg (ci-après dénommées les tables Iceberg) constituent la base de la création de lakehouses au format ouvert sur Google Cloud. Les tables Iceberg offrent la même expérience entièrement gérée que les tables BigQuery, mais stockent les données dans des buckets de stockage détenus par le client, en passant par Parquet afin d'assurer l'interopérabilité avec les formats de table ouverts Iceberg.

Les tables BigQuery pour Apache Iceberg sont distinctes des tables externes BigLake pour Apache Iceberg, car seules les tables BigQuery pour Apache Iceberg sont modifiables directement dans BigQuery. Les tables externes BigLake pour Apache Iceberg sont des tables en lecture seule générées à partir d'un autre moteur de requêtes, tel qu'Apache Spark, et ne peuvent être interrogées qu'à l'aide de BigQuery.

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

Architecture

Les tables Iceberg proposent les atouts de la gestion de ressources BigQuery, pour les tables qui se trouvent dans vos propres buckets cloud. Les tables Iceberg vous permettent d'utiliser BigQuery sur ces tables sans devoir déplacer les données hors des buckets que vous contrôlez.

Le schéma suivant illustre l'architecture générale des tables gérées : Schéma de l'architecture des tables BigQuery pour Iceberg

Cette gestion des tables 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.
  • Lorsque vous supprimez une table gérée dans BigQuery, BigQuery ne supprime pas les fichiers de données associés. Vous devez confirmer la suppression en supprimant manuellement du bucket les fichiers et les métadonnées de table exportées.
  • Les tables Iceberg n'entraînent aucun coût de stockage BigQuery. Pour en savoir plus, consultez la section Facturation.

La création d'une table 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, elle offre davantage de possibilités :

  • Spécifiez la connexion de ressources Cloud avec WITH CONNECTION, pour configurer les identifiants de connexion de BigLake afin d'accéder à Cloud Storage.
  • Spécifier le format de fichier pour le stockage de données avec file_format. PARQUET est compatible avec la version preview.
  • Spécifier le format de la table de métadonnées Open Source avec table_format. ICEBERG est compatible avec la version preview.

Bonnes pratiques

Modifier ou ajouter directement des 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.
Créez une table 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 Iceberg que dans des préfixes vides.
Modifier ou remplacer les fichiers de données de table 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 Iceberg.
Création de deux tables BigQuery pour Apache 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 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 Iceberg.

Considérations au sujet des emplacements

Vous pouvez améliorer les performances en utilisant des buckets Cloud Storage à région unique ou birégionaux au lieu des buckets multirégionaux.

Facturation

Les fonctionnalités suivantes sont facturées selon les tarifs publiés existants :

  • Tarifs de Cloud Storage pour toutes les données stockées dans les buckets Cloud Storage, le traitement des données effectué par Cloud Storage et l'utilisation du réseau pour la quantité de données lue dans votre bucket.
  • Tarifs de calcul BigQuery pour les requêtes, le LMD et l'optimisation du stockage en arrière-plan (y compris le clustering, l'agglomération et la récupération de mémoire).
    • Les frais liés aux réservations (emplacements) suivent les tarifs existants pour les emplacements.
    • Les frais basés sur des unités de gestion des stocks (SKU) à la demande suivent les tarifs à la demande existants. Pour en savoir plus, consultez la section Coûts associés à BigLake.
  • Le chargement par lot et l'opération de calcul Extract sont facturés à l'aide de SKU à la demande ou de réservations (emplacements).
  • Tarifs de l'API Storage Read pour la lecture à partir de Spark via l'API Read.
  • Tarifs de l'API Storage Write pour le traitement par flux.

Workflows associés aux tables Iceberg

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, 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.

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 la page 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 :

  • 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 projet
  • storage.objects.create sur votre projet
  • storage.objects.delete sur votre projet
  • storage.objects.get sur votre projet
  • storage.objects.list sur votre projet

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

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

SQL 

CREATE TABLE [PROJECT_NAME.]DATASET_NAME.TABLE_NAME (
COLUMN DATA_TYPE[, ...]
)
CLUSTER BY CLUSTER_COLUMN_LIST
WITH CONNECTION CONNECTION_NAME
OPTIONS (
file_format = 'PARQUET',
table_format = 'ICEBERG',
storage_uri = 'STORAGE_URI');

Remplacez les éléments suivants :

  • PROJECT_NAME : 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_NAME : 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 : 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.
  • STORAGE_URI : URI Cloud Storage complet. Par exemple, gs://mybucket/table.

bq 

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

Remplacez les éléments suivants :

  • PROJECT_NAME : 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. Par 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 : liste de quatre colonnes au maximum, séparées par des virgules. Ces colonnes doivent être des colonnes uniques de premier niveau.
  • 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 une table Iceberg

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

Chargement rapide à partir de fichiers Parquet

L'option copy_files_only vous permet de charger des données plus rapidement en copiant vos fichiers Parquet existants, plutôt que de lire le contenu et de le réécrire sous forme de nouveaux fichiers. Le chargement rapide utilise moins de capacité de calcul qu'un chargement de fichier standard. Les fichiers Parquet doivent être compatibles avec la spécification Apache Iceberg et comporter des statistiques de colonne complètes. Le chargement rapide ne détecte pas les valeurs non valides (telles que les codes temporels hors plage) présentes dans les fichiers, car ceux-ci ne sont pas lus ni retraités. Pour en savoir plus sur le chargement de fichiers Parquet, consultez la section Charger des données Parquet dans une nouvelle table.

Pour charger rapidement des fichiers Parquet plats dans une table Iceberg existante, utilisez la commande bq load:

bq load \
    --copy_files_only \
    --source_format=PARQUET \
    DATASET_NAME.TABLE_NAME \
    PATH_TO_SOURCE

Remplacez les éléments suivants :

  • DATASET_NAME: ensemble de données contenant votre table Iceberg.
  • TABLE_NAME: nom de la table Iceberg dans laquelle vous chargez des données.
  • PATH_TO_SOURCE : 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/mydata*.parquet.

Chargement standard de données à partir de fichiers plats

Les tables Iceberg utilisent des jobs de chargement BigQuery pour charger des fichiers externes dans des tables Iceberg. Si vous disposez d'une table 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 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, 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 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 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 Hive

Vous pouvez charger des fichiers partitionnés avec Hive dans des tables Iceberg à l'aide de jobs de chargement BigQuery standards. Pour en savoir plus, consultez la page 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 à l'aide d'un abonnement Pub/Sub BigQuery.

Exporter des données depuis des tables Iceberg

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

Exporter des données vers des formats de fichiers plats

Pour exporter une table 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.

Lire des tables Iceberg avec des métadonnées Iceberg

Pour lire les données des tables Iceberg au format Iceberg, procédez comme suit:

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

  2. Configurez et lisez les données de table dans Apache Spark avec HadoopCatalog.

    L'exemple suivant configure votre environnement pour utiliser Spark SQL avec Apache Iceberg, puis exécute une requête pour extraire les données d'une table 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' \

# Queries the table
spark-sql> SELECT * FROM CATALOG_NAME.FOLDER_NAME;

    Remplacez les éléments suivants :

    • ICEBERG_VERSION_NUMBER : version actuelle de l'environnement d'exécution Apache Spark/Iceberg. Téléchargez la dernière version sur la page Spark Releases (versions Spark).
    • CATALOG_NAME: catalogue permettant de référencer votre table 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 Iceberg

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

Tarifs

La tarification des tables Iceberg comprend trois composants distincts:

Stockage

Les tables 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 le cas échéant. 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 nécessitent des opérations d'optimisation du stockage, telles que l'agglomération de fichiers et le re-clustering. Ces opérations d'optimisation utilisent des emplacements Enterprise Edition soumis au paiement à l'usage, et n'utilisent pas les réservations BACKGROUND existantes.

Les opérations d'exportation de données qui ont lieu lors du traitement par flux via l'API BigQuery 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 la page Tarifs de l'ingestion de données.

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 BigQuery 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 présentent les limites suivantes: