Interroger les tables Iceberg d'Apache

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

À propos de l'interrogation des tables Apache Iceberg

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

Configurations prises en charge

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

Catalogue Magasin(s) d'objets Autorisation de catalogue (REST) Authentification de stockage Notes
Unity (groupe de données) Amazon S3, Azure ADLS Gen2 OAuth2 principal de service (/oidc/v1/token) - recommandé; PAT - tests rapides Accès S3/clé secrète; clé SAS ADLS Gen2
  • UniForm requis (Delta à Iceberg-readable). Native Iceberg via Iceberg REST n'est pas encore pris en charge par notre intégration; utilisez Delta+UniForm via …/api/2.1/unity-catalog/iceberg;

  • Le distributeur de données d'identification du magasin d'objets n'est pas pris en charge.
Polaris (flocons de neige) Amazon S3, Azure ADLS Gen2 OAuth2 (données d'identification du client) ou jeton pris en charge par Polaris Accès S3/clé secrète; clé SAS ADLS Gen2 Le distributeur de données d'identification du magasin d'objets n'est pas pris en charge.
Glace AWS Amazon S3 S.O. (utilise l'authentification de compte AWS) S3 accès/clé secrète; Le distributeur de données d'identification du magasin d'objets n'est pas pris en charge. Les mêmes données 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, magasin d'objets OCI S.O. (sans REST) Accès S3/clé secrète; clé SAS ADLS Gen2, données d'identification natives OCI Pointez la base de données autonome vers le fichier metadata.json de la table (manifeste racine). Instantané ponctuel; recréez la table externe après modification du schéma ou nouvel instantané.
Hadoop (hors catalogue) Service de stockage d'objets OCI S.O. (sans REST) Données d'identification natives OCI Fait pointer vers un dossier d'entrepôt avec lac de données qui contient des fichiers de données et de métadonnées.

Tables UniForm Delta Lake

Autonomous AI Database Serverless peut également interroger les tables Delta Lake pour lesquelles UniForm est activé (anciennement Delta Lake Universal Format). UniForm écrit les métadonnées Apache Iceberg pour la table Delta, afin que vous puissiez créer une table externe dans Autonomous Database contre ces métadonnées Iceberg (via un catalogue Iceberg ou le fichier de métadonnées racine Iceberg) et l'interroger comme n'importe quelle autre table Iceberg. Les mêmes limitations Iceberg sur cette page s'appliquent toujours. Voir la documentation sur Delta Lake pour activer UniForm.

Restrictions d'interrogation des tables Apache Iceberg

Ce chapitre répertorie les restrictions relatives à l'interrogation des tables Apache Iceberg.

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

    Solution de rechange : Utilisez Delta + UniForm pour publier une vue lisible par Iceberg au moyen du point d'extrémité REST Iceberg du catalogue Unity.

  • Catalogues REST certifiés : La base de données autonome est certifiée avec Snowflake Polaris et Databricks Unity Catalog (UniForm seulement) pour l'accès en lecture à Iceberg.
Authentification et données d'identification :
  • Envoi de données d'identification de catalogue : Non pris en charge.

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

  • Données d'identification ARN AWS : Non prises en charge. Les numéros ARN du rôle IAM et AssumeRole par ARN ne sont pas acceptés.
Sémantique de table et LMD
  • Les tables Iceberg partitionnées ne sont pas prises en charge; seules les tables non partitionnées sont autorisées.
  • Mises à jour au niveau de la rangée (fusion en lecture) : Non prises en charge. Si les métadonnées Iceberg font référence à des fichiers de suppression, les interrogations échoueront.
Évolution du schéma 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é avec 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
  • Aucun déplacement dans le temps d'interrogation : L'interrogation par instantané, version ou horodatage n'est pas prise en charge.
  • Non_catalog seulement : Les nouveaux instantanés ne sont pas sélectionnés automatiquement. Pour lire un instantané spécifique, ciblez les données metadata.json de cet instantané et recréez la table externe.
Glace AWS
  • Alignement des données d'identification : Les mêmes données d'identification doivent être utilisées pour AWS S3 et AWS Glue.
  • Co-emplacement de région : Les seaux S3 et le catalogue AWS Glue doivent se trouver dans la même région AWS.

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

Configuration requise pour Iceberg

Cette rubrique décrit les exigences de configuration pour l'utilisation d'Iceberg avec Oracle Autonomous AI Database.

Rubriques

Données d'identification pour Iceberg : Catalogue REST par rapport au magasin d'objets

Cette rubrique explique comment Apache Iceberg gère les données et y accède au moyen des deux données d'identification : Catalogue REST et magasin d'objets. Vous pouvez également vous référer à deux façons différentes de gérer les informations de table dans des formats de table de lac de données tels qu'Apache Iceberg.

Tables externes gérées par catalogue par rapport aux métadonnées directes

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

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

    Qu'est-ce que : Métadonnées, schéma et instantané "courant" résolus au moyen d'un catalogue REST.

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

    Meilleur pour : Produits de données d'entreprise, partage inter-ingénierie, gouvernance cohérente, détectabilité (le catalogue est le point unique de vérité).

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

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

      Comportement : Instantané fixe et reproductible, aucune avancée automatique, gouvernance limitée aux listes de contrôle d'accès du magasin d'objets.

      Meilleur pour : Expériences, tests, vérifications.

Données d'identification REST par rapport au magasin d'objets

Données d'identification de catalogue REST

Les données 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 points d'extrémité RESTful. Pour l'authentification, les données d'identification REST sont souvent basées sur OAuth, ce qui vous oblige à obtenir un jeton de porteur à partir d'un point d'extrémité de jeton à l'aide de client ID et secret.

Lors de l'utilisation d'un catalogue REST Iceberg, deux données d'identification sont requises :
  • rest_auth_cred : S'authentifie avec le service de catalogue (par exemple, Unity ou Polaris).

  • credential_name : S'authentifie auprès du magasin d'objets où résident les données et les métadonnées Iceberg.
Note

Les données d'identification de fournisseur ne sont pas prises en charge pour le moment. Les informations d'identification et de connexion font référence au processus contrôlé de distribution ou d'extraction des informations d'identification et de connexion (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 de manière statique dans des fichiers de configuration ou des scripts.

Données d'identification du magasin d'objets

Les données d'identification du magasin d'objets sont utilisées lorsque les tables Apache Iceberg sont stockées directement sur le stockage d'objets en nuage, comme le service de stockage d'objets pour Oracle Cloud Infrastructure (OCI) ou Amazon S3.

Les données d'identification permettent à la base de données autonome d'IA d'accéder aux fichiers (tels que les données Parquet et les manifestes de métadonnées) et de les lire directement à partir du magasin d'objets en nuage.

Note

Utilisez les données d'identification du magasin d'objets lors de la définition de tables externes qui pointent directement vers des fichiers Parquet/de métadonnées dans des seaux OCI/S3.

Préalable : Accorder des listes de contrôle d'accès au réseau (LCA) pour les opérations d'Iceberg

Cette rubrique explique comment accorder des privilèges de listes de contrôle d'accès au réseau au schéma de base de données qui exécute des énoncés Apache Iceberg.

Avant d'interroger les tables Apache Iceberg dans Oracle Database 23ai, vous devez configurer les privilèges d'accès réseau. Les opérations Iceberg communiquent avec des services externes par HTTPS, y compris des mandataires HTTP du système, des points d'extrémité de service de catalogue et des référentiels de stockage d'objets tels qu'Amazon S3 ou le stockage d'objets d'OCI.

Pour autoriser ces connexions, accordez des listes de contrôle d'accès réseau (ACL) au schéma de base de données qui exécute des interrogations Iceberg ou des énoncés LDD (Data Definition Language). Si les listes de contrôle d'accès requises ne sont pas accordées, les opérations échouent avec l'erreur, par exemple ORA-20000: Failed to generate column list, ORA-24247: network access denied by access control list (ACL).

Vous devez accorder ces listes de contrôle d'accès aux éléments suivants :
  • Le schéma qui crée et possède la table externe Iceberg doit avoir un accès HTTPS sortant aux noms d'hôte requis.
  • Les utilisateurs qui n'ont besoin d'exécuter que des énoncés SELECT sur une table externe Iceberg existante ne nécessitent pas ces listes de contrôle d'accès; ils n'ont besoin que de privilèges standard tels que DWROLE et SELECT sur la table.
Les meilleures pratiques pour définir les listes de contrôle d'accès incluent de les garder aussi restrictives que possible, de les limiter à HTTPS (port 443) et de ne permettre l'accès qu'aux hôtes spécifiques requis par Iceberg. Par exemple, si votre table Iceberg stocke des métadonnées et des fichiers de données dans OCI Object Storage, procédez comme suit :
BEGIN
   DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
      host           => 'objectstorage.<region>.oraclecloud.com',
      lower_port     => 443,
      upper_port     => 443,
      ace            => xs$ace_type(
                           privilege_list   => xs$name_list('http'),
                           principal_name   => '<schema>',
                           principal_type   => xs_acl.ptype_db
                        )
   );
END;
/

 Fournissez les valeurs appropriées pour le nom <schema> et <region> pour votre région OCI.

Cet exemple accorde une autorisation de schéma de base de données Oracle pour effectuer des demandes HTTPS sortantes vers un point d'extrémité du service de stockage d'objets pour OCI.

La procédure DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE ajoute une entrée de contrôle d'accès (ACE) qui permet au schéma spécifié d'utiliser le privilège http (qui inclut HTTPS) lors de la connexion au point d'extrémité régional du service de stockage d'objets pour OCI sur le port 443. Cet accès est requis pour la lecture des métadonnées de table Iceberg et l'extraction des fichiers de données stockés dans le service de stockage d'objets OCI.

Pour plus d'informations, voir DBMS_NETWORK_ACL_ADMIN.

Noms d'hôte par configuration

Utilisez le tableau suivant pour déterminer les noms d'hôte qui nécessitent généralement des entrées de liste de contrôle d'accès pour le schéma qui exécute DBMS_CLOUD.CREATE_EXTERNAL_TABLE :
Stockage Noms d'hôte

OCI Object Storage (aucun catalogue externe ou HadoopCatalog)

objectstorage.<region>.oraclecloud.com

AWS S3 (aucun catalogue externe)

<bucket>.s3.<region>.amazonaws.com

AWS Glue Catalog + S3

  • glue.<region>.amazonaws.com (catalog API)

  • <bucket>.s3.amazonaws.com (bucket region lookup)

  • <bucket>.s3.<region>.amazonaws.com (data and metadata files)

Databricks Unity Catalog + Azure (ADLS Gen2)

  • <workspace>.azuredatabricks.net (catalog and token endpoints)

  • <storage-account>.blob.core.windows.net (data and metadata files)

Catalogue Databricks Unity + S3

  • <workspace>.azuredatabricks.net

  • <bucket>.s3.amazonaws.com

  • <bucket>.s3.<region>.amazonaws.com

Snowflake Polaris + S3

  • <account>.snowflakecomputing.com

    (Polaris et points d'extrémité de jeton)
  • <bucket>.s3.amazonaws.com

  • <bucket>.s3.<region>.amazonaws.com

Snowflake Polaris + Azure (ADLS Gen2)

  • <account>.snowflakecomputing.com

  • <storage-account>.blob.core.windows.net

Si vous utilisez un mandataire HTTPS, vous devez également configurer des listes de contrôle d'accès pour l'hôte mandataire. Pour plus d'informations, voir Appeler des services Web à partir d'une base de données autonome d'IA.

Accorder des rôles de schéma pour les opérations Iceberg

La valeur DWROLE doit être accordée à tout schéma qui crée ou gère des tables externes Iceberg.

Dans Autonomous AI Database, DWROLE est le privilège standard défini pour l'exécution du chargement de données et des opérations connexes à l'aide de l'ensemble DBMS_CLOUD. L'affectation de ce rôle garantit que le schéma dispose des privilèges requis pour accéder au stockage en nuage et pour créer, interroger et gérer des tables externes Iceberg.

Flux de travail type pour l'interrogation des tables Apache Iceberg

Avant de commencer à interroger Apache Iceberg Tables, vous devez connaître son flux de travail. La présente section explique comment configurer des tables externes pour accéder aux données présentées comme un flux des travaux de configuration de bout en bout comportant cinq étapes principales.

  1. Décider le modèle d'accès :
    • Géré par catalogue : Utilisez ce modèle lorsque vous voulez qu'un catalogue continuellement mis à jour et géré serve de source unique de vérité pour les métadonnées de données. Ce catalogue central vous aide à assurer la cohérence et la gouvernance de vos données.
    • Métadonnées directes : Utilisez ce modèle lorsque vous utilisez un instantané fixe des métadonnées (au moyen de metadata.json). Ce modèle est plus simple mais statique, il n'est pas recommandé pour la production car il ne dispose pas de mises à jour et de gouvernance automatiques.
  2. Collecter ce dont vous avez besoin :
    • Géré par catalogue : Vous devez avoir accès au point d'extrémité du catalogue (le cas échéant), au chemin exact de la table et à l'emplacement du magasin d'objets où résident les fichiers de données réels.
    • Métadonnées directes : Vous n'avez besoin que de l'URI pointant vers le fichier metadata.json racine plus l'emplacement du magasin d'objets de ces fichiers de données.
  3. Préparer les données d'identification :
    • Pour les configurations Gérées par catalogue, obtenez des données d'identification pour accéder au catalogue.
    • Les données d'identification du magasin d'objets sont toujours nécessaires, quel que soit le modèle, pour lire à la fois les fichiers de données et les fichiers de métadonnées.
      Note

      La distribution automatique des données d'identification et AWS AssumeRole pour l'accès au catalogue ne sont pas prises en charge.
  4. Créer la table externe :
    • Dans Géré par catalogue, la table interroge les données au moyen du catalogue et accède aux fichiers du magasin d'objets.
    • Dans Direct-Metadata (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 interrogation 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

Le présent chapitre décrit le processus de configuration de l'accès aux données externes avec différents fournisseurs de données en nuage.

Rubriques :

Catalogue Unity Databricks

Cette section explique le flux de travail qui relie Databricks aux formats de table ouverts via UniForm, ce qui facilite l'accès aux données de Delta Lake dans les environnements qui prennent en charge Iceberg.

Catalogue Unity de Databricks (chemin UniForm)

Préalables :
  • Une table Delta créée avec UniForm pour 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, l'accès aux données externes est activé); accordez EXTERNAL USE SCHEMA à votre principal).

  • Auth : OAuth2 (recommandé) ou jeton d'accès personnel (pour les tests rapides).

  • Configurer les listes de contrôle d'accès réseau : Avant de créer une table externe qui utilise le catalogue Unity de Databricks avec des données stockées dans le stockage BLOB Azure, vous devez accorder l'autorisation de schéma Oracle pour établir des connexions HTTPS sortantes aux services Azure requis. Comme Oracle Database bloque l'accès au réseau par défaut, vous devez mettre à jour la liste de contrôle d'accès au réseau (ACL) pour permettre au schéma d'atteindre :
    • Espace de travail Databricks, qui héberge les API du catalogue Unity et les points d'extrémité de jeton/authentification.

    • Le compte Azure Storage, qui stocke les métadonnées et les fichiers de données de la table Iceberg.

    Exemple pour configurer des listes de contrôle d'accès réseau
    BEGIN
       -- Databricks workspace (Unity Catalog and token endpoint)
       DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
          host           => '<workspace>.azuredatabricks.net',
          lower_port     => 443,
          upper_port     => 443,
          ace            => xs$ace_type(
                               privilege_list => xs$name_list('http'),
                               principal_name => '<schema>',
                               principal_type => xs_acl.ptype_db
                            )
       );
    
       -- Azure Storage (metadata and data files)
       DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
          host           => '<storage-account>.blob.core.windows.net',
          lower_port     => 443,
          upper_port     => 443,
          ace            => xs$ace_type(
                               privilege_list => xs$name_list('http'),
                               principal_name => '<schema>',
                               principal_type => xs_acl.ptype_db
                            )
       );
    END;
    /

    Remplacez les paramètres fictifs suivants :

    • <workspace> : Nom de l'espace de travail Databricks utilisé dans votre URL Azure Databricks.
    • <storage-account> : Nom du compte de stockage Azure qui contient les métadonnées et les fichiers de données Iceberg.
    • <schema> : Schéma Oracle qui exécutera DBMS_CLOUD.CREATE_EXTERNAL_TABLE et nécessite un accès HTTPS.
Note

L'API REST Native Iceberg n'est pas prise en charge par notre intégration pour le moment. Utilisez Delta with UniForm (Iceberg-readable) et exposez-le au moyen de l'API 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 Iceberg) nommée customers_iceberg dans Databricks dans le catalogue et le schéma Unity Catalog spécifié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');

Données d'identification du magasin d'objets (ADLS Gen2)

La procédure suivante configure les données d'identification pour l'accès au magasin d'objets (Azure Data Lake Storage Gen2) à l'aide de clés de compte de stockage ou de jetons SAS pour l'accès sécurisé au stockage en nuage externe.
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 données d'identification de catalogue REST avec OAuth2

La procédure suivante configure les données d'identification OAuth2 pour une authentification sécurisée à l'aide d'un principal de service Databricks (ID client et clé secrète client) :
-- 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 données d'identification de catalogue REST avec un jeton d'accès personnel

Cette procédure indique comment utiliser un jeton d'accès personnel pour les tests rapides en créant des données d'identification PAT et en créant la table externe à l'aide de ces données.
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;

Snowflake Polaris

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

Snowflake Polaris (catalogue REST)

Préalables :
  • Catalogue et point d'extrémité Polaris Iceberg disponibles pour votre compte.

  • Fichiers de table accessibles dans votre magasin d'objets (S3/ADLS selon le cas).

  • Auth : OAuth2 recommandé (données d'identification du client) ou un autre mécanisme de jeton pris en charge par Polaris.

  • Avant de créer une table externe qui accède à un catalogue Iceberg stocké dans Snowflake et Amazon S3, le schéma de base de données doit être autorisé à établir des connexions HTTPS sortantes à ces services. Oracle Database restreint l'accès au réseau par défaut. Vous devez donc mettre à jour la liste de contrôle d'accès au réseau (ACL) pour permettre au schéma d'atteindre :
    • Points d'extrémité de votre compte Snowflake, utilisés pour l'accès au catalogue, l'authentification et l'échange de jetons

    • Point d'extrémité régional Amazon S3 où les métadonnées et les fichiers de données Iceberg sont stockés

    • (Facultatif) Point d'extrémité S3 non régional, requis par certaines API AWS et opérations de consultation de région

    Exemple pour configurer des listes de contrôle d'accès réseau
    BEGIN
    
       -- Allow HTTPS access to your Snowflake account (Polaris and token endpoints)
       DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
          host           => '<account>.snowflakecomputing.com',
          lower_port     => 443,
          upper_port     => 443,
          ace            => xs$ace_type(
                               privilege_list => xs$name_list('http'),
                               principal_name => '<schema>',
                               principal_type => xs_acl.ptype_db
                            )
       );
    
       -- Allow HTTPS access to the S3 bucket (regional endpoint for data/metadata)
       DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
          host           => '<bucket>.s3.<region>.amazonaws.com',
          lower_port     => 443,
          upper_port     => 443,
          ace            => xs$ace_type(
                               privilege_list => xs$name_list('http'),
                               principal_name => '<schema>',
                               principal_type => xs_acl.ptype_db
                            )
       );
    
       -- Optional: non-regional S3 endpoint (used for some APIs/region lookup)
       DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
          host           => '<bucket>.s3.amazonaws.com',
          lower_port     => 443,
          upper_port     => 443,
          ace            => xs$ace_type(
                               privilege_list => xs$name_list('http'),
                               principal_name => '<schema>',
                               principal_type => xs_acl.ptype_db
                            )
       );
    
    END;
    /

    Remplacez les paramètres fictifs suivants :

    • <account> : Identificateur de votre compte Snowflake.

    • <schema> : Schéma qui nécessite un accès HTTPS sortant.

    • <bucket> : Nom du seau Amazon S3 contenant les données et métadonnées Iceberg.

    • <region> : Région AWS dans laquelle le seau S3 est hébergé.

