Interroger les tables d'iceberg Apache

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

A propos de l'interrogation des tables d'iceberg Apache

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

Configurations prises en charge

Voici la matrice de compatibilité de la configuration prise en charge :

Catalogue Magasins d'objets Authentification de catalogue (REST) Authentification de stockage Notes
Unity (briques de données) Amazon S3, Azure ADLS Gen2 OAuth2 principal de service (/oidc/v1/token) - recommandé ; PAT - tests rapides Clé d'accès/secret S3 ; clé SAS Gen2 ADLS
  • UniForm requis (Lisible par delta à iceberg). Iceberg natif via Iceberg REST pas encore pris en charge par notre intégration ; utilisez Delta+UniForm via …/api/2.1/unity-catalog/iceberg ;

  • La distribution des informations d'identification de banque d'objets n'est pas prise en charge.
Polaris (lac de neige) Amazon S3, Azure ADLS Gen2 OAuth2 (informations d'identification client) ou jeton pris en charge par Polaris Clé d'accès/secret S3 ; clé SAS Gen2 ADLS La distribution des informations d'identification de banque d'objets n'est pas prise en charge.
AWS Glue Amazon S3 S/O (utilise l'authentification du compte AWS) S3 accès/clé secrète ; La distribution des informations d'identification de banque d'objets n'est pas prise en charge. Les mêmes informations d'identification doivent être utilisées pour S3 et Glue. S3 et Glue doivent se trouver dans la même région AWS.
Métadonnées JSON (option hors catalogue) Amazon S3, Azure ADLS Gen2, banque d'objets OCI S/O (pas de REST) Clé d'accès/secret S3 ; clé SAS Gen2 ADLS, informations d'identification natives OCI Pointez ADB vers le fichier metadata.json de la table (manifeste racine). Instantané ponctuel ; recréez la table externe après la modification du schéma ou le nouvel instantané.
Hadoop (hors catalogue) OCI Object Storage S/O (pas de REST) Informations d'identification native OCI pointe vers un dossier de lakehouse qui contient des fichiers de données et de métadonnées.

Restrictions relatives à l'interrogation des tables d'iceberg Apache

Ce chapitre répertorie les restrictions d'interrogation des tables Apache Iceberg.

Catalogues et interopérabilité
  • Iceberg (REST) natif d'Unity : non pris en charge.

    Solution de contournement : utilisez Delta + UniForm pour publier une vue lisible par Iceberg via l'adresse REST Iceberg d'Unity Catalog.

  • Catalogues REST certifiés : ADB est certifié avec les options Snowflake Polaris et Databricks Unity Catalog (UniForm uniquement) pour l'accès en lecture Iceberg.
Authentification et informations d'identification :
  • Distribution des informations d'identification de catalogue : non prise en charge.

    La distribution cloud native basée sur les rôles, telle que l'hypothèse de rôle automatique ou les informations d'identification temporaires émises par STS, n'est pas prise en charge. Utilisez des clés d'accès/secret explicites ou des jetons statiques.)

  • Informations d'identification AWS ARN : non prises en charge. Les ARN de rôle IAM et AssumeRole via ARN ne sont pas acceptés.
Sémantique des tables et LMD
  • Les tables Iceberg partitionnées ne sont pas prises en charge ; seules les tables non partitionnées sont autorisées.
  • Mises à jour de niveau ligne (fusion sur lecture) : non pris en charge. Si les métadonnées Iceberg font référence à des fichiers de suppression, les requêtes échoueront.
Evolution des schémas et des métadonnées
  • Le schéma d'une table externe fixe est déterminé lors de la création et doit être aligné sur la version du schéma Iceberg dans les métadonnées. Si le schéma Iceberg est mis à jour, la table externe doit être recréée.
Instantanés et temps de déplacement
  • Pas de temps de requête : l'interrogation par cliché, version ou horodatage n'est pas prise en charge.
  • Non_catalog uniquement : les nouveaux instantanés ne sont pas récupérés automatiquement. Pour lire un instantané spécifique, ciblez la table externe metadata.json et recréez.
AWS Glue
  • Alignement des informations d'identification : les mêmes informations d'identification doivent être utilisées pour AWS S3 et AWS Glue.
  • Co-location de région : les buckets S3 et le catalogue AWS Glue doivent se trouver dans la même région AWS.

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 AI 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 Concurrence 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.

Informations d'identification pour Iceberg : Catalogue REST et banque d'objets

Cette rubrique explique comment Apache Iceberg gère les données et y accède via les deux informations d'identification : le catalogue REST et la banque d'objets. Vous pouvez également vous référer à deux méthodes différentes de gestion des informations de table dans les formats de table de lac de données, comme Apache Iceberg.

Tables externes de métadonnées directes ou gérées par catalogue

La section suivante compare les tables externes gérées par le catalogue avec les tables externes de métadonnées directes mettant en évidence leurs principales différences.

  • Géré par catalogue (Unity / Polaris / AWS Glue)

    Présentation : métadonnées, schéma et cliché "en cours" résolus via un catalogue REST.

    Comportement : reflète automatiquement le dernier instantané du catalogue, les autorisations centralisées, les balises et le lignage.

    Meilleur pour : les produits de données d'entreprise, le partage inter-moteur, la gouvernance cohérente, la découvrabilité (le catalogue est le point de vérité unique).

    • Métadonnées directes (système de fichiers via metadata.json)

      Qu'est-ce que c'est ? La table externe pointe directement vers un élément metadata.json spécifique.

      Comportement : instantané corrigé et reproductible, pas d'avances automatiques, gouvernance limitée aux ACL de banque d'objets.

      Meilleur pour : expériences, tests, audits.

Informations d'identification de banque d'objets et REST

Informations d'identification de catalogue REST

Des informations d'identification REST sont requises lors de la connexion à un catalogue REST Apache Iceberg. Le catalogue REST gère les métadonnées des tables Iceberg en exposant les adresses RESTful. Pour l'authentification, les informations d'identification REST sont souvent basées sur OAuth. Vous devez donc obtenir un jeton de support à partir d'une adresse de jeton à l'aide de client ID et secret.

Lors de l'utilisation d'un catalogue REST Iceberg, deux informations d'identification sont requises :
  • rest_auth_cred : s'authentifie auprès du service de catalogue (par exemple, Unity ou Polaris).

  • credential_name : s'authentifie auprès de la banque d'objets où résident les métadonnées et les données Iceberg.
Remarque

Les informations d'identification en attente ne sont pas prises en charge pour le moment. Les informations d'identification de distribution font référence au processus contrôlé de distribution ou d'extraction des informations d'identification d'accès (comme les noms d'utilisateur et les mots de passe, les clés d'API ou les jetons) lorsqu'elles sont nécessaires, souvent automatiquement ou à la demande, plutôt que de les stocker statiquement dans des fichiers de configuration ou des scripts.

Informations d'identification de banque d'objets

Les informations d'identification de banque d'objets sont utilisées lorsque les tables Apache Iceberg sont stockées directement sur le stockage d'objets cloud, comme Oracle Cloud Infrastructure (OCI) Object Storage ou Amazon S3.

Les informations d'identification permettent à la base de données Autonomous AI d'accéder aux fichiers (tels que les manifestes de données et de métadonnées Parquet) et de les lire directement à partir de la banque d'objets cloud.

Remarque

Utilisez les informations d'identification de banque d'objets lors de la définition de tables externes qui pointent directement vers les fichiers de parquet/métadonnées dans les buckets OCI/S3.

Workflow standard d'interrogation des tables d'iceberg Apache

Avant de commencer à interroger les tables d'iceberg Apache, vous devez connaître son flux de travail. Cette section explique comment configurer des tables externes pour accéder aux données présentées sous la forme d'un workflow de configuration de bout en bout, en cinq étapes principales.

  1. Décidez votre modèle d'accès :
    • Géré par le catalogue : utilisez ce modèle lorsque vous voulez qu'un catalogue régi et mis à jour en permanence serve de source unique d'informations fiables pour les métadonnées de données. Ce catalogue central permet de maintenir la cohérence et la gouvernance de vos données.
    • Métadonnées directes : utilisez ce modèle lorsque vous utilisez un cliché fixe des métadonnées (via metadata.json). Ce modèle est plus simple mais statique, non recommandé pour la production car il ne dispose pas de mises à jour et de gouvernance automatiques.
  2. Rassemblez ce dont vous avez besoin :
    • Géré par le catalogue : vous devez avoir accès à l'adresse de catalogue (le cas échéant), au chemin exact de la table et à l'emplacement de la banque d'objets où résident les fichiers de données réels.
    • Métadonnées directes : vous avez uniquement besoin de l'URI pointant vers le fichier metadata.json racine plus l'emplacement de banque d'objets de ces fichiers de données.
  3. Préparer les informations d'identification :
    • Pour les configurations gérées par le catalogue, achetez des informations d'identification pour accéder au catalogue.
    • Les informations d'identification de banque d'objets sont toujours nécessaires, quel que soit le modèle, pour lire les fichiers de données et de métadonnées.
      Remarque

      La distribution automatique des informations d'identification et AWS AssumeRole pour l'accès au catalogue ne sont pas pris en charge.
  4. Créer la table externe :
    • Dans Géré par le catalogue, la table interroge les données via le catalogue et accède aux fichiers de la banque d'objets.
    • Dans Métadonnées directes, la table pointe directement vers le fichier metadata.json spécifique sans intervention du catalogue.
  5. Vérification rapide et attentes :

    Exécutez une requête simple telle que COUNT(*) pour vérifier la configuration de votre table et vous assurer qu'elle peut accéder aux données correctement.

Démarrages rapides du fournisseur

Ce chapitre décrit le processus de configuration de l'accès aux données externes avec différents fournisseurs de données cloud.

Rubriques :

Catalogue Databricks Unity

Cette section explique le workflow qui lie les bases de données aux formats de table ouverts via UniForm, ce qui facilite l'accès aux données de Delta Lake dans les environnements prenant en charge Iceberg.

Catalogue Databricks Unity (chemin UniForm)

Prérequis :
  • Table Delta créée avec UniForm afin que les clients Iceberg puissent la lire.
  • Fichiers de table dans Azure ADLS Gen2 ou AWS S3.
  • Privilèges Unity Catalog pour l'accès externe (par exemple, accès aux données externes activé) ; accordez EXTERNAL USE SCHEMA à votre principal.
  • Authentification : OAuth2 (recommandé) ou jeton d'accès personnel (pour les tests rapides).
Remarque

L'Iceberg natif via REST Iceberg n'est pas encore pris en charge par notre intégration. Utilisez Delta avec UniForm (lisible à l'iceberg) et exposez-le via REST Unity Iceberg : https ://<workspace-host>/api/2.1/unity-catalog/iceberg.

Créez une table UniForm (lisible par Iceberg) dans Databricks :

La procédure suivante crée une table UniForm (lisible par les icebergs) nommée customers_iceberg dans Databricks dans le catalogue et le schéma Unity Catalog indiqués :
USE CATALOG <your_catalog>;
USE SCHEMA  <your_schema>;

CREATE TABLE customers_iceberg (
  id   INT,
  name STRING
)
TBLPROPERTIES(
  'delta.columnMapping.mode'='name',
  'delta.enableIcebergCompatV2'='true',
  'delta.universalFormat.enabledFormats'='iceberg'
);

INSERT INTO customers_iceberg (id, name) VALUES
  (1,'Alice'), (2,'Bob'), (3,'Carol');

Informations d'identification de banque d'objets (ADLS Gen2)

La procédure suivante configure des informations d'identification pour l'accès à la banque d'objets (Azure Data Lake Storage Gen2) à l'aide de clés de compte de stockage ou de jetons SAS pour un accès au stockage cloud externe sécurisé.
BEGIN
  BEGIN DBMS_CLOUD.DROP_CREDENTIAL('AZURE_BLOB_CRED'); EXCEPTION WHEN OTHERS THEN NULL; END;
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'AZURE_BLOB_CRED',
    username        => '<storage-account-or-sas-username>',
    password        => '<storage-key-or-sas-token>'
  );
END;
/

Créer des informations d'identification de catalogue REST avec OAuth2

La procédure suivante configure les informations d'identification OAuth2 pour une authentification sécurisée à l'aide d'un principal de service Databricks (ID client et clé secrète) :
-- Databricks service principal (client_id / client_secret)
BEGIN
  BEGIN DBMS_CLOUD.DROP_CREDENTIAL('UNITY_OAUTH'); EXCEPTION WHEN OTHERS THEN NULL; END;
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'UNITY_OAUTH',
    username        => '<client_id>',
    password        => '<client_secret>'
  );
