Interroger les tables Apache Iceberg avec Autonomous Database sur une infrastructure Exadata dédiée

Autonomous Database prend en charge l'interrogation des tables Apache Iceberg.

Note :

La prise en charge de l'interrogation des tables Apache Iceberg est disponible dans Oracle Database 19c à partir de la version 19.28 et dans Oracle Database 23ai à partir de la version 23.9.

Configurations prises en charge

Ces configurations spécifiques sont prises en charge :

Iceberg tables sur Amazon Web Services AWS :
- Tables Iceberg enregistrées avec AWS Glue Data Catalog, créées avec Spark ou Athena.
  Pour plus d'informations, voir Utiliser le connecteur AWS Glue pour lire et écrire des tables Apache Iceberg avec des transactions ACID et effectuer des déplacements dans le temps et Utilisation des tables Iceberg.
- Tables Iceberg stockées sur AWS S3 en fournissant directement l'URL du fichier de métadonnées racine.
Tables Iceberg sur le service de stockage d'objets pour Oracle Cloud Infrastructure (OCI) :
- Tables Iceberg générées avec le service de flux de données OCI à l'aide d'un catalogue Hadoop.
  Pour plus d'informations, voir Exemples de flux de données Oracle et Utilisation d'un catalogue Hadoop.
- Tables Iceberg stockées dans le service de stockage d'objets pour OCI en fournissant directement l'URL du fichier de métadonnées racine.

Restrictions

Tables d'iceberg partitionnées
Oracle ne prend pas en charge les tables partitionnées Iceberg.
Mises à jour au niveau des rangées des tables d'Iceberg
Oracle ne prend pas en charge la fusion-lecture pour les mises à jour de table Iceberg. Les interrogations rencontrant des fichiers supprimés dans les métadonnées Iceberg échoueront. Pour plus d'informations sur la fusion en lecture, voir Énumérer RowLevelOperationMode.
Évolution du schéma
Le schéma des tables externes Oracle est fixe et reflète la version du schéma Iceberg lors de la création de la table externe. Les interrogations échouent si les métadonnées Iceberg pointent vers une version de schéma différente de celle utilisée pour créer la table Iceberg. Si le schéma Iceberg change après la création de la table externe, il est recommandé de recréer la table externe.

Rubriques connexes

CREATE_EXTERNAL_TABLE Procédure pour Apache Iceberg

Concepts liés à l'interrogation des tables Apache Iceberg

Une compréhension des concepts suivants est utile pour interroger les tables Apache Iceberg.

Catalogue Iceberg

Le catalogue Iceberg est un service qui gère les métadonnées de table, telles que les instantanés de table, le schéma de table et les informations de partitionnement. Pour interroger le dernier instantané d'une table Iceberg, les moteurs de requête doivent d'abord accéder au catalogue et obtenir l'emplacement du fichier de métadonnées le plus récent. Il existe déjà un certain nombre de mises en oeuvre de catalogue disponibles, notamment AWS Glue, Hive, Nessie et Hadoop. Autonomous Database prend en charge le catalogue AWS Glue et l'implémentation HadoopCatalog utilisée par Spark.

Pour plus d'informations, voir Accès simultané optimiste.

Fichiers de métadonnées

Le fichier de métadonnées est un document JSON qui assure le suivi des instantanés de table, du modèle de partitionnement et des informations de schéma. Le fichier de métadonnées est le point d'entrée d'une hiérarchie de listes de manifestes et de fichiers manifestes. Les manifestes suivent les fichiers de données de la table ainsi que des informations telles que le partitionnement et les statistiques de colonne. Pour plus d'informations, voir Spécification de table Iceberg.

Transactions

Iceberg prend en charge les mises à jour au niveau ligne des tables à l'aide de la copie sur écriture ou de la fusion sur lecture. La copie sur écriture génère de nouveaux fichiers de données qui reflètent les lignes mises à jour, tandis que la fusion sur lecture génère de nouveaux "fichiers de suppression" qui doivent être fusionnés avec les fichiers de données lors de la lecture. Oracle prend en charge la copie sur écriture. Les interrogations sur les tables iceberg échouent si elles rencontrent un fichier de suppression. Pour plus de renseignements, consultez la page RowLevelOperationMode.

