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
La base de données d'IA autonome prend en charge l'interrogation des tables d'iceberg Apache. - Concepts liés à l'interrogation des tables d'iceberg Apache
Les concepts suivants sont utiles pour l'interrogation des tables d'iceberg Apache. - 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 : catalogue REST et 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. - Workflow standard d'interrogation des tables d'iceberg Apache
Avant de commencer à interroger les tables d'iceberg Apache, vous devez connaître son workflow. 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. - 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. - Références
Cette section fournit une liste de références pour les liens cités tout au long de ce chapitre :
Rubrique parent : Interrogation des données externes avec la base de données d'IA autonome
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 |
|
| 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 d'interrogation des tables d'iceberg Apache
Ce chapitre répertorie les restrictions d'interrogation des tables d'iceberg Apache.
Rubrique parent : Interrogation des tables d'iceberg Apache
Restrictions relatives à l'interrogation des tables d'iceberg Apache
Ce chapitre répertorie les restrictions d'interrogation des tables Apache Iceberg.
-
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.
-
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.
- 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.
- 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.
- 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.
- 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.
Rubrique parent : A propos de l'interrogation des tables d'iceberg Apache
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.
Rubrique parent : Interrogation des tables d'iceberg Apache
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.jsonspé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.
-
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.
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.
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.
Rubrique parent : Interrogation des tables d'iceberg Apache
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.
- 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.
- 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.jsonracine plus l'emplacement de banque d'objets de ces fichiers de données.
- 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.
- 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.jsonspécifique sans intervention du catalogue.
-
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.
Rubrique parent : Interrogation des tables d'iceberg Apache
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 Unity Databricks
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. - Snowflake Polaris
Cette rubrique décrit Snowflake Polaris (catalogue REST) qui permet un accès sécurisé aux tables Apache Polaris Iceberg via une API REST à l'aide de l'authentification OAuth2. - Catalogue de colle AWS
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. - Hadoop/Système de fichiers (fichier de métadonnées direct)
Cette rubrique explique comment créer des informations d'identification de stockage pour accéder au fichier de métadonnées d'une table Iceberg directement à 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.
Rubrique parent : Interrogation des tables d'iceberg Apache
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)
- 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).
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 :
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)
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
-- 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
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;
Rubrique parent : Démarrages rapides du fournisseur
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)
- 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
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
SELECT COUNT(*) FROM SALES_POLARIS;Conservez les marques de réservation d'adresse et d'URL de jeton car elles varient selon la configuration Polaris.
Rubrique parent : Démarrages rapides du fournisseur
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.
-
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
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
ORDERS_GLUE afin de vérifier la connexion et l'accessibilité des données.SELECT COUNT(*) FROM ORDERS_GLUE;Rubrique parent : Démarrages rapides du fournisseur
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
- 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
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.
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;
/Rubrique parent : Démarrages rapides du fournisseur
Références
Cette section fournit une liste de références pour les liens cités tout au long de ce chapitre :
Rubrique parent : Interrogation des tables d'iceberg Apache