Apache Iceberg-Tabellen abfragen

Die autonome KI-Datenbank unterstützt das Abfragen von Apache Iceberg-Tabellen.

Apache-Eisberg-Tabellen abfragen

Die autonome KI-Datenbank unterstützt das Abfragen von Apache Iceberg-Tabellen.

Unterstützte Konfigurationen

Hier ist die Kompatibilitätsmatrix der unterstützten Konfiguration:

Catalog Objektspeicher Katalogauthentifizierung (REST) Speicherauthentifizierung Hinweise
Unity (Databricks) Amazon S3, Azure ADLS Gen2 Principal des OAuth2-Service (/oidc/v1/token) - empfohlen; PAT - Schnelltests S3-Zugriffs-/Secret-Key; ADLS Gen2-SAS-Schlüssel
  • UniForm erforderlich (Delta zu Iceberg-lesbar). Native Iceberg über Iceberg REST noch nicht durch unsere Integration unterstützt; verwenden Sie Delta+UniForm über …/api/2.1/unity-catalog/iceberg;

  • Ausgehende Objektspeicherzugangsdaten werden nicht unterstützt.
Polaris (Schneeküste) Amazon S3, Azure ADLS Gen2 OAuth2 (Clientzugangsdaten) oder von Polaris unterstütztes Token S3-Zugriffs-/Secret-Key; ADLS Gen2-SAS-Schlüssel Ausgehende Objektspeicherzugangsdaten werden nicht unterstützt.
AWS Glue Amazon S3 N/V (verwendet AWS-Accountauthentifizierung) S3 Zugriffs-/Secret-Key; Ausgehende Objektspeicherzugangsdaten werden nicht unterstützt. Dieselben Zugangsdaten müssen für S3 und Glue verwendet werden. S3 und Glue müssen sich in derselben AWS-Region befinden.
JSON-Metadaten (Option "Nicht im Katalog") Amazon S3, Azure ADLS Gen2, OCI Object Store N/V (kein REST) S3-Zugriffs-/Secret-Key; ADLS Gen2-SAS-Schlüssel, native OCI-Zugangsdaten Verweisen Sie auf ADB auf metadata.json (Root-Manifest) der Tabelle. Point-in-Time Snapshot; externe Tabelle nach Schemaänderung oder neuem Snapshot neu erstellen.
Hadoop (nicht im Katalog enthalten) OCI Object Storage N/V (kein REST) OCI-native Zugangsdaten Verweist auf einen Lakehouse-Ordner mit Daten- und Metadatendateien.

Einschränkungen bei der Abfrage von Apache Iceberg-Tabellen

In diesem Kapitel werden Einschränkungen bei der Abfrage von Apache Iceberg-Tabellen aufgeführt.

Kataloge & Interoperabilität
  • Unity Native Iceberg (REST): Wird nicht unterstützt.

    Problemumgehung: Verwenden Sie Delta + UniForm, um eine Iceberg-lesbare Ansicht über den Iceberg-REST-Endpunkt von Unity Catalog zu veröffentlichen.

  • Zertifizierte REST-Kataloge: ADB ist mit Snowflake Polaris und Databricks Unity Catalog (nur UniForm) für Iceberg-Lesezugriff zertifiziert.
Authentifizierung und Zugangsdaten:
  • Katalogzugangsdaten-Vending: Nicht unterstützt.

    Cloud-natives rollenbasiertes Vending, wie automatische Rollenannahme oder temporäre von STS ausgestellte Zugangsdaten, wird nicht unterstützt. Verwenden Sie explizite Zugriffs-/Secret-Keys oder statische Token.)

  • AWS-ARN-Zugangsdaten: Nicht unterstützt. IAM-Rollen-ARNs und AssumeRole über ARN werden nicht akzeptiert.
Tabellensemantik und DML
  • Partitionierte Iceberg-Tabellen werden nicht unterstützt. Nur nicht partitionierte Tabellen sind zulässig.
  • Updates auf Zeilenebene (Merge-on-Read): Nicht unterstützt. Wenn Iceberg-Metadaten Dateien löschen, schlagen Abfragen fehl.
Schema- und Metadatenentwicklung
  • Das Schema einer festen externen Tabelle wird bei der Erstellung bestimmt und muss mit der Iceberg-Schemaversion in den Metadaten übereinstimmen. Wenn das Iceberg-Schema aktualisiert wird, muss die externe Tabelle neu erstellt werden.