Évolution du schéma

Iceberg prend en charge l'évolution du schéma. Les modifications de schéma sont répercutées dans les métadonnées Iceberg à l'aide d'un ID schéma. Notez que les tables externes Oracle ont un schéma fixe, déterminé par la version de schéma la plus récente lors de la création de la table. Les interrogations Iceberg échouent lorsque les métadonnées interrogées pointent vers une version de schéma différente de celle utilisée lors de la création de la table. Pour plus d'informations, voir Évolution des schémas.

Partitionnement

Iceberg prend en charge des options de partitionnement avancées, telles que le partitionnement masqué et l'évolution des partitions, qui reposent sur le traitement/la modification des métadonnées de la table sans modification coûteuse de la disposition des données.

Exemples : Interroger Apache Iceberg Tables

Ces exemples montrent comment interroger les tables Apache Iceberg sur Amazon Web Services (AWS) et Oracle Cloud Infrastructure (OCI), à l'aide d'un catalogue de données et à l'aide d'URL directes pour le fichier manifeste racine.

Pour des informations détaillées sur la création de tables externes pour Apache Iceberg, voir Procédure CREATE_EXTERNAL_TABLE pour Apache Iceberg.

Interroger une table Iceberg sur AWS à l'aide d'un catalogue de données de colle

Dans cet exemple, nous interrogeons la table Iceberg iceberg_parquet_time_dim. Une description de example_1_table.png suit
Description de l'illustration example_1_table.png

La table appartient à la base de données Glue my-iceberg-db et est stockée dans le dossier s3://my-iceberg-bucket/iceberg-loc.

Les détails du tableau pour iceberg_parquet_time_dim sont affichés ici :

Une description de example_1_details_v1.png suit

Description de l'illustration example_1_details_v1.png

Nous pouvons créer une table externe pour iceberg_parquet_time_dim comme suit :

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE (
    table_name       => 'iceberg_parquet_time_dim',
    credential_name  => 'AWS_CRED',
    file_uri_list    => '',
    format           =>
      '{"access_protocol":
        {
         "protocol_type": "iceberg",
         "protocol_config":
          {
           "iceberg_catalog_type": "aws_glue",
           "iceberg_glue_region": "us-west-1",
           "iceberg_table_path": "my-iceberg-db.iceberg_parquet_time_dim"
          }
        }
      }'
  );
END;
/

Dans la section protocol_config, nous spécifions que la table utilise AWS Glue comme type de catalogue et réglons la région du catalogue à us-west-1.

Les données d'identification AWS_CRED sont créées à l'aide de dbms_cloud.create_credential avec une clé d'API AWS. L'instance de catalogue de données de colle est déterminée par l'ID compte associé à AWS_CRED pour la région us-west-1, car il existe une seule région de catalogue de données de colle pour chaque compte. L'élément iceberg_table_path de la section protocol_config utilise un chemin $database_name.$table_name pour spécifier le nom de la table de colle et le nom de la base de données. Enfin, les paramètres column_list et field_list restent nuls car le schéma de la table est automatiquement dérivé des métadonnées Iceberg.

Pour plus d'informations sur la création des données d'identification, voir ProcédureCREATE_CREDENTIAL.

Pour plus d'informations sur les ressources AWS Glue, voir Spécification des ARN des ressources AWS Glue.

Interroger une table Iceberg sur AWS à l'aide de l'emplacement du fichier de métadonnées racine

Si nous connaissons l'emplacement du fichier de métadonnées d'une table Iceberg, nous pouvons créer une table externe sans spécifier de catalogue, comme suit :

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE (
    table_name       => 'iceberg_parquet_time_dim',
    credential_name  => 'AWS_CRED',
    file_uri_list    => 'https://my-iceberg-bucket.s3.us-west-1.amazonaws.com/iceberg-loc/metadata/00004-1758ee2d-a204-4fd9-8d52-d17e5371a5ce.metadata.json',
    format           =>'{"access_protocol":{"protocol_type":"iceberg"}}');
