Créer des tables BigLake Apache Iceberg

BigLake vous permet d'accéder aux tables Iceberg avec un contrôle des accès plus précis. Pour ce faire, vous devez d'abord créer une table BigLake Iceberg.

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 magasin d'objets.

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. Les tables BigLake fournissent des intégrations supplémentaires avec d'autres services BigQuery. Pour obtenir la liste complète des intégrations disponibles, consultez la section Présentation des tables BigLake.

Vous pouvez créer des tables BigLake Iceberg de différentes manières :

Avec BigLake Metastore (recommandé). BigLake Metastore est un catalogue personnalisé Iceberg. L'utilisation de BigLake Metastore est recommandée, car elle permet la synchronisation des tables entre les charges de travail Spark et BigQuery. Pour ce faire, vous pouvez utiliser une procédure stockée BigQuery pour Apache Spark afin d'initialiser BigLake Metastore et de créer la table BigLake Iceberg. Toutefois, les mises à jour de schéma nécessitent toujours d'exécuter une requête de mise à jour dans BigQuery. Pour obtenir la liste complète des limites, consultez la section Limites.
Avec fichier de métadonnées JSON Iceberg. 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. Pour éviter cela, utilisez BigLake Metastore. Vous pouvez utiliser une procédure stockée BigQuery pour Apache Spark afin de créer des tables BigLake Iceberg qui référencent un fichier de métadonnées Iceberg.

Avant de commencer

Activer les API BigQuery Connection, BigQuery Reservation et BigLake .
Activer les API
Si vous utilisez une procédure stockée pour Spark dans BigQuery pour créer des tables BigLake Iceberg, 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 BigLake 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.
Si vous utilisez BigLake Metastore, installez le catalogue personnalisé Iceberg approprié pour Apache Spark. Sélectionnez la version de catalogue personnalisée qui correspond le mieux à la version d'Iceberg que vous utilisez.
1. Iceberg 1.5.0 : gs://spark-lib/biglake/biglake-catalog-iceberg1.5.0-0.1.1-with-dependencies.jar
2. Iceberg 1.2.0 : gs://spark-lib/biglake/biglake-catalog-iceberg1.2.0-0.1.1-with-dependencies.jar
3. Iceberg 0.14.0 : gs://spark-lib/biglake/biglake-catalog-iceberg0.14.0-0.1.1-with-dependencies.jar

Rôles requis

Pour vous assurer que l'appelant de l'API BigLake dispose des autorisations nécessaires pour créer une table BigLake, demandez à votre administrateur d'accorder à l'appelant de l'API BigLake les rôles IAM suivants sur le projet :

Administrateur BigQuery (roles/bigquery.admin)
Administrateur BigLake (roles/biglake.admin)

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Ces rôles prédéfinis contiennent les autorisations requises pour créer une table BigLake. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour créer une table BigLake :

bigquery.tables.create
bigquery.connections.delegate
bigquery.jobs.create

Votre administrateur peut également attribuer ces autorisations à l'appelant de l'API BigLake avec des rôles personnalisés ou d'autres rôles prédéfinis.

En outre, pour permettre aux utilisateurs BigQuery d'interroger la table, le compte de service associé à la connexion doit disposer du rôle Lecteur BigLake (roles/biglake.viewer) et d'un accès au bucket Cloud Storage contenant ces données.

Pour créer des tables BigLake Iceberg avec BigLake Metastore, l'appelant de l'API BigLake change. Vous devez accorder au compte de service Dataproc ou Spark l'accès au bucket Cloud Storage contenant ces données :

Si vous exécutez Spark sur Dataproc, l'appelant dans Dataproc est le compte de service Dataproc.
Si vous exécutez des procédures Spark dans BigQuery, l'appelant est un compte de service de connexion Spark.

Créer des tables avec BigLake Metastore

Nous vous recommandons de créer des tables Iceberg BigLake avec BigLake Metastore. Vous pouvez utiliser Apache Spark pour créer ces tables. Pour ce faire, utilisez des procédures stockées BigQuery pour Spark en procédant comme suit :

Accédez à la page BigQuery.