Créez des données d'identification OAuth2 :

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

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 données d'identification de stockage

La procédure suivante crée des données d'identification de stockage nommées S3_CRED pour accéder au stockage d'objets (par exemple, Amazon S3) avec un ID 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 à l'aide du 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 interrogation pour vérifier que la table externe est correctement configurée et accessible.
SELECT COUNT(*) FROM SALES_POLARIS;
Note

Conservez les paramètres fictifs de point d'extrémité et d'URL de jeton, car ils varient selon la configuration Polaris.

Catalogue de colle AWS

Cette rubrique décrit comment accéder aux données Amazon S3 au moyen du catalogue de données Glue avec des tables Iceberg enregistrées à l'aide des données d'identification AWS.

Préalables :
  • Collez le catalogue de données avec la table Iceberg enregistrée (S3 objets accessibles).

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

  • Auth : Clé/secret d'accès pour S3; accès de colle au moyen de la configuration de catalogue.

  • La transmission de données d'identification au moyen du numéro ARN AWS n'est pas prise en charge. Les données d'identification explicites doivent être fournies.

  • Avant de créer une table externe qui utilise AWS Glue comme catalogue Iceberg et Amazon S3 comme couche de stockage, le schéma Oracle doit avoir l'autorisation d'effectuer des demandes HTTPS sortantes vers ces services AWS. Oracle Database restreint l'accès au réseau par défaut. Vous devez donc mettre à jour la liste de contrôle d'accès au réseau (ACL) pour permettre au schéma d'atteindre :
    • AWS Glue, qui fournit l'API de catalogue Iceberg

    • Point d'extrémité régional S3, où les métadonnées et les fichiers de données Iceberg sont stockés

    • Point d'extrémité S3 non régional, requis pour certaines API AWS et opérations de consultation de région

    Exemple pour configurer des listes de contrôle d'accès réseau
    BEGIN
    
       -- AWS Glue (catalog API)
       DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
          host           => 'glue.<region>.amazonaws.com',
          lower_port     => 443,
          upper_port     => 443,
          ace            => xs$ace_type(
                               privilege_list => xs$name_list('http'),
                               principal_name => '<schema>',
                               principal_type => xs_acl.ptype_db
                            )
       );
    
       -- S3 bucket (regional endpoint for data and metadata files)
       DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
          host           => '<bucket>.s3.<region>.amazonaws.com',
          lower_port     => 443,
          upper_port     => 443,
          ace            => xs$ace_type(
                               privilege_list => xs$name_list('http'),
                               principal_name => '<schema>',
                               principal_type => xs_acl.ptype_db
                            )
       );
    
       -- Optional: non-regional S3 endpoint (used for some APIs or region lookup)
       DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
          host           => '<bucket>.s3.amazonaws.com',
          lower_port     => 443,
          upper_port     => 443,
          ace            => xs$ace_type(
                               privilege_list => xs$name_list('http'),
                               principal_name => '<schema>',
                               principal_type => xs_acl.ptype_db
                            )
       );
    
    END;
    /

    Remplacez les paramètres fictifs suivants :

    • <region> : Région AWS où se trouvent Glue et le seau S3.

    • <bucket> : Nom du seau S3 qui stocke les fichiers de données et de métadonnées Iceberg.

    • <schema> : Schéma Oracle qui exécute DBMS_CLOUD.CREATE_EXTERNAL_TABLE et nécessite un accès HTTPS.