END;
/

Nous utilisons le paramètre file_uri_list pour spécifier l'emplacement du fichier de métadonnées dans le format d'URL de style hébergé virtuel AWS S3. Pour plus d'informations sur ce format, voir Méthodes d'accès à un seau AWS S3.

Dans cet exemple, la base de données accède directement au fichier de métadonnées. Il n'est donc pas nécessaire de fournir une section protocol_config dans le paramètre format. Lorsque vous utilisez l'emplacement du fichier de métadonnées pour créer une table externe, la base de données interroge l'instantané le plus récent référencé par le fichier de métadonnées. Les mises à jour ultérieures de la table Iceberg, qui créent de nouveaux instantanés et de nouveaux fichiers de métadonnées, ne seront pas visibles par la base de données.

Interroger une table Iceberg qui utilise le catalogue Hadoop sur OCI

Dans cet exemple, nous interrogeons la table Iceberg icebergTablePy, créée à l'aide du service de flux de données pour OCI, où Spark utilise la mise en oeuvre HadoopCatalog pour le catalogue Iceberg. HadoopCatalog utilise un répertoire warehouse et place les métadonnées Iceberg dans un sous-dossier $database_name/$table_name sous ce répertoire. Il utilise également un fichier version-hint.text qui contient le numéro de version de la version la plus récente du fichier de métadonnées. Voir Prise en charge d'Iceberg sur le service de flux de données pour OCI pour l'exemple sur Github.

La table d'exemple db.icebergTablePy a été créée à l'aide d'un dossier warehouse, nommé iceberg, dans le seau OCI my-iceberg-bucket. La disposition du stockage sur OCI pour le tableau icebergTablePy est affichée ci-dessous :

Une description de example_3_table_v1.png suit

Description de l'illustration example_3_table_v1.png

Créez une table externe pour la table db.icebergTablePy comme suit :

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE (
    table_name       => 'iceberg_parquet_time_dim3',
    credential_name  => 'OCI_CRED',
    file_uri_list    => '',
    format           =>'{"access_protocol":{"protocol_type":"iceberg",
        "protocol_config":{"iceberg_catalog_type": "hadoop",
        "iceberg_warehouse":"https://objectstorage.uk-cardiff-1.oraclecloud.com/n/my-tenancy/b/my-iceberg-bucket/o/iceberg",
        "iceberg_table_path": "db.icebergTablePy"}}}');
END;
/

Interroger une table Iceberg sur OCI à l'aide de l'emplacement du fichier de métadonnées racine

Nous pouvons interroger la table Iceberg décrite dans la section précédente en utilisant directement l'URL du fichier de métadonnées, comme suit :

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE (
    table_name       => 'iceberg_parquet_time_dim4',
    credential_name  => 'OCI_CRED',
    file_uri_list    => 'https://objectstorage.uk-cardiff-1.oraclecloud.com/n/my-tenancy/b/my-iceberg-bucket/o/iceberg/db/icebergTablePy/metadata/v2.metadata.json',
    format           =>'{"access_protocol":{"protocol_type":"iceberg"}}'
    );
  END;
/

Dans cet exemple, nous utilisons le paramètre file_uri_list pour spécifier l'URI du fichier de métadonnées à l'aide du format d'URI OCI natif. Lors de l'utilisation de l'URI du fichier de métadonnées, la table externe interroge toujours le dernier instantané stocké dans le fichier spécifique. Les mises à jour suivantes qui génèrent de nouveaux instantanés et de nouveaux fichiers de métadonnées ne sont pas accessibles à l'interrogation.

Pour plus d'informations sur le format d'URI OCI natif, voir Formats d'URI du service de stockage d'objets en nuage.

Titre et informations sur les droits d'auteur

Oracle et/ou ses sociétés affiliées.