Accéder à BigQuery
Dans le volet Explorateur, cliquez sur la connexion du projet que vous avez utilisé pour créer la ressource de connexion.
Pour créer une procédure stockée pour Spark, cliquez sur Créer une procédure stockée.
Dans l'éditeur de requête, modifiez l'exemple de code pour initialiser BigLake Metastore et créer une table Iceberg BigLake à l'aide de l'instruction CREATE PROCEDURE ci-après :
```
 # Creates a stored procedure that initializes BLMS and database.
 # Creates a table in the database and populates a few rows of data.
 CREATE OR REPLACE PROCEDURE iceberg_demo.iceberg_setup_3_3 ()
 WITH CONNECTION `PROCEDURE_CONNECTION_PROJECT_ID.PROCEDURE_CONNECTION_REGION.PROCEDURE_CONNECTION_ID`
 OPTIONS(engine="SPARK",
 jar_uris=["gs://spark-lib/biglake/biglake-catalog-iceberg1.2.0-0.1.0-with-dependencies.jar"],
 properties=[
 ("spark.jars.packages","org.apache.iceberg:iceberg-spark-runtime-3.3_2.12:1.2.0"),
 ("spark.sql.catalog.CATALOG", "org.apache.iceberg.spark.SparkCatalog"),
 ("spark.sql.catalog.CATALOG.catalog-impl", "org.apache.iceberg.gcp.biglake.BigLakeCatalog"),
 ("spark.sql.catalog.CATALOG.hms_uri: HMS_URI")
 ("spark.sql.catalog.CATALOG.gcp_project", "PROJECT_ID"),
 ("spark.sql.catalog.CATALOG.gcp_location", "LOCATION"),
 ("spark.sql.catalog.CATALOG.blms_catalog", "CATALOG"),
 ("spark.sql.catalog.CATALOG.warehouse", "DATA_WAREHOUSE_URI")
 ]
 )
 LANGUAGE PYTHON AS R'''
 from pyspark.sql import SparkSession

 spark = SparkSession \
   .builder \
   .appName("BigLake Iceberg Example") \
   .enableHiveSupport() \
   .getOrCreate()

 spark.sql("CREATE NAMESPACE IF NOT EXISTS CATALOG;")
 spark.sql("CREATE DATABASE IF NOT EXISTS CATALOG.CATALOG_DB;")
 spark.sql("DROP TABLE IF EXISTS CATALOG.CATALOG_DB.CATALOG_TABLE;")

 /* Create a BigLake Metastore table and a BigQuery Iceberg table. */
 spark.sql("CREATE TABLE IF NOT EXISTS CATALOG.CATALOG_DB.CATALOG_TABLE (id bigint, demo_name string)
           USING iceberg
           TBLPROPERTIES(bq_table='BQ_DATASET.BQ_TABLE', bq_connection='TABLE_CONNECTION_PROJECT_ID.TABLE_CONNECTION_REGION.TABLE_CONNECTION_ID');
           ")

 /* Copy a Hive Metastore table to BigLake Metastore. Can be used together with
    TBLPROPERTIES `bq_table` to create a BigQuery Iceberg table. */
 spark.sql("CREATE TABLE CATALOG.CATALOG_DB.CATALOG_TABLE (id bigint, demo_name string)
            USING iceberg
            TBLPROPERTIES(hms_table='HMS_DB.HMS_TABLE');")
 ''';
```
Remplacez les éléments suivants :
- PROCEDURE_CONNECTION_PROJECT_ID : projet contenant la connexion permettant d'exécuter des procédures Spark, par exemple myproject.
- PROCEDURE_CONNECTION_REGION : région contenant la connexion permettant d'exécuter des procédures Spark, par exemple us.
- PROCEDURE_CONNECTION_ID : ID de connexion, par exemple myconnection
  
  Lorsque vous affichez les détails de la connexion dans la console Google Cloud, il s'agit de la valeur de la dernière section de l'ID de connexion complet affiché dans ID de connexion (par exemple, projects/myproject/locations/connection_location/connections/myconnection).
- CATALOG : nom du catalogue Iceberg à créer pour BigLake Metastore.
  
  La valeur par défaut est iceberg.
- HMS_URI : si vous souhaitez copier des tables Hive Metastore existantes dans BigLake Metastore, spécifiez un URI Hive Metastore.
  
  Par exemple, thrift://localhost:9083.
- PROJECT_ID : ID du projet dans lequel vous souhaitez créer l'instance BigLake Metastore.
  
  Les tables BigLake Iceberg sont également créées dans le même projet.