Créer des données d'identification de stockage

La procédure suivante crée des données d'identification de stockage nommées S3_CRED dans Databricks pour permettre l'accès aux données stockées dans un seau 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 interrogation pour compter toutes les rangées de la table externe ORDERS_GLUE en vérifiant la connexion et l'accessibilité des données.
SELECT COUNT(*) FROM ORDERS_GLUE;

Hadoop/Filesystem (fichier de métadonnées direct)

Cette rubrique explique comment créer des données d'identification de stockage pour accéder au fichier de métadonnées d'une table Iceberg directement à partir de magasins d'objets tels que ADLS, S3 ou OCI. Il explique la catégorisation des 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 avec Hadoop) sans utiliser de service de catalogue.

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

Préalables :
  • Vous pouvez accéder au manifeste racine (metadata.json) Iceberg de la table dans votre magasin d'objets (ADLS/S3/OCI).
  • Ce chemin est un point dans le temps. Pour suivre les nouveaux instantanés, recréez la table externe.

Créer des données d'identification de stockage

Cette procédure tente d'abord de supprimer des données d'identification existantes appelées STORE_CRED si elles existent (en ignorant les erreurs). Il crée ensuite des données 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

Il 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 interrogation pour compter toutes les lignes de la table externe.


SELECT COUNT(*) FROM CUSTOMERS_META;

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

Dans cet exemple, nous interrogeons la table Iceberg db.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 dossier d'entrepôt avec lac de données iceberg dans le seau 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;
/

Références

La présente section fournit une liste de références pour les liens cités dans le présent chapitre :