END;
/

BEGIN
  DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
    table_name      => 'CUSTOMERS_ICEBERG',
    credential_name => 'AZURE_BLOB_CRED',
    format          => '{
      "access_protocol": {
        "protocol_type": "iceberg-rest",
        "protocol_config": {
          "iceberg_catalog_type": "unity",
          "rest_catalog_endpoint": "https://<workspace-host>/api/2.1/unity-catalog/iceberg",
          "rest_authentication": {
            "rest_auth_cred": "UNITY_OAUTH",
            "rest_auth_endpoint": "https://<workspace-host>/oidc/v1/token"
          },
          "table_path": ["<your_catalog>","<your_schema>","customers_iceberg"]
        }
      }
    }'
  );
END;
/
SELECT COUNT(*) FROM CUSTOMERS_ICEBERG;

Créer des informations d'identification de catalogue REST avec un jeton d'accès personnel

Cette procédure indique comment utiliser un test d'acceptation patient pour des tests rapides en créant des informations d'identification PAT et en créant la table externe qui les utilise.
BEGIN
  BEGIN DBMS_CLOUD.DROP_CREDENTIAL('UNITY_PAT'); EXCEPTION WHEN OTHERS THEN NULL; END;
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'UNITY_PAT',
    username        => 'token',
    password        => '<dapiXXXXXXXXXXXXXXXXXXXXXXXX>'
  );