- LOCATION : emplacement dans lequel vous souhaitez créer l'instance BigLake Metastore.
  
  BigQuery ne peut accéder qu'aux instances BigLake Metastore stockées dans le même emplacement.
- DATA_WAREHOUSE_URI : URI du bucket Cloud Storage que vous avez créé pour stocker les métadonnées et les fichiers de données Iceberg.
  
  Par exemple, gs://mybucket/iceberg-warehouse.
- CATALOG_DB : nom de la base de données que vous souhaitez créer dans BigLake Metastore.
  
  Cette base de données est équivalente à l'ensemble de données BigQuery qui contiendra la table BigLake Iceberg.
- CATALOG_TABLE : nom de la table que vous souhaitez créer dans BigLake Metastore.
  
  Cette table est équivalente à la table BigLake Iceberg que vous souhaitez créer.
- BQ_DATASET : ensemble de données BigQuery contenant la table BigLake Iceberg.
- BQ_TABLE : table BigLake Iceberg que vous souhaitez créer.
- TABLE_CONNECTION_PROJECT_ID : projet contenant la connexion à la création de la table BigLake, par exemple myproject.
- TABLE_CONNECTION_REGION : région contenant la connexion permettant de créer la table BigLake, par exemple us.
- TABLE_CONNECTION_ID : ID de connexion, par exemple myconnection
  
  Lorsque vous affichez les détails de la connexion dans la console Google Cloud, il s'agit de la valeur de la dernière section de l'ID de connexion complet affiché dans ID de connexion (par exemple, projects/myproject/locations/connection_location/connections/myconnection).
  
  Le compte de service associé à la connexion doit disposer du rôle roles/biglake.viewer pour permettre aux utilisateurs de BigQuery d'interroger la table.
- HMS_DB : si vous souhaitez copier des tables Hive Metastore existantes dans BigLake Metastore, spécifiez une base de données Hive Metastore.
- HMS_TABLE : si vous souhaitez copier des tables Hive Metastore existantes dans BigLake Metastore, spécifiez une table Hive Metastore.
Pour en savoir plus sur les configurations de catalogue Iceberg, consultez la page Catalogues Spark.
Pour exécuter la procédure stockée, cliquez sur Exécuter. Pour en savoir plus, consultez la section Appeler la procédure stockée Spark. Une table BigLake Iceberg est créée dans BigQuery.

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

Vous pouvez créer des tables BigLake Iceberg 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 BigLake à 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. Pour éviter cela, référencez une instance BigLake Metastore lorsque vous créez une table Iceberg BigLake.

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 :

SQL

Utilisez l'instruction CREATE EXTERNAL TABLE. L'exemple suivant crée une table BigLake nommée myexternal-table :

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

Remplacez la valeur uris par le dernier fichier de métadonnées JSON pour un instantané de table spécifique.

Vous pouvez activer l'option Demander un filtre de partitionnement en définissant l'option require_partition_filter.

bq

Dans un environnement de ligne de commande, exécutez la commande bq mk --table avec le décorateur @connection pour spécifier la connexion à utiliser à la fin du paramètre --external_table_definition : Pour activer l'option "Demander un filtre de partitionnement", utilisez --require_partition_filter.

bq mk 

    --table 

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

    PROJECT_ID:DATASET.EXTERNAL_TABLE

Remplacez les éléments suivants :

TABLE_FORMAT : nom de la table que vous souhaitez créer

Dans ce cas, ICEBERG.
URI : dernier fichier de métadonnées JSON pour un instantané de table spécifique

Par exemple, gs://mybucket/mydata/mytable/metadata/iceberg.metadata.json.
CONNECTION_PROJECT_ID : projet contenant la connexion permettant de créer la table BigLake, par exemple myproject
CONNECTION_REGION : région contenant la connexion permettant de créer la table BigLake, par exemple us
CONNECTION_ID : ID de connexion de la table, par exemple myconnection

Lorsque vous affichez les détails de la connexion dans la console Google Cloud, il s'agit de la valeur de la dernière section de l'ID de connexion complet affiché dans ID de connexion (par exemple, projects/myproject/locations/connection_location/connections/myconnection).
DATASET : nom de l'ensemble de données BigQuery dans lequel vous souhaitez créer une table

