Créer des tables externes en lecture seule Apache Iceberg

Les tables externes en lecture seule Apache Iceberg vous permettent d'accéder aux tables Apache Iceberg avec un contrôle des accès plus précis, au format en lecture seule. Cette fonctionnalité contraste avec les tables BigLake pour Apache Iceberg dans BigQuery, qui vous permettent de créer des tables Iceberg dans BigQuery au format en écriture.

Iceberg est un format de table Open Source compatible avec les tables de données à l'échelle du pétaoctet. La spécification ouverte Iceberg vous permet d'exécuter plusieurs moteurs de requête sur une seule copie de données stockées dans un store d'objets. Les tables externes en lecture seule Apache Iceberg (ci-après appelées tables en lecture seule Iceberg) sont compatibles avec la version 2 de la spécification Iceberg, y compris la fusion lors de la lecture.

En tant qu'administrateur BigQuery, vous pouvez appliquer le contrôle des accès au niveau des lignes et des colonnes, y compris le masquage des données sur les tables. Pour en savoir plus sur la configuration du contrôle des accès au niveau de la table, consultez la page Configurer des stratégies de contrôle d'accès. Les stratégies d'accès aux tables sont également appliquées lorsque vous utilisez l'API BigQuery Storage en tant que source de données pour la table dans Dataproc et Spark sans serveur.

Vous pouvez créer des tables Iceberg en lecture seule de différentes manières:

• Avec BigLake Metastore (recommandé pour Trusted Cloud by S3NS). BigLake Metastore est basé sur le catalogue BigQuery et s'intègre directement à BigQuery. Les tables du métastore BigLake sont modifiables à partir de plusieurs moteurs Open Source, et les mêmes tables peuvent être interrogées à partir de BigQuery. Le metastore BigLake est également compatible avec l'intégration directe à Apache Spark.

• Avec AWS Glue Data Catalog (recommandé pour AWS). AWS Glue est la méthode recommandée pour AWS, car il s'agit d'un référentiel de métadonnées centralisé dans lequel vous définissez la structure et l'emplacement de vos données stockées dans divers services AWS. Il offre des fonctionnalités telles que la découverte automatique de schémas et l'intégration aux outils d'analyse AWS.

• Avec des fichiers de métadonnées JSON Iceberg (recommandé pour Azure). Si vous utilisez un fichier de métadonnées JSON Iceberg, vous devez mettre à jour manuellement le dernier fichier de métadonnées chaque fois que des tables sont mises à jour. Vous pouvez utiliser une procédure stockée BigQuery pour Apache Spark afin de créer des tables Iceberg en lecture seule qui référencent un fichier de métadonnées Iceberg.

Pour obtenir la liste complète des limites, consultez la section Limites.

Avant de commencer

• Enable the BigQuery Connection and BigQuery Reservation APIs.

  Enable the APIs

• Si vous utilisez une procédure stockée pour Spark dans BigQuery pour créer des tables Iceberg en lecture seule, procédez comme suit:

  1. Créez une connexion Spark.
  2. Configurez le contrôle des accès pour cette connexion.

• Pour stocker les métadonnées et les fichiers de données de la table Iceberg en lecture seule dans Cloud Storage, créez un bucket Cloud Storage. Vous devez vous connecter à votre bucket Cloud Storage pour accéder aux fichiers de métadonnées. Pour cela, procédez comme suit :

  1. Créez une connexion de ressource Cloud.
  2. Configurez l'accès pour cette connexion.

Rôles requis

Pour obtenir les autorisations nécessaires pour créer une table Iceberg en lecture seule, demandez à votre administrateur de vous accorder les rôles IAM suivants sur le projet:

• Administrateur BigQuery (roles/bigquery.admin)
• Administrateur des objets de l'espace de stockage (roles/storage.objectAdmin)

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 créer une table Iceberg en lecture seule. 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 avec BigLake Metastore

Nous vous recommandons de créer des tables Iceberg en lecture seule avec BigLake Metastore. Vous pouvez utiliser Apache Spark pour créer ces tables. Pour ce faire, utilisez des procédures stockées BigQuery. Pour obtenir un exemple, consultez la section Créer et exécuter une procédure stockée.

Créer des tables avec un fichier de métadonnées

Vous pouvez créer des tables Iceberg en lecture seule avec un fichier de métadonnées JSON. Toutefois, cette méthode n'est pas recommandée car vous devez mettre à jour l'URI du fichier de métadonnées JSON manuellement pour maintenir la table Iceberg en lecture seule à jour. Si l'URI n'est pas mis à jour, les requêtes dans BigQuery peuvent échouer ou fournir des résultats différents de ceux d'autres moteurs de requête, qui utilisent directement un catalogue Iceberg.

Les fichiers de métadonnées de la table Iceberg sont créés dans le bucket Cloud Storage que vous spécifiez lorsque vous créez une table Iceberg à l'aide de Spark.