END;
/

BEGIN
  DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
    table_name      => 'CUSTOMERS_ICEBERG',
    credential_name => 'AZURE_BLOB_CRED',
    format          => '{
      "access_protocol": {
        "protocol_type": "iceberg-rest",
        "protocol_config": {
          "iceberg_catalog_type": "unity",
          "rest_catalog_endpoint": "https://<workspace-host>/api/2.1/unity-catalog/iceberg",
          "rest_authentication": { "rest_auth_cred": "UNITY_PAT" },
          "table_path": ["<your_catalog>","<your_schema>","customers_iceberg"]
        }
      }
    }'
  );
END;
/
SELECT COUNT(*) FROM CUSTOMERS_ICEBERG;

Flocon de neige Polaris

Cette rubrique décrit Snowflake Polaris (catalogue REST) permettant un accès sécurisé aux tables Apache Polaris Iceberg via une API REST à l'aide de l'authentification OAuth2.

Snowflake Polaris (catalogue REST)

Prérequis :
  • Catalogue Polaris Iceberg et adresse disponibles pour votre compte.
  • Fichiers de table accessibles dans votre banque d'objets (S3/ADLS, le cas échéant).
  • Authentification : OAuth2 recommandé (informations d'identification client) ou un autre mécanisme de jeton pris en charge par Polaris.

Créez des informations d'identification OAuth2 :

La procédure suivante crée des informations d'identification OAuth2 portant le nom POLARIS_OAUTH pour authentifier l'accès à un catalogue Iceberg Apache Polaris.

BEGIN
  BEGIN DBMS_CLOUD.DROP_CREDENTIAL('POLARIS_OAUTH'); EXCEPTION WHEN OTHERS THEN NULL; END;
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'POLARIS_OAUTH',
    username        => '<client_id>',
    password        => '<client_secret>'
  );