Par exemple, mydataset.
EXTERNAL_TABLE : nom de la table que vous souhaitez créer

Par exemple, mytable.

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

Si vous utilisez un fichier de métadonnées JSON pour créer des tables BigLake Iceberg, 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 :

bq

Créer un fichier de définition de table :

bq mkdef --source_format=ICEBERG \
"URI" > TABLE_DEFINITION_FILE

Exécutez la commande bq update avec l'option --autodetect_schema :
```
bq update --autodetect_schema --external_table_definition=TABLE_DEFINITION_FILE
PROJECT_ID:DATASET.TABLE
```
Remplacez les éléments suivants :
- URI : votre URI Cloud Storage par le dernier fichier de métadonnées JSON
  
  Par exemple, gs://mybucket/us/iceberg/mytable/metadata/1234.metadata.json.
- TABLE_DEFINITION_FILE : nom du fichier contenant le schéma de la table
- PROJECT_ID : ID du projet contenant la table que vous souhaitez mettre à jour
- DATASET : ensemble de données contenant la table que vous souhaitez mettre à jour
- TABLE : table dont vous souhaitez prendre un instantané

API

Utilisez la méthode tables.patch avec la propriété autodetect_schema définie sur true :

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

Remplacez les éléments suivants :

PROJECT_ID : ID du projet contenant la table que vous souhaitez mettre à jour
DATASET : ensemble de données contenant la table que vous souhaitez mettre à jour
TABLE : table dont vous souhaitez prendre un instantané

Dans le corps de la requête, spécifiez les valeurs mises à jour pour les champs suivants :

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

Remplacez URI par le dernier fichier de métadonnées Iceberg. Exemple : gs://mybucket/us/iceberg/mytable/metadata/1234.metadata.json.

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

Vous pouvez contrôler l'accès aux tables BigLake à l'aide de plusieurs méthodes :

Pour obtenir des instructions sur la configuration de la sécurité au niveau des colonnes, consultez le guide de la sécurité au niveau des colonnes.
Pour obtenir des instructions sur la configuration du masquage de données, consultez le guide de masquage de données.
Pour savoir comment configurer la sécurité au niveau des lignes, consultez le guide de la sécurité au niveau des lignes.

Par exemple, supposons que vous souhaitez limiter l'accès aux lignes de la table mytable dans l'ensemble de données mydataset :

+---------+---------+-------+
| country | product | price |
+---------+---------+-------+
| US      | phone   |   100 |
| JP      | tablet  |   300 |
| UK      | laptop  |   200 |
+---------+---------+-------+

Vous pouvez créer un filtre au niveau de la ligne pour Kim (kim@example.com), qui limite son accès aux lignes où country est égal à US.

CREATE ROW ACCESS POLICY only_us_filter
ON mydataset.mytable
GRANT TO ('user:kim@example.com')
FILTER USING (country = 'US');

Kim peut ensuite exécuter la requête suivante :

SELECT * FROM projectid.mydataset.mytable;

Le résultat n'affiche que les lignes où country est égal à US :

+---------+---------+-------+
| country | product | price |
+---------+---------+-------+
| US      | phone   |   100 |
+---------+---------+-------+

Interroger des tables BigLake

Pour en savoir plus, consultez la section Interroger des données Iceberg.

Mappage de données

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

Type de données Iceberg	Type de données BigQuery
`boolean`	`BOOL`
`int`	`INT64`
`long`	`INT64`
`float`	`FLOAT64`
`double`	`FLOAT64`
`Decimal(P/S)`	`NUMERIC or BIG_NUMERIC depending on precision`
`date`	`DATE`
`time`	`TIME`
`timestamp`	`DATETIME`
`timestamptz`	`TIMESTAMP`
`string`	`STRING`
`uuid`	`BYTES`
`fixed(L)`	`BYTES`
`binary`	`BYTES`
`list<Type>`	`ARRAY<Type>`
`struct`	`STRUCT`
`map<KeyType, ValueType>`	`ARRAY<Struct<key KeyType, value ValueType>>`

Limites

Les tables BigLake Iceberg sont soumises aux limites des tables BigLake, ainsi qu'aux limites suivantes :

