Interrogation des tables d'iceberg Apache avec Autonomous Database on Dedicated Exadata Infrastructure

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

Remarques :

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 :

Tableaux Iceberg sur Amazon Web Services AWS :
- Tableaux Iceberg enregistrés avec AWS Glue Data Catalog, créés avec Spark ou Athena.
  Pour plus d'informations, reportez-vous à Utilisation du 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 de tables Iceberg.
- Tables d'iceberg stockées sur AWS S3 en fournissant directement l'URL du fichier de métadonnées racine.
Tables d'iceberg sur Oracle Cloud Infrastructure (OCI) Object Storage :
- Tables d'iceberg générées avec OCI Data Flow à l'aide d'un catalogue Hadoop.
  Pour plus d'informations, reportez-vous à Exemples Oracle Data Flow et à Utilisation d'un catalogue Hadoop.
- Tables d'iceberg stockées sur OCI Object Storage 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.
Mise à jour au niveau des lignes des tables Iceberg
Oracle ne prend pas en charge la fusion sur lecture pour les mises à jour de table Iceberg. Les requêtes rencontrant des fichiers supprimés dans les métadonnées de l'iceberg échoueront. Pour plus d'informations sur la fusion en lecture, reportez-vous à l'Enum RowLevelOperationMode.
Evolution du schéma
Le schéma des tables externes Oracle est fixe et reflète la version du schéma Iceberg au moment de la création de la table externe. Les requêtes é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

Procédure CREATE_EXTERNAL_TABLE pour Apache Iceberg

Concepts liés à l'interrogation des tables d'iceberg Apache

Il est utile de comprendre les concepts suivants 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 cliché 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. Un certain nombre d'implémentations de catalogue sont déjà 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, reportez-vous à la rubrique Accès simultané optimiste.

Fichiers de métadonnées

Le fichier de métadonnées est un document JSON qui assure le suivi des clichés de table, du schéma 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 assurent le suivi des fichiers de données de la table, ainsi que des informations telles que les statistiques de partitionnement et de colonne. Pour plus d'informations, reportez-vous à la spécification de table Iceberg.

Transactions

Iceberg prend en charge les mises à jour de niveau ligne des tables à l'aide de la copie lors de l'écriture ou de la fusion lors de la lecture. Copy-on-write génère de nouveaux fichiers de données qui reflètent les lignes mises à jour, tandis que Merge-on-read 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 lors de l'écriture. Les requêtes sur les tables d'iceberg échouent si elles rencontrent un fichier de suppression. Pour plus d'informations, reportez-vous à RowLevelOperationMode.

Evolution du schéma

Iceberg soutient l'évolution des schémas. Les modifications de schéma sont reflétées dans les métadonnées Iceberg à l'aide d'un ID de schéma. 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 requêtes 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 Evolution du schéma.

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 modifications coûteuses de la disposition des données.

Exemples : interroger des tables d'iceberg Apache

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 d'URL directes pour le fichier manifeste racine.

Pour plus d'informations sur la création de tables externes pour Apache Iceberg, reportez-vous à la procédure CREATE_EXTERNAL_TABLE pour Apache Iceberg.

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

Dans cet exemple, nous interrogeons la table Iceberg iceberg_parquet_time_dim. Description de l'image example_1_table.png ci-après
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 :

Description de l'image example_1_details_v1.png

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 indiquons que la table utilise AWS Glue comme type de catalogue et que la région du catalogue est définie sur us-west-1.

Les informations d'identification AWS_CRED sont créées à l'aide de dbms_cloud.create_credential avec une clé d'API AWS. L'instance Glue Data Catalog est déterminée par l'ID de compte associé à AWS_CRED pour la région us-west-1, car il existe une seule région Glue Data Catalog pour chaque compte. L'élément iceberg_table_path de la section protocol_config utilise un chemin $database_name.$table_name pour indiquer le nom de la table Glue 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'information sur la création de ces infos d'identification, reportez-vous à Procédure CREATE_CREDENTIAL.

Pour plus d'informations sur les ressources AWS Glue, reportez-vous à Spécification des ARN de ressource 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 indiquer l'emplacement du fichier de métadonnées dans le format d'URL de type hébergé virtuel AWS S3. Pour plus d'informations sur ce format, reportez-vous à Méthodes d'accès à un bucket 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 le cliché 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 d'iceberg qui utilise le catalogue Hadoop sur OCI

Dans cet exemple, nous interrogeons la table Iceberg icebergTablePy, créée à l'aide d'OCI Data Flow, où Spark utilise l'implémentation 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. Pour obtenir l'exemple sur Github, reportez-vous à Prise en charge d'Iceberg sur OCI Data Flow.

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

Description de l'image example_3_table_v1.png

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 indiquer l'URI du fichier de métadonnées à l'aide du format d'URI OCI natif. Lorsque vous utilisez l'URI du fichier de métadonnées, la table externe interroge toujours le dernier cliché stocké dans le fichier spécifique. Les mises à jour suivantes qui génèrent de nouveaux clichés et de nouveaux fichiers de métadonnées ne sont pas accessibles à la requête.

Pour plus d'informations sur le format d'URI OCI natif, reportez-vous à Formats d'URI Cloud Object Storage.

Informations relatives au titre et au copyright

Oracle et/ou ses affiliés.