Tables gérées Apache Iceberg

Les tables gérées Apache Iceberg (anciennement appelées tables BigLake pour Apache Iceberg dans BigQuery) constituent la base de la création de lakehouses au format ouvert sur Cloud de Confiance by S3NS. Les tables gérées 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 des données.

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

• Mutations de table à l'aide du langage de manipulation de données (LMD) GoogleSQL.
• Traitement par lot et par flux unifié, à haut débit, à l'aide de l'API BigQuery Storage Write via des connecteurs tels que Spark, Dataflow et d'autres moteurs.
• Exportation de l'instantané Iceberg V2 et actualisation automatique à chaque modification de table pour un accès direct aux requêtes avec des moteurs de requête Open Source et tiers, tels que Spark.
• Évolution du schéma, qui vous permet d'ajouter, de supprimer et de renommer des colonnes en fonction de vos besoins. Cette fonctionnalité vous permet également de modifier le type de données et le mode d'une colonne existante. Pour en savoir plus, consultez Règles de conversion.
• Optimisation automatique du stockage, y compris la mise à l'échelle adaptative des fichiers, le clustering automatique, la récupération de mémoire et l'optimisation des métadonnées.
• Fonctionnalité temporelle pour accéder aux données historiques dans BigQuery.
• Sécurité au niveau des colonnes et masquage des données.
• Transactions multi-instructions (en version bêta)
• Partitionnement de table (en aperçu).
• Créer des tables dans les workflows Dataform

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 les 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.
• La compaction et le clustering automatiques sont effectués sur les fichiers de données du bucket. Une fois la période de voyage temporel expirée, les fichiers de données sont collectés en tant que déchets. 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 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 :

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 à effectuer cette configuration :

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

  • Espaces de noms hiérarchiques
  • Listes de contrôle d'accès (LCA) aux objets
  • Clés de chiffrement fournies par le client
  • Gestion des versions des objets
  • Verrouillage des objets
  • Verrou de bucket
  • Restaurer des objets supprimés de façon réversible avec l'API BigQuery ou la CLI bq

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 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 créer des tables Iceberg gérées :
  • Propriétaire de données BigQuery (roles/bigquery.dataOwner) sur votre projet
  • Administrateur de connexion BigQuery (roles/bigquery.connectionAdmin) sur votre projet
• Pour interroger des tables gérées Iceberg :
  • Lecteur de données BigQuery (roles/bigquery.dataViewer) sur votre projet
  • Utilisateur BigQuery (roles/bigquery.user) sur votre projet
• Attribuez les rôles suivants au compte de service de connexion pour qu'il puisse lire et écrire des données dans Cloud Storage :
  • Utilisateur d'objets Storage (roles/storage.objectUser) sur le bucket
  • Lecteur des anciens buckets de l'espace de stockage (roles/storage.legacyBucketReader) sur le bucket

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 :

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 :

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');

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

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

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 :

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

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

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

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 Exporter des données.

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

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

1. Exportez les métadonnées au format Iceberg V2 avec 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 mutation de 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 gérée Iceberg

Après avoir actualisé l'instantané des 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 fragments de données du fichier Parquet, et le dossier /metadata contient l'instantané des métadonnées de la table gérée par 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 tableau réels.

Lire les 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

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

Utiliser le partitionnement

Pour accéder au partitionnement des tables gérées 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 gérées Iceberg :

• 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 gérées Iceberg sont également compatibles avec le clustering et la combinaison de tables en cluster et partitionnées.

Limites de partitionnement

• Toutes les limites des tables partitionnées BigQuery s'appliquent.
• Les types de colonnes de partitionnement autres que DATE, DATETIME ou TIMESTAMP ne sont pas acceptés.
• L'expiration des partitions n'est pas prise en charge.
• L'évolution des partitions n'est pas acceptée.

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, puis incluez l'un des éléments suivants, selon votre environnement :

• Clause PARTITION BY
• Les options --time_partitioning_field et --time_partitioning_type
• Propriété timePartitioning

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 gérées Iceberg partitionnées sont les mêmes que pour les tables gérées Iceberg standards. BigQuery définit automatiquement le champ d'application du job sur les bonnes partitions, comme dans le partitionnement masqué Iceberg. De plus, toutes les nouvelles données que vous ajoutez à la table sont automatiquement partitionnées.

Vous pouvez également interroger les 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. 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 gérées Iceberg 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 gérées Iceberg 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 gérées Iceberg 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 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 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 pages suivantes :

• Jobs d'optimisation du stockage
• EXPORT TABLE METADATA jobs

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 gérées Iceberg ne sont pas compatibles avec les opérations de renommage ni les instructions ALTER TABLE RENAME TO.
• Les tables Iceberg gérées ne sont pas compatibles avec les copies de tables ni les instructions CREATE TABLE COPY.
• Les tables Iceberg gérées ne sont pas compatibles avec les clones de tables ni les instructions CREATE TABLE CLONE.
• Les tables Iceberg gérées ne sont pas compatibles avec les instantanés de table ni avec les instructions CREATE SNAPSHOT TABLE.
• Les tables gérées Iceberg ne sont pas compatibles avec les schémas de table suivants :
  • Schéma vide.
  • Schéma comportant les types de données BIGNUMERIC, INTERVAL, JSON, RANGE ou GEOGRAPHY.
  • Schéma comportant des classements de champs.
  • Schéma comportant des expressions de valeur par défaut.
• 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 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 accepté.
• Les tables gérées Iceberg ne sont pas compatibles avec les mises à jour de capture des données modifiées (CDC).
• Les tables gérées Iceberg 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 gérées Iceberg.
• 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 Iceberg gérées, 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 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.
• L'instruction 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 Iceberg gérées.
• Il est possible que les métadonnées Iceberg ne contiennent pas les données qui ont été diffusées en streaming 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 autres instructions LMD en mutation sont mises en file d'attente.