END;
/

Créer des informations d'identification de stockage

La procédure suivante crée des informations d'identification de stockage nommées S3_CRED pour accéder au stockage d'objets (par exemple, Amazon S3) avec un ID de clé d'accès AWS et une clé d'accès secrète.

-- Storage credential for your object store (example: S3)
BEGIN
  BEGIN DBMS_CLOUD.DROP_CREDENTIAL('S3_CRED'); EXCEPTION WHEN OTHERS THEN NULL; END;
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'S3_CRED',
    username        => '<aws_access_key_id>',
    password        => '<aws_secret_access_key>'
  );
END;
/

Créer une table externe

La procédure suivante définit une table externe nommée SALES_POLARIS dans Databricks qui accède aux données stockées au format Iceberg géré par le catalogue Polaris.
BEGIN
  DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
    table_name      => 'SALES_POLARIS',
    credential_name => 'S3_CRED',
    format          => '{
      "access_protocol": {
        "protocol_type": "iceberg-rest",
        "protocol_config": {
          "iceberg_catalog_type": "polaris",
          "rest_catalog_endpoint": "<https://<your-polaris-endpoint>/...>",
          "rest_authentication": {
            "rest_auth_cred": "POLARIS_OAUTH",
            "rest_auth_endpoint": "<https://<your-oauth-token-endpoint>>"
          },
          "table_path": ["<db>","<schema>","<table>"]
        }
      }
    }'
  );
END;
/

Vérification rapide des fonctionnalités

La procédure suivante exécute une requête pour vérifier que la table externe est correctement configurée et accessible.
SELECT COUNT(*) FROM SALES_POLARIS;
Remarque

Conservez les marques de réservation d'adresse et d'URL de jeton car elles varient selon la configuration Polaris.

Catalogue AWS Glue

Cette rubrique explique comment accéder aux données Amazon S3 via Glue Data Catalog avec des tables Iceberg enregistrées à l'aide des informations d'identification AWS.