La configuration copy-on-write est compatible, mais la configuration merge-on-read n'est pas compatible. Pour en savoir plus, consultez la section Configuration Iceberg.
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 BigLake Iceberg doivent contenir des littéraux dans les prédicats par rapport aux colonnes partitionnées.
La création de tables BigLake Iceberg dans la région BigQuery Omni Azure (azure-eastus2) n'est pas acceptée.
Seuls les fichiers de données Apache Parquet sont acceptés.
La propriété field_id doit être définie dans les métadonnées de tous les fichiers de données Iceberg pour associer les colonnes au schéma Iceberg. Les tables dotées de la propriété schema.name-mapping.default ne sont pas acceptées.
Les tables Hive migrées vers des tables Iceberg à l'aide des procédures stockées Spark d'Iceberg ne sont pas acceptées.
Si vous utilisez BigLake Metastore, les limites suivantes s'appliquent :
- BigLake Metastore n'est pas disponible dans les régions BigQuery Omni.
- Lorsque vous renommez une table, la table de destination doit se trouver dans la même base de données que la table source. La base de données de la table de destination doit être spécifiée explicitement.
- Lorsque vous inspectez une table de métadonnées Iceberg, vous devez utiliser un nom de table complet. Par exemple, prod.db.table.history.

Coûts

Des frais vous seront facturés à hauteur de 1 To, selon la tarification des requêtes à la demande (par To), pour 6 250 000 requêtes envoyées à BigLake Metastore ou pour 625 000 objets stockés dans BigLake Metastore. Les taux de la tarification des requêtes à la demande varient selon les régions. Pour un plus petit nombre de requêtes ou d'objets, vous serez facturé au prorata approprié de cette valeur de 1 To.

Par exemple, si vous avez envoyé 6 250 000 requêtes à BigLake Metastore et que vous y avez également stocké 312 500 objets, vous serez facturé à hauteur de 1,5 To, selon la tarification des requêtes à la demande applicable dans la région dans laquelle vous avez créé l'instance BigLake Metastore.

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 :

SQL

Utilisez l'instruction CREATE EXTERNAL TABLE. L'exemple suivant crée une table BigLake nommée TABLE avec l'option "Demander un filtre de partitionnement" activée :

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

Remplacez les éléments suivants :

TABLE : nom de la table que vous souhaitez créer.
PROJECT_ID : ID du projet contenant la table que vous souhaitez créer
REGION : emplacement dans lequel vous souhaitez créer la table Iceberg
CONNECTION_ID : ID de connexion Exemple :myconnection
URI : votre URI Cloud Storage avec le dernier fichier de métadonnées JSON

Par exemple, gs://mybucket/us/iceberg/mytable/metadata/1234.metadata.json.

bq

Exécutez la commande bq mk --table avec le décorateur @connection pour spécifier la connexion à utiliser à la fin du paramètre --external_table_definition. Utilisez --require_partition_filter pour activer l'option "Demander un filtre de partitionnement". L'exemple suivant crée une table BigLake nommée TABLE avec l'option "Demander un filtre de partitionnement" activée :

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

Remplacez les éléments suivants :

URI : dernier fichier de métadonnées JSON pour un instantané de table spécifique

Par exemple, gs://mybucket/mydata/mytable/metadata/iceberg.metadata.json.
CONNECTION_PROJECT_ID : projet contenant la connexion permettant de créer la table BigLake, par exemple myproject
CONNECTION_REGION : région contenant la connexion permettant de créer la table BigLake, par exemple us.
CONNECTION_ID : ID de connexion Exemple :myconnection

Lorsque vous affichez les détails de la connexion dans la console Google Cloud, il s'agit de la valeur de la dernière section de l'ID de connexion complet affiché dans ID de connexion (par exemple, projects/myproject/locations/connection_location/connections/myconnection).
DATASET : nom de

l'ensemble de données BigQuery contenant la table que vous souhaitez mettre à jour. Par exemple, mydataset.
EXTERNAL_TABLE : nom de la table que vous souhaitez créer

Par exemple, mytable.

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

Exécutez la commande bq update et spécifiez l'option --require_partition_filter.

Exemple :

Pour mettre à jour mypartitionedtable dans l'ensemble de données mydataset de votre projet par défaut, saisissez :

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 tables BigLake.
Apprenez à configurer des stratégies de contrôle d'accès.
Découvrez comment exécuter des requêtes dans BigQuery.
Découvrez les instructions compatibles avec les dialectes SQL dans BigQuery.