Sélectionnez l'une des options suivantes :

  CREATE EXTERNAL TABLE myexternal-table
  WITH CONNECTION `myproject.us.myconnection`
  OPTIONS (
         format = 'ICEBERG',
         uris = ["gs://mybucket/mydata/mytable/metadata/iceberg.metadata.json"]
   )

bq mk 

    --table 

    --external_table_definition=TABLE_FORMAT=URI@projects/CONNECTION_PROJECT_ID/locations/CONNECTION_REGION/connections/CONNECTION_ID 

    PROJECT_ID:DATASET.EXTERNAL_TABLE

Mettre à jour les métadonnées d'une table

Si vous utilisez un fichier de métadonnées JSON pour créer une table Iceberg en lecture seule, mettez à jour la définition de la table avec les dernières métadonnées de la table. Pour mettre à jour le schéma ou le fichier de métadonnées, sélectionnez l'une des options suivantes:

PATCH https://bigquery.googleapis.com/bigquery/v2/projects/PROJECT_ID/datasets/DATASET/tables/TABLE?autodetect_schema=true

{
     "externalDataConfiguration": {
      "sourceFormat": "ICEBERG",
      "sourceUris": [
        "URI"
      ]
    },
    "schema": null
  }'

Configurer des stratégies de contrôle d'accès

Vous pouvez contrôler l'accès aux tables en lecture seule Iceberg à l'aide de la sécurité au niveau des colonnes, de la sécurité au niveau des lignes et du masquage des données.

Mappage de données

BigQuery convertit les types de données Iceberg en types de données BigQuery, comme indiqué dans le tableau suivant :

Limites

Les tables en lecture seule Iceberg sont soumises aux limites des tables externes et aux limites suivantes:

• Les tables utilisant la fusion lors de la lecture présentent les limites suivantes:

  • Chaque fichier de données peut être associé à 10 000 fichiers de suppression maximum.
  • Vous ne pouvez pas appliquer plus de 100 000 ID d'égalité à un fichier de suppression.
  • Vous pouvez contourner ces limites en compactant fréquemment les fichiers de suppression ou en créant une vue au-dessus du tableau Iceberg qui évite les partitions fréquemment mutées.

• BigQuery accepte l'élagage des fichiers manifestes à l'aide de toutes les fonctions de transformation de partition Iceberg, à l'exception de Bucket. Pour en savoir plus sur l'élimination des partitions, consultez la section Interroger des tables partitionnées. Les requêtes faisant référence à des tables Iceberg en lecture seule doivent contenir des littéraux dans les prédicats par rapport aux colonnes partitionnées.

• Seuls les fichiers de données Apache Parquet sont acceptés.

Coûts de fusion lors de la lecture

La facturation à la demande pour les données de fusion lors de la lecture correspond à la somme des analyses des données suivantes:

• Tous les octets logiques lus dans le fichier de données (y compris les lignes marquées comme supprimées par position et les suppressions d'égalité).
• Les octets logiques lus lors du chargement de la suppression d'égalité et de la position suppriment les fichiers pour trouver les lignes supprimées dans un fichier de données.

Demander un filtre de partitionnement

Vous pouvez exiger l'utilisation de filtres de prédicat en activant l'option Demander un filtre de partitionnement pour votre table Iceberg. Si vous activez cette option, toute tentative d'interrogation de la table sans spécifier de clause WHERE alignée sur chaque fichier manifeste génère l'erreur suivante :

Cannot query over table project_id.dataset.table without a
filter that can be used for partition elimination.

Chaque fichier manifeste nécessite au moins un prédicat adapté à l'élimination de partitions.

Vous pouvez activer require_partition_filter de différentes manières lors de la création d'une table Iceberg :

  CREATE EXTERNAL TABLE TABLE
  WITH CONNECTION `PROJECT_ID.REGION.CONNECTION_ID`
  OPTIONS (
         format = 'ICEBERG',
         uris = [URI],
         require_partition_filter = true
   )

bq mk \
    --table \
    --external_table_definition=ICEBERG=URI@projects/CONNECTION_PROJECT_ID/locations/CONNECTION_REGION/connections/CONNECTION_ID \
    PROJECT_ID:DATASET.EXTERNAL_TABLE \
    --require_partition_filter

Vous pouvez également mettre à jour votre table Iceberg pour activer l'option "Demander un filtre de partitionnement".

Si vous n'activez pas l'option Demander un filtre de partitionnement lorsque vous créez la table partitionnée, vous pouvez mettre la table à jour pour ajouter l'option.

bq update --require_partition_filter PROJECT_ID:DATASET.TABLE

Étapes suivantes

• Apprenez-en plus sur la procédure stockée pour Spark.
• Découvrez les stratégies de contrôle des accès.
• Découvrez comment exécuter des requêtes dans BigQuery.
• Découvrez les instructions compatibles avec les dialectes SQL dans BigQuery.