Snapshots und Zeitreisen
  • Keine Abfragezeitreise: Die Abfrage nach Snapshot, Version oder Zeitstempel wird nicht unterstützt.
  • Nur Non_catalog: Neue Snapshots werden nicht automatisch ausgewählt. Um einen bestimmten Snapshot zu lesen, zielen Sie darauf ab, dass der Snapshot die externe Tabelle metadata.json und neu erstellen enthält.
AWS Glue
  • Zugangsdatenausrichtung: Für AWS S3 und AWS Glue müssen dieselben Zugangsdaten verwendet werden.
  • Region Co-Location: S3-Buckets und der AWS Glue-Katalog müssen sich in derselben AWS-Region befinden.

Konzepte zur Abfrage von Apache-Eisberg-Tabellen

Die folgenden Konzepte sind für die Abfrage von Apache Iceberg-Tabellen hilfreich.

Iceberg-Katalog

Der Iceberg-Katalog ist ein Service, der Tabellenmetadaten, wie Tabellen-Snapshots, das Tabellenschema und Partitionierungsinformationen verwaltet. Um den neuesten Snapshot für eine Iceberg-Tabelle abzufragen, müssen Abfrage-Engines zuerst auf den Katalog zugreifen und den Speicherort der neuesten Metadatendatei abrufen. Es gibt bereits eine Reihe verfügbarer Katalogimplementierungen, darunter AWS Glue, Hive, Nessie und Hadoop. Autonomous AI Database unterstützt den AWS Glue-Katalog und die HadoopCatalog-Implementierung, die von Spark verwendet wird.

Weitere Informationen finden Sie unter Optimistische Nebenläufigkeit.

Metatendateien

Die Metadatendatei ist ein JSON-Dokument, das die Tabellen-Snapshots, das Partitionierungsschema und die Schemainformationen verfolgt. Die Metadatendatei ist der Einstiegspunkt in eine Hierarchie aus Manifestlisten und Manifestdateien. Die Manifeste verfolgen die Datendateien der Tabelle zusammen mit Informationen wie Partitionierung und Spaltenstatistiken. Weitere Informationen finden Sie unter Iceberg Table Specification.

Transaktionen

Iceberg unterstützt Tabellenaktualisierungen auf Zeilenebene mit Copy-on-Write oder Merge-on-Read. Beim Copy-on-Write werden neue Datendateien generiert, die den aktualisierten Zeilen entsprechen. Beim Merge-on-Read werden neue "Löschdateien" generiert, die beim Lesen mit den Datendateien zusammengeführt werden müssen. Oracle unterstützt Copy-on-Write-Vorgänge. Abfragen an Eisberg-Tabellen sind nicht erfolgreich, wenn sie auf eine Löschdatei stoßen. Weitere Informationen finden Sie unter RowLevelOperationMode.

Schemaentwicklung

Iceberg unterstützt die Schemaentwicklung. Schemaänderungen werden mit einer Schema-ID in den Iceberg-Metadaten widergespiegelt. Beachten Sie, dass externe Oracle-Tabellen ein festes Schema aufweisen, das von der aktuellsten Schemaversion beim Erstellen der Tabelle bestimmt wird. Iceberg-Abfragen schlagen fehl, wenn die abgefragten Metadaten auf eine andere Schemaversion als die beim Erstellen der Tabelle verwendete verweisen. Weitere Informationen finden Sie unter Schemaentwicklung.

Partitionierung

Iceberg unterstützt erweiterte Partitionierungsoptionen wie versteckte Partitionierung und Partitionsentwicklung, die auf der Verarbeitung/Änderung der Metadaten der Tabelle basieren, ohne dass kostspielige Änderungen am Datenlayout erforderlich sind.

Zugangsdaten für Iceberg: REST-Katalog vs. Objektspeicher

In diesem Thema wird erläutert, wie Apache Iceberg Daten mit den beiden Zugangsdaten verwaltet und darauf zugreift: REST-Katalog und Objektspeicher. Sie können sich auch auf zwei verschiedene Arten zur Verwaltung von Tabelleninformationen in Data Lake-Tabellenformaten wie Apache Iceberg beziehen.

Katalogverwaltete und direkte Metadaten - Externe Tabellen

Im folgenden Abschnitt werden katalogverwaltete externe Tabellen mit externen Direktmetadaten-Tabellen verglichen, die ihre Hauptunterschiede hervorheben.

  • Katalogverwaltet (Unity / Polaris / AWS Glue)

    Was es ist: Metadaten, Schema und "aktueller" Snapshot werden über einen REST-Katalog aufgelöst.

    Verhalten: Zeigt automatisch den neuesten Snapshot des Katalogs, zentralisierte Berechtigungen, Tags und Herkunft an.

    Am besten geeignet für: Unternehmensdatenprodukte, übergreifende gemeinsame Nutzung, konsistente Governance, Erkennbarkeit (der Katalog ist der einzelne Point of Truth).

    • Direct-Metadata (Dateisystem über metadata.json)

      Was es ist: Die externe Tabelle verweist direkt auf eine bestimmte metadata.json.

      Verhalten: Behobener, reproduzierbarer Snapshot; keine automatischen Vorschüsse; Governance beschränkt auf Objektspeicher-ACLs.

      Am besten geeignet für: Experimente, Tests, Audits.