Prérequis :
  • Colle Data Catalog avec la table Iceberg enregistrée (objets S3 accessibles).

    Nom de la région pour Colle (par exemple, us-east-1).

  • Authentification : clé d'accès/secret pour S3 ; accès Glue via la configuration du catalogue.

  • Le transfert d'informations d'identification via AWS ARN n'est pas pris en charge. Des informations d'identification explicites doivent être fournies.

Créer des informations d'identification de stockage

La procédure suivante crée des informations d'identification de stockage nommées S3_CRED dans Databricks pour permettre l'accès aux données stockées dans un bucket Amazon S3.

-- S3 credential
BEGIN
  BEGIN DBMS_CLOUD.DROP_CREDENTIAL('S3_CRED'); EXCEPTION WHEN OTHERS THEN NULL; END;
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'S3_CRED',
    username        => '<aws_access_key_id>',
    password        => '<aws_secret_access_key>'
  );
END;
/

Créer une table Iceberg externe

Crée une table Iceberg externe nommée ORDERS_GLUE dans Databricks.
BEGIN
  DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
    table_name      => 'ORDERS_GLUE',
    credential_name => 'S3_CRED',
    format          => '{
      "access_protocol": {
        "protocol_type": "iceberg",
        "protocol_config": {
          "iceberg_catalog_type": "aws_glue",
          "iceberg_glue_region": "us-east-1",
          "table_path": ["<database>","<table>"]
        }
      }
    }'
  );
END;
/

Vérification rapide des fonctionnalités

La procédure suivante exécute une requête pour compter toutes les lignes de la table externe ORDERS_GLUE afin de vérifier la connexion et l'accessibilité des données.
SELECT COUNT(*) FROM ORDERS_GLUE;

Hadoop/Système de fichiers (fichier de métadonnées directes)

Cette rubrique explique comment créer des informations d'identification de stockage pour accéder directement au fichier de métadonnées d'une table Iceberg à partir de banques d'objets telles qu'ADLS, S3 ou OCI. Il explique comment catégoriser les types de gestion directe des métadonnées pour les tables Iceberg stockées directement dans le système de fichiers (généralement des systèmes de fichiers compatibles Hadoop) sans utiliser de service de catalogue.

Exemple : interroger une table Iceberg à l'aide de métadonnées JSON

Prérequis :
  • Vous pouvez accéder au manifeste root de l'iceberg de la table (metadata.json) dans la banque d'objets (ADLS/S3/OCI).
  • Ce chemin est point dans le temps. Pour suivre les nouveaux clichés, recréez la table externe.

Création d'informations d'identification de stockage

Cette procédure tente d'abord de supprimer des informations d'identification existantes appelées STORE_CRED si elles existent (en ignorant les erreurs). Elle crée ensuite des informations d'identification nommées STORE_CRED.

-- Storage credential for wherever the metadata.json lives
BEGIN
  BEGIN DBMS_CLOUD.DROP_CREDENTIAL('STORE_CRED'); EXCEPTION WHEN OTHERS THEN NULL; END;
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'STORE_CRED',
    username        => '<user-or-key>',
    password        => '<secret-or-token>'
  );
END;
/

Créer une table externe

Elle crée une table externe nommée CUSTOMERS_META.
BEGIN
  DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
    table_name      => 'CUSTOMERS_META',
    credential_name => 'STORE_CRED',
    file_uri_list   => 'https://<bucket-or-container>/<path>/metadata.json',
    format          => '{"access_protocol":{"protocol_type":"iceberg"}}'
  );
END;
/

Vérification rapide des fonctionnalités

La procédure suivante exécute une requête pour compter toutes les lignes de la table externe.


SELECT COUNT(*) FROM CUSTOMERS_META;

Exemple : interrogation d'une table Iceberg à l'aide du catalogue Hadoop sur OCI

Dans cet exemple, nous interrogeons la table d'iceberg db.icebergTablePy, créée à l'aide d'OCI Data Flow, où Spark utilise l'implémentation HadoopCatalog pour le catalogue d'iceberg. HadoopCatalog utilise un dossier de lakehouse iceberg dans le bucket my-iceberg-bucket 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.

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',
    format           => '{
      "access_protocol": {
        "protocol_type": "iceberg",
        "protocol_config": {
          "iceberg_catalog_type": "hadoop",
          "iceberg_lakehouse": "https://objectstorage.uk-cardiff-1.oraclecloud.com/n/my-tenancy/b/my-iceberg-bucket/o/iceberg",
          "iceberg_table_path": "db.icebergTablePy"
        }
      }
    }'
  );
END;
/