Esegui query su tabelle iceberg Apache

Autonomous AI Database supporta l'esecuzione di query sulle tabelle Apache Iceberg.

Informazioni sull'esecuzione di query sulle tabelle Iceberg Apache

Autonomous AI Database supporta l'esecuzione di query sulle tabelle di Apache Iceberg.

Configurazioni supportate

Ecco la matrice di compatibilità della configurazione supportata:

Catalog Aree di memorizzazione oggetti Autorizzazione catalogo (REST) Autenticazione storage Note
Unità (Databricks) Amazon S3, Azure AGGIUNGE Gen2 OAuth2 service principal (/oidc/v1/token) - consigliato; PAT - test rapidi chiave di accesso/segreta S3; chiave SAS Gen2 ADLS
  • UniForm richiesto (Delta a Iceberg leggibile). Iceberg nativo via Iceberg REST non ancora supportato dalla nostra integrazione; utilizzare Delta+UniForm via …/api/2.1/unity-catalog/iceberg;

  • Il vendor delle credenziali dell'area di memorizzazione degli oggetti non è supportato.
Polaris (Snowflake) Amazon S3, Azure AGGIUNGE Gen2 OAuth2 (credenziali client) o token supportato da Polaris chiave di accesso/segreta S3; chiave SAS Gen2 ADLS Il vendor delle credenziali dell'area di memorizzazione degli oggetti non è supportato.
AWS Glue Amazon S3 N/D (utilizza l'autenticazione dell'account AWS) chiave di accesso/segreto S3; Il vendor delle credenziali dell'area di memorizzazione degli oggetti non è supportato. Le stesse credenziali devono essere utilizzate per S3 e Glue. S3 e Glue devono trovarsi nella stessa regione AWS.
Metadati JSON (opzione non in catalogo) Amazon S3, Azure ADLS Gen2, OCI Object Store N/D (nessun REST) Chiave di accesso/segreto S3; chiave SAS ADLS Gen2, credenziali native OCI Puntare ADB al file manifesto di root metadata.json della tabella. Snapshot point-in-time; ricreare una tabella esterna dopo modifica dello schema o nuovo snapshot.
Hadoop (non catalogo) Storage degli oggetti OCI N/D (nessun REST) Credenziali OCI native Punta a una cartella lakehouse che contiene dati e file di metadati.

Limitazioni dell'esecuzione delle query sulle tabelle dell'iceberg Apache

Questo capitolo elenca le limitazioni per l'esecuzione di query sulle tabelle Apache Iceberg.

Cataloghi e interoperabilità
  • Iceberg nativo Unity (REST): non supportato.

    Soluzione: utilizzare Delta + UniForm per pubblicare una vista leggibile da Iceberg tramite l'endpoint REST Iceberg di Unity Catalog.

  • Cataloghi REST certificati: ADB è certificato con Snowflake Polaris e Databricks Unity Catalog (solo UniForm) per l'accesso in lettura a Iceberg.
Autenticazione e credenziali:
  • Distribuzione delle credenziali del catalogo: non supportata.

    Il vendor basato sui ruoli cloud nativo, ad esempio l'assunzione automatica dei ruoli o le credenziali temporanee emesse da STS, non è supportato. Utilizzare chiavi di accesso/segrete esplicite o token statici.)

  • Credenziali ARN AWS: non supportate. Il ruolo IAM ARN e AssumeRole tramite ARN non sono accettati.
Semantica tabella e DML
  • Le tabelle Iceberg partizionate non sono supportate. Sono consentite solo le tabelle non partizionate.
  • Aggiornamenti a livello di riga (merge-on-read): non supportati. Se i metadati Iceberg fanno riferimento a file di eliminazione, le query non riusciranno.
Evoluzione schema e metadati
  • Lo schema di una tabella esterna fissa viene determinato alla creazione e deve essere allineato alla versione dello schema Iceberg nei metadati. Se lo schema Iceberg viene aggiornato, è necessario ricreare la tabella esterna.
Istantanee e viaggi nel tempo
  • Nessun viaggio temporale query: l'esecuzione di query per snapshot, versione o indicatore orario non è supportata.
  • Non_catalog solo: i nuovi snapshot non vengono raccolti automaticamente. Per leggere uno snapshot specifico, la destinazione di tale snapshot è metadata.json e ricreare la tabella esterna.
AWS Glue
  • Allineamento delle credenziali: le stesse credenziali devono essere utilizzate per AWS S3 e AWS Glue.
  • Co-location dell'area: i bucket S3 e il catalogo AWS Glue devono trovarsi nella stessa area AWS.

Concetti relativi all'esecuzione di query sulle tabelle dell'iceberg Apache

Una comprensione dei seguenti concetti è utile per interrogare le tabelle di Apache Iceberg.

Catalogo Iceberg

Il catalogo Iceberg è un servizio che gestisce i metadati delle tabelle, ad esempio gli snapshot delle tabelle, lo schema delle tabelle e le informazioni di partizionamento. Per eseguire una query sullo snapshot più recente di una tabella Iceberg, i motori di query devono prima accedere al catalogo e ottenere la posizione del file di metadati più recente. Esistono già diverse implementazioni di cataloghi disponibili, tra cui AWS Glue, Hive, Nessie e Hadoop. Autonomous AI Database supporta il catalogo AWS Glue e l'implementazione HadoopCatalog utilizzata da Spark.

Per ulteriori informazioni, vedere Concorrenza ottimistica.

File di metadati

Il file di metadati è un documento JSON che tiene traccia degli snapshot della tabella, dello schema di partizionamento e delle informazioni sullo schema. Il file di metadati è il punto di ingresso di una gerarchia di elenchi di manifesti e file manifesto. I file manifesto tengono traccia dei file di dati della tabella insieme a informazioni quali il partizionamento e le statistiche delle colonne. Per ulteriori informazioni, vedere Specifica della tabella Iceberg.

Transazioni

Iceberg supporta gli aggiornamenti a livello di riga alle tabelle utilizzando copia su scrittura o unione su lettura. Copy-on-write genera nuovi file di dati che riflettono le righe aggiornate, mentre merge-on-read genera nuovi "delete files" che devono essere uniti ai file di dati durante la lettura. Oracle supporta la funzione di copia su scrittura. Le query sulle tabelle iceberg non riescono se incontrano un file di eliminazione. Per ulteriori informazioni, vedere RowLevelOperationMode.

Evoluzione degli schemi

Iceberg supporta l'evoluzione dello schema. Le modifiche allo schema si riflettono nei metadati Iceberg utilizzando un ID schema. Si noti che le tabelle esterne Oracle dispongono di uno schema fisso, determinato dalla versione dello schema più recente al momento della creazione della tabella. Le query Iceberg non riescono quando i metadati interrogati puntano a una versione dello schema diversa rispetto a quella utilizzata al momento della creazione della tabella. Per ulteriori informazioni, vedere Evoluzione dello schema.

Partizionamento

Iceberg supporta opzioni di partizionamento avanzate come il partizionamento nascosto e l'evoluzione della partizione che si basano sull'elaborazione/alterazione dei metadati della tabella senza costose modifiche al layout dei dati.

Credenziali per Iceberg: catalogo REST rispetto a area di memorizzazione oggetti

Questo argomento spiega in che modo Apache Iceberg gestisce e accede ai dati tramite le due credenziali: Catalogo REST e Area di memorizzazione degli oggetti. È inoltre possibile fare riferimento a due modi diversi di gestione delle informazioni delle tabelle nei formati delle tabelle dei data lake, ad esempio Apache Iceberg.

Tabelle esterne Catalog-Managed vs Direct-Metadata

Nella sezione seguente vengono confrontate le tabelle esterne gestite a catalogo con le tabelle esterne a metadati diretti che evidenziano le differenze principali.

  • Catalog-Managed (Unity / Polaris / AWS Glue)

    Che cos'è: metadati, schema e snapshot "corrente" risolti tramite un catalogo REST.

    Funzionamento: riflette automaticamente lo snapshot più recente del catalogo; autorizzazioni, tag e derivazione centralizzati.

    Migliore per: prodotti di dati aziendali, condivisione cross-engine, governance coerente, individuabilità (il catalogo è il single point of truth).

    • Metadati diretti (file system tramite metadata.json)

      Che cos'è: la tabella esterna punta direttamente a un metadata.json specifico.

      Comportamento: snapshot fisso e riproducibile; nessun avanzamento automatico; governance limitata alle ACL dell'area di memorizzazione degli oggetti.

      Ideale per: Esperimenti, test, audit.

Credenziali area di memorizzazione oggetti e REST a confronto

Credenziali catalogo REST

Le credenziali REST sono necessarie quando si esegue la connessione a un catalogo REST Apache Iceberg. Il catalogo REST gestisce i metadati per le tabelle Iceberg esponendo gli endpoint RESTful. Per eseguire l'autenticazione, le credenziali REST sono spesso basate su OAuth e richiedono di ottenere un token bearer da un endpoint token utilizzando client ID e secret.

Quando si utilizza un catalogo Iceberg REST, sono necessarie due credenziali:
  • rest_auth_cred: autentica con il servizio catalogo (ad esempio, Unity o Polaris).

  • credential_name: esegue l'autenticazione nell'area di memorizzazione degli oggetti in cui risiedono i dati e i metadati dell'iceberg.
Nota

Le credenziali di vendita non sono attualmente supportate. Le credenziali di invio si riferiscono al processo controllato di distribuzione o recupero delle credenziali di accesso (come nomi utente e password, chiavi API o token) quando sono necessarie, spesso automaticamente o su richiesta, piuttosto che memorizzarle in modo statico in file o script di configurazione.

Credenziali area di archiviazione oggetti

Le credenziali dell'area di memorizzazione degli oggetti vengono utilizzate quando le tabelle Apache Iceberg vengono memorizzate direttamente nello storage degli oggetti cloud, ad esempio Oracle Cloud Infrastructure (OCI) Object Storage o Amazon S3.

Le credenziali consentono ad Autonomous AI Database di accedere e leggere i file (ad esempio i file manifest di dati e metadati Parquet) direttamente dall'area di memorizzazione degli oggetti cloud.

Nota

Utilizzare le credenziali dell'area di memorizzazione degli oggetti durante la definizione di tabelle esterne che puntano direttamente ai file Parquet/metadati nei bucket OCI/S3.

Workflow tipico dell'esecuzione di query sulle tabelle dell'iceberg Apache

Prima di iniziare a eseguire query sulle tabelle Apache Iceberg, è necessario conoscere il flusso di lavoro. In questa sezione viene descritto come impostare tabelle esterne per accedere ai dati presentati come flusso di lavoro di impostazione end-to-end con cinque passi principali.

  1. Decidi il tuo modello di accesso:
    • Gestione catalogo: utilizzare questo modello quando si desidera che un catalogo gestito e aggiornato in modo continuo funga da singola origine affidabile per i metadati dei dati. Questo catalogo centrale consente di mantenere la coerenza e la governance sui dati.
    • Metadati diretti: utilizzare questo modello quando si utilizza uno snapshot fisso di metadati (tramite metadata.json). Questo modello è più semplice ma statico, non consigliato per la produzione poiché manca di aggiornamenti e governance automatici.
  2. Raccogliere i dati necessari:
    • Gestione catalogo: è necessario disporre dell'accesso all'endpoint del catalogo (se applicabile), al percorso della tabella esatto e alla posizione dell'area di memorizzazione degli oggetti in cui risiedono i file di dati effettivi.
    • Metadati diretti: è necessario solo che l'URI punti al file metadata.json radice più la posizione dell'area di memorizzazione degli oggetti di questi file di dati.
  3. Prepara credenziali:
    • Per le impostazioni di Gestione catalogo, acquisire le credenziali per accedere al catalogo.
    • Le credenziali dell'area di memorizzazione degli oggetti sono sempre necessarie, indipendentemente dal modello, per leggere sia i file di dati che i file di metadati.
      Nota

      La distribuzione automatica delle credenziali e AWS AssumeRole per l'accesso al catalogo non sono supportati.
  4. Creare la tabella esterna:
    • In Gestione catalogo, la tabella esegue una query sui dati tramite il catalogo e accede ai file nell'area di memorizzazione degli oggetti.
    • In Metadati diretti, la tabella punta direttamente al file metadata.json specifico senza il coinvolgimento del catalogo.
  5. Controllo rapido e aspettative:

    Eseguire una query semplice come COUNT(*) per verificare l'impostazione della tabella e assicurarsi che possa accedere ai dati in modo corretto.

Quickstart provider

In questo capitolo viene descritto il processo di impostazione dell'accesso ai dati esterni con provider di dati cloud diversi.

Argomenti:

Databricks Unity Catalog

Questa sezione spiega il flusso di lavoro che collega Databricks ai formati di tabella aperta tramite UniForm, semplificando l'accesso ai dati di Delta Lake in ambienti che supportano Iceberg.

Databricks Unity Catalog (percorso UniForm)

Prerequisiti:
  • Tabella Delta creata con UniForm in modo che i client Iceberg possano leggerla.
  • File di tabella in Azure ADLS Gen2 o AWS S3.
  • Privilegi Unity Catalog per l'accesso esterno (ad esempio, accesso ai dati esterni abilitato); concedere EXTERNAL USE SCHEMA al principal.
  • Autorizzazione: OAuth2 (consigliato) o Token di accesso personale (per test rapidi).
Nota

L'iceberg nativo tramite REST Iceberg non è ancora supportato dalla nostra integrazione. Utilizzare Delta con UniForm (leggibile da Iceberg) ed esporlo tramite REST Unity Iceberg: https://<workspace-host>/api/2.1/unity-catalog/iceberg.

Creare una tabella UniForm (leggibile da Iceberg) in Databricks:

La procedura riportata di seguito crea una tabella UniForm (leggibile da Iceberg) denominata customers_iceberg in Databricks all'interno del catalogo e dello schema Unity Catalog specificati.
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');

Credenziale dell'area di memorizzazione degli oggetti (ADLS Gen2)

La procedura riportata di seguito imposta le credenziali per l'accesso all'area di memorizzazione degli oggetti (Azure Data Lake Storage Gen2) utilizzando le chiavi dell'account di storage o i token SAS per l'accesso sicuro allo storage cloud esterno.
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;
/

Crea credenziali catalogo REST con OAuth2

La procedura seguente imposta le credenziali OAuth2 per l'autenticazione sicura utilizzando un principal del servizio Databricks (ID client e segreto):
-- 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;

Crea credenziali catalogo REST con token di accesso personale (PAT)

Questa procedura mostra come utilizzare un PAT per i test rapidi creando una credenziale PAT e creando la tabella esterna che lo utilizza.
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;

Fiocco di neve Polaris

Questo argomento descrive Snowflake Polaris (catalogo REST) che consente l'accesso sicuro alle tabelle Iceberg di Apache Polaris tramite un'API REST tramite l'autenticazione OAuth2.

Snowflake Polaris (catalogo REST)

Prerequisiti:
  • Catalogo e endpoint Polaris Iceberg disponibili per il tuo account.
  • File di tabella accessibili nell'area di memorizzazione degli oggetti (S3/ADLS, a seconda dei casi).
  • Auth: OAuth2 consigliato (credenziali client) o un altro meccanismo di token supportato da Polaris.

Creare una credenziale OAuth2:

La procedura seguente crea una credenziale OAuth2 con il nome POLARIS_OAUTH per l'autenticazione dell'accesso a un catalogo 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;
/

Crea credenziale di storage

La procedura riportata di seguito crea una credenziale di storage denominata S3_CRED per accedere allo storage degli oggetti (ad esempio, Amazon S3) con un ID chiave di accesso AWS e una chiave di accesso segreta.

-- 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;
/

Crea tabella esterna

La procedura seguente definisce una tabella esterna denominata SALES_POLARIS in Databricks che accede ai dati memorizzati utilizzando il formato Iceberg gestito dal catalogo 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;
/

Controllo rapido delle funzionalità

Nella procedura riportata di seguito viene eseguita una query per verificare che la tabella esterna sia impostata e accessibile in modo corretto.
SELECT COUNT(*) FROM SALES_POLARIS;
Nota

Mantieni i segnaposto dell'endpoint e dell'URL del token poiché variano in base alla configurazione Polaris.

Catalogo AWS Glue

Questo argomento descrive come accedere ai dati di Amazon S3 tramite Glue Data Catalog con tabelle Iceberg registrate utilizzando le credenziali AWS.

Prerequisiti:
  • Catalogo dati colla con la tabella Iceberg registrata (oggetti S3 accessibili).

    Nome dell'area per la colla (ad esempio, us-east-1).

  • Aut: chiave di accesso/segreto per S3; accesso colla tramite configurazione del catalogo.

  • Il vendor di credenziali tramite AWS ARN non è supportato. È necessario fornire credenziali esplicite.

Creare una credenziale di storage

La procedura riportata di seguito crea una credenziale di storage denominata S3_CRED in Databricks per consentire l'accesso ai dati memorizzati in 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;
/

Creare una tabella Iceberg esterna

Crea una tabella Iceberg esterna denominata ORDERS_GLUE in 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;
/

Controllo rapido delle funzionalità

La procedura seguente esegue una query per contare tutte le righe nella tabella esterna ORDERS_GLUE verificando la connessione e l'accessibilità dei dati.
SELECT COUNT(*) FROM ORDERS_GLUE;

Hadoop/Filesystem (file di metadati diretti)

Questo argomento spiega come creare una credenziale di storage per accedere al file di metadati di una tabella Iceberg direttamente dalle aree di memorizzazione degli oggetti come ADLS, S3 o OCI. Spiega la categorizzazione dei tipi di gestione diretta dei metadati per le tabelle Iceberg memorizzate direttamente nel file system (di solito file system compatibili con Hadoop) senza utilizzare un servizio catalogo.

Esempio: eseguire una query su una tabella Iceberg utilizzando metadati JSON

Prerequisiti:
  • È possibile accedere all'Iceberg root manifest (metadata.json) della tabella nell'area di memorizzazione degli oggetti (ADLS/S3/OCI).
  • Questo percorso è point-in-time. Per seguire nuovi snapshot, ricreare la tabella esterna.

Creare una credenziale di storage

Questa procedura tenta in primo luogo di eliminare una credenziale esistente denominata STORE_CRED se esiste (ignorando eventuali errori). Viene quindi creata una nuova credenziale denominata 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;
/

Creare una tabella esterna

Crea una tabella esterna denominata 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;
/

Controllo rapido delle funzionalità

Nella procedura riportata di seguito viene eseguita una query per contare tutte le righe nella tabella esterna.


SELECT COUNT(*) FROM CUSTOMERS_META;

Esempio: eseguire una query su una tabella Iceberg utilizzando il catalogo Hadoop su OCI

In questo esempio viene eseguita una query sulla tabella Iceberg db.icebergTablePy, creata utilizzando OCI Data Flow, in cui Spark utilizza l'implementazione HadoopCatalog per il catalogo Iceberg. HadoopCatalog utilizza una cartella lakehouse iceberg nel bucket my-iceberg-bucket e inserisce i metadati Iceberg in una sottocartella $database_name/$table_name in questa directory. Utilizza anche un file version-hint.text che contiene il numero di versione per la versione più recente del file di metadati.

Creare una tabella esterna per la tabella db.icebergTablePy come indicato di seguito.
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;
/

Risorse