REST-Zugangsdaten im Vergleich zu Objektspeicher

REST-Katalogzugangsdaten

REST-Zugangsdaten sind beim Herstellen einer Verbindung zu einem Apache Iceberg-REST-Katalog erforderlich. Der REST-Katalog verwaltet Metadaten für Iceberg-Tabellen, indem er RESTful-Endpunkte bereitstellt. Zur Authentifizierung sind REST-Zugangsdaten häufig OAuth-basiert, sodass Sie ein Bearer-Token mit einem client ID- und secret-Token aus einem Tokenendpunkt abrufen müssen.

Bei der Verwendung eines REST Iceberg-Katalogs sind zwei Zugangsdaten erforderlich:
  • rest_auth_cred: authentifiziert sich beim Katalogservice (z.B. Unity oder Polaris).

  • credential_name: authentifiziert sich beim Objektspeicher, in dem sich die Iceberg-Daten und -Metadaten befinden.
Hinweis

Ausstehende Zugangsdaten werden derzeit nicht unterstützt. Das Senden von Anmeldeinformationen bezieht sich auf den kontrollierten Prozess der Verteilung oder des Abrufs von Zugangsdaten (wie Benutzernamen und Kennwörter, API-Schlüssel oder Token), wenn sie benötigt werden, oft automatisch oder nach Bedarf, anstatt sie statisch in Konfigurationsdateien oder Skripten zu speichern.

Objektspeicherzugangsdaten

Objektspeicherzugangsdaten werden verwendet, wenn Apache Iceberg-Tabellen direkt im Cloud-Objektspeicher wie Oracle Cloud Infrastructure (OCI) Object Storage oder Amazon S3 gespeichert werden.

Mit den Zugangsdaten kann die autonome KI-Datenbank direkt aus dem Cloud-Objektspeicher auf Dateien zugreifen und diese lesen (wie Parquet-Daten und Metadatenmanifeste).

Hinweis

Verwenden Sie Objektspeicherzugangsdaten, wenn Sie externe Tabellen definieren, die direkt auf Parquet-/Metadatendateien in OCI/S3-Buckets verweisen.

Typischer Workflow beim Abfragen von Apache-Eisberg-Tabellen

Bevor Sie mit der Abfrage von Apache Iceberg Tables beginnen, sollten Sie mit dem Workflow vertraut sein. In diesem Abschnitt wird erläutert, wie Sie externe Tabellen einrichten, um auf Daten zuzugreifen, die als End-to-End-Setupworkflow dargestellt werden, mit fünf Hauptschritten.

  1. Entscheiden Sie Ihr Zugriffsmodell:
    • Katalogverwaltet: Verwenden Sie dieses Modell, wenn ein kontinuierlich aktualisierter, gesteuerter Katalog als Single Source of Truth für Datenmetadaten dienen soll. Dieser zentrale Katalog trägt zur Aufrechterhaltung der Konsistenz und Governance Ihrer Daten bei.
    • Direkte Metadaten: Verwenden Sie dieses Modell, wenn Sie mit einem festen Snapshot von Metadaten arbeiten (über metadata.json). Dieses Modell ist einfacher, aber statisch und wird für die Produktion nicht empfohlen, da es keine automatischen Updates und Governance enthält.
  2. Erfassen, was Sie benötigen:
    • Von Katalog verwaltet: Sie müssen Zugriff auf den Katalogendpunkt (falls zutreffend), den genauen Tabellenpfad und den Objektspeicherort haben, in dem sich die tatsächlichen Datendateien befinden.
    • Direkte Metadaten: Sie benötigen nur die URI, die auf die Datei metadata.json der Root verweist, sowie den Speicherort des Objektspeichers dieser Datendateien.
  3. Zugangsdaten vorbereiten:
    • Für Catalog-Managed-Setups müssen Sie Zugangsdaten für den Zugriff auf den Katalog anfordern.
    • Object Store-Zugangsdaten sind immer unabhängig vom Modell erforderlich, um sowohl Daten- als auch Metadatendateien zu lesen.
      Hinweis

      Automatisches Ausstellen von Zugangsdaten und AWS AssumeRole für den Katalogzugriff werden nicht unterstützt.
  4. Externe Tabelle erstellen:
    • In Katalogverwaltet fragt die Tabelle Daten über den Katalog ab und greift auf Dateien im Objektspeicher zu.
    • In Direct-Metadata verweist die Tabelle direkt auf die spezifische metadata.json-Datei, ohne dass der Katalog beteiligt ist.
  5. Schnellprüfung und Erwartungen:

    Führen Sie eine einfache Abfrage wie COUNT(*) aus, um das Tabellensetup zu prüfen und sicherzustellen, dass sie korrekt auf Daten zugreifen kann.

Mitarbeiter-Schnellstarts

In diesem Kapitel wird der Prozess zum Einrichten des externen Datenzugriffs mit verschiedenen Cloud-Datenanbietern beschrieben.

Themen:

Databricks Unity-Katalog

In diesem Abschnitt wird der Workflow erläutert, der Databricks mit offenen Tabellenformaten über UniForm verknüpft. Dadurch wird der Zugriff auf Delta Lake-Daten in Umgebungen erleichtert, die Iceberg unterstützen.

Databricks Unity Catalog (Pfad UniForm)

Voraussetzungen:
  • Eine mit UniForm erstellte Delta-Tabelle, damit Iceberg-Clients sie lesen können.
  • Tabellendateien in Azure ADLS Gen2 oder AWS S3.
  • Unity-Katalogberechtigungen für externen Zugriff (z.B. "Externer Datenzugriff aktiviert") und EXTERNAL USE SCHEMA für Ihren Principal erteilen.
  • Authentifizierung: OAuth2 (empfohlen) oder persönliches Zugriffstoken (für Schnelltests).
Hinweis

Native Iceberg über Iceberg REST wird von unserer Integration noch nicht unterstützt. Verwenden Sie Delta mit UniForm (Iceberg-readable), und stellen Sie es über Unity Iceberg REST bereit: https://<workspace-host>/api/2.1/unity-catalog/iceberg.

Erstellen Sie eine Tabelle UniForm (Iceberg-readable) in Databricks:

Mit der folgenden Prozedur wird eine UniForm-(Iceberg-readable-)Tabelle namens customers_iceberg in Databricks innerhalb des angegebenen Unity Catalog-Katalogs und -Schemas erstellt:
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');

Zugangsdaten für Objektspeicher (ADLS Gen2)

Mit der folgenden Prozedur werden Zugangsdaten für den Objektspeicherzugriff (Azure Data Lake Storage Gen2) mit Speicheraccountschlüsseln oder SAS-Token für einen sicheren externen Cloud-Speicherzugriff eingerichtet.
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;
/

REST-Katalogzugangsdaten mit OAuth2 erstellen

Mit der folgenden Prozedur werden OAuth2-Zugangsdaten für die sichere Authentifizierung mit einem Databricks-Service-Principal (Client-ID und Secret) eingerichtet:
-- 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;

REST-Katalogzugangsdaten mit persönlichem Zugriffstoken (PAT) erstellen

Im Folgenden wird beschrieben, wie Sie einen PAT für Schnelltests verwenden, indem Sie PAT-Zugangsdaten erstellen und die externe Tabelle damit erstellen.
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

In diesem Thema wird Snowflake Polaris (REST-Katalog) beschrieben, der sicheren Zugriff auf Apache Polaris Iceberg-Tabellen über eine REST-API mit OAuth2-Authentifizierung ermöglicht.

Snowflake Polaris (REST-Katalog)

Voraussetzungen:
  • Polaris Iceberg Katalog und Endpunkt für Ihren Account verfügbar.
  • Tabellendateien, auf die in Ihrem Objektspeicher zugegriffen werden kann (S3/ADLS, sofern zutreffend).
  • Auth: OAuth2 empfohlen (Clientzugangsdaten) oder ein anderer von Polaris unterstützter Tokenmechanismus.

Erstellen Sie OAuth2-Zugangsdaten:

Mit dem folgenden Verfahren werden OAuth2-Zugangsdaten mit dem Namen POLARIS_OAUTH erstellt, um den Zugriff auf einen Apache Polaris Iceberg-Katalog zu authentifizieren.

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

Speicherzugangsdaten erstellen

Mit dem folgenden Verfahren werden Speicherzugangsdaten mit dem Namen S3_CRED für den Zugriff auf den Objektspeicher (Beispiel: Amazon S3) mit einer AWS-Zugriffsschlüssel-ID und einem Secret Access Key erstellt.

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

Externe Tabelle erstellen

Die folgende Prozedur definiert eine externe Tabelle namens SALES_POLARIS in Databricks, die auf Daten zugreift, die im Iceberg-Format gespeichert sind, das vom Polaris-Katalog verwaltet wird.
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;
/

Schnellfunktionalität prüfen

Im Folgenden wird eine Abfrage ausgeführt, um zu prüfen, ob die externe Tabelle korrekt eingerichtet und zugänglich ist.
SELECT COUNT(*) FROM SALES_POLARIS;
Hinweis

Behalten Sie die Platzhalter für Endpunkt- und Token-URL bei, da sie je nach Polaris-Konfiguration variieren.

AWS Glue-Katalog

In diesem Thema wird beschrieben, wie Sie über den Glue Data Catalog mit registrierten Iceberg-Tabellen über AWS-Zugangsdaten auf Amazon S3-Daten zugreifen.

Voraussetzungen:
  • Kleben Sie den Datenkatalog mit der registrierten Iceberg-Tabelle (S3-Objekte zugänglich).

    Regionsname für Kleber (z.B. us-east-1).

  • Auth: Zugriff auf Schlüssel/Secret für S3; Glue-Zugriff über Katalogkonfiguration.

  • Zugangsdaten-Vending über AWS ARN wird nicht unterstützt. Explizite Zugangsdaten müssen angegeben werden.

Speicherzugangsdaten erstellen

Mit der folgenden Prozedur werden Speicherzugangsdaten mit dem Namen S3_CRED in Databricks erstellt, um den Zugriff auf Daten zu ermöglichen, die in einem Amazon S3-Bucket gespeichert sind.

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

Erstellen eines externen Iceberg-Tisches

Erstellt eine externe Iceberg-Tabelle mit dem Namen 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;
/

Schnellfunktionalität prüfen

Die folgende Prozedur führt eine Abfrage aus, um alle Zeilen in der externen Tabelle ORDERS_GLUE zu zählen und die Verbindung und Datenzugänglichkeit zu prüfen.
SELECT COUNT(*) FROM ORDERS_GLUE;

Hadoop/Dateisystem (direkte Metadatendatei)

In diesem Thema wird erläutert, wie Sie Speicherzugangsdaten für den Zugriff auf die Metadatendatei einer Iceberg-Tabelle direkt aus Objektspeichern wie ADLS, S3 oder OCI erstellen. Es wird erläutert, wie die Typen der direkten Metadatenverwaltung für Iceberg-Tabellen kategorisiert werden, die direkt im Dateisystem gespeichert sind (in der Regel Hadoop-kompatible Dateisysteme), ohne einen Katalogservice zu verwenden.

Beispiel: Iceberg-Tabelle mit JSON-Metadaten abfragen

Voraussetzungen:
  • Sie können im Objektspeicher (ADLS/S3/OCI) auf das Iceberg-Root-Manifest (metadata.json) der Tabelle zugreifen.
  • Dieser Pfad lautet Point-in-Time. Um neuen Snapshots zu folgen, erstellen Sie die externe Tabelle neu.

Speicherzugangsdaten erstellen

Bei dieser Prozedur wird zuerst versucht, vorhandene Zugangsdaten mit dem Namen STORE_CRED zu löschen, falls diese vorhanden sind (Fehler werden ignoriert). Anschließend werden neue Zugangsdaten mit dem Namen STORE_CRED erstellt.

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

Externe Tabelle erstellen

Es erstellt eine externe Tabelle mit dem Namen 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;
/

Schnellfunktionalität prüfen

Im folgenden Verfahren wird eine Abfrage ausgeführt, um alle Zeilen in der externen Tabelle zu zählen.


SELECT COUNT(*) FROM CUSTOMERS_META;

Beispiel: Iceberg-Tabelle mit Hadoop-Katalog auf OCI abfragen

In diesem Beispiel fragen wir die Iceberg-Tabelle db.icebergTablePy ab, die mit OCI Data Flow erstellt wurde. Dabei verwendet Spark die HadoopCatalog-Implementierung für den Iceberg-Katalog. HadoopCatalog verwendet den Lakehouse-Ordner iceberg im Bucket my-iceberg-bucket und stellt die Iceberg-Metadaten in einen $database_name/$table_name-Unterordner unter dieses Verzeichnis. Außerdem wird eine version-hint.text-Datei verwendet, die die Versionsnummer für die neueste Version der Metadatendatei enthält.

Erstellen Sie wie folgt eine externe Tabelle für Tabelle db.icebergTablePy:
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;
/

Referenzen

Dieser Abschnitt enthält eine Liste der Referenzen für Links, die in diesem Kapitel aufgeführt werden: