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

Setup-Anforderungen für Iceberg

In diesem Thema werden die Setupanforderungen für die Verwendung von Iceberg mit Oracle Autonomous AI Database beschrieben.

Themen

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 Autonomous Database 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.

Voraussetzung: Netzwerkzugriffssteuerungslisten (ACLs) für Iceberg-Vorgänge erteilen

In diesem Thema wird erläutert, wie Sie dem Datenbankschema, das Apache Iceberg-Anweisungen ausführt, Berechtigungen für Network Access Control Lists (ACL) erteilen.

Bevor Sie Apache Iceberg-Tabellen in Oracle Database 23ai abfragen, müssen Sie Netzwerkzugriffsberechtigungen konfigurieren. Iceberg-Vorgänge kommunizieren mit externen Services über HTTPS, einschließlich System-HTTP-Proxys, Katalogserviceendpunkten und Object Storage-Repositorys wie Amazon S3 oder OCI Object Storage.

Um diese Verbindungen zuzulassen, erteilen Sie dem Datenbankschema, das Iceberg-Abfragen oder Data Definition Language-(DDL-)Anweisungen ausführt, Netzwerkzugriffssteuerungslisten (ACLs). Wenn die erforderlichen ACLs nicht erteilt werden, schlagen Vorgänge mit dem folgenden Fehler fehl: ORA-20000: Failed to generate column list, ORA-24247: network access denied by access control list (ACL).

Sie müssen diese ACLs folgenden Berechtigungen erteilen:
  • Das Schema, das die externe Iceberg-Tabelle erstellt und Eigentümer ist, muss über ausgehenden HTTPS-Zugriff auf die erforderlichen Hostnamen verfügen.
  • Benutzer, die nur SELECT-Anweisungen in einer vorhandenen externen Iceberg-Tabelle ausführen müssen, benötigen diese ACLs nicht. Sie benötigen nur Standardberechtigungen, wie DWROLE und SELECT in der Tabelle.
Zu den Best Practices für die Definition von ACLs gehören, sie so restriktiv wie möglich zu halten, sie auf HTTPS (Port 443) zu beschränken und nur den Zugriff auf die spezifischen Hosts zuzulassen, die von Iceberg benötigt werden. Beispiel: Wenn Ihre Iceberg-Tabelle Metadaten und Datendateien in OCI Object Storage speichert, gehen Sie wie folgt vor:
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;
/

 Geben Sie die entsprechenden Werte für den Namen <schema> und <region> mit Ihrer OCI-Region an.

In diesem Beispiel wird einem Oracle-Datenbankschema die Berechtigung erteilt, ausgehende HTTPS-Anforderungen an einen OCI Object Storage-Endpunkt auszuführen.

Die Prozedur DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE fügt einen Access Control-Eintrag (ACE) hinzu, mit dem das angegebene Schema die Berechtigung http (einschließlich HTTPS) verwenden kann, wenn eine Verbindung zum regionalen OCI Object Storage-Endpunkt auf Port 443 hergestellt wird. Dieser Zugriff ist erforderlich, um Iceberg-Tabellenmetadaten zu lesen und Datendateien abzurufen, die in OCI Object Storage gespeichert sind.

Weitere Informationen finden Sie unter DBMS_NETWORK_ACL_ADMIN.

Hostnamen nach Konfiguration

Bestimmen Sie anhand der folgenden Tabelle, welche Hostnamen in der Regel ACL-Einträge für das Schema erfordern, das DBMS_CLOUD.CREATE_EXTERNAL_TABLE ausführt:
Speicher Hostnamen

OCI Object Storage (kein externer Katalog oder HadoopCatalog)

objectstorage.<region>.oraclecloud.com

AWS S3 (kein externer Katalog)

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

AWS Glue-Katalog + 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)

Databricks Unity-Katalog + S3

  • <workspace>.azuredatabricks.net

  • <bucket>.s3.amazonaws.com

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

Schneeflocke Polaris + S3

  • <account>.snowflakecomputing.com

    (Polaris und Token-Endpunkte)
  • <bucket>.s3.amazonaws.com

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

Snowflake Polaris + Azure (ADLS Gen2)

  • <account>.snowflakecomputing.com

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

Wenn Sie einen HTTPS-Proxy verwenden, müssen Sie auch ACLs für den Proxyhost konfigurieren. Weitere Informationen finden Sie unter Webservices aus autonomer KI-Datenbank aufrufen.

Schemarollen für Iceberg-Vorgänge erteilen

Die DWROLE muss jedem Schema erteilt werden, das externe Iceberg-Tabellen erstellt oder verwaltet.

In Autonomous AI Database ist DWROLE das Standardberechtigungsset für die Ausführung von Dataloading und zugehörigen Vorgängen mit dem Package DBMS_CLOUD. Durch die Zuweisung dieser Rolle wird sichergestellt, dass das Schema über die erforderlichen Berechtigungen verfügt, um auf Cloud-Speicher zuzugreifen und externe Iceberg-Tabellen zu erstellen, abzufragen und zu verwalten.

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

  • Netzwerk-ACLs konfigurieren: Bevor Sie eine externe Tabelle erstellen, die Databricks Unity Catalog mit Daten verwendet, die in Azure Blob Storage gespeichert sind, müssen Sie dem Oracle-Schema die Berechtigung erteilen, ausgehende HTTPS-Verbindungen zu den erforderlichen Azure-Services herzustellen. Da Oracle Database standardmäßig den Netzwerkzugriff blockiert, müssen Sie die Network Access Control-Liste (ACL) aktualisieren, damit das Schema Folgendes erreichen kann:
    • Der Databricks-Workspace, der Unity Catalog-APIs und Token-/Authentifizierungsendpunkte hostet.

    • Der Azure Storage-Account, in dem die Metadaten und Datendateien der Iceberg-Tabelle gespeichert werden.

    Beispiel für die Konfiguration von Netzwerk-ACLs
    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;
    /

    Ersetzen Sie die folgenden Platzhalter:

    • <workspace>: Der Databricks-Workspace-Name, der in Ihrer Azure-Databricks-URL verwendet wird.
    • <storage-account>: Der Azure Storage-Accountname, der Iceberg-Metadaten und -Datendateien enthält.
    • <schema>: Das Oracle-Schema, das DBMS_CLOUD.CREATE_EXTERNAL_TABLE ausführt und HTTPS-Zugriff erfordert.
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.

  • Bevor Sie eine externe Tabelle erstellen, die auf einen Iceberg-Katalog zugreift, der in Snowflake und Amazon S3 gespeichert ist, muss das Datenbankschema berechtigt sein, ausgehende HTTPS-Verbindungen zu diesen Services herzustellen. Oracle Database schränkt den Netzwerkzugriff standardmäßig ein. Daher müssen Sie die Network Access Control-Liste (ACL) aktualisieren, damit das Schema Folgendes erreichen kann:
    • Ihre Snowflake-Accountendpunkte, die für Katalogzugriff, Authentifizierung und Tokenaustausch verwendet werden

    • Der regionale Endpunkt von Amazon S3, an dem Iceberg Metadaten und Datendateien gespeichert werden

    • (Optional) Der nicht-regionale S3-Endpunkt, der für einige AWS-APIs und Regions-Lookup-Vorgänge erforderlich ist

    Beispiel für die Konfiguration von Netzwerk-ACLs
    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;
    /

    Ersetzen Sie die folgenden Platzhalter:

    • <account>: Ihre Snowflake-Account-ID.

    • <schema>: Das Schema, das ausgehenden HTTPS-Zugriff benötigt.

    • <bucket>: Der Name des Amazon S3-Buckets, der die Iceberg-Daten und -Metadaten enthält.

    • <region>: Die AWS-Region, in der der Bucket S3 gehostet wird.

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.

  • Bevor Sie eine externe Tabelle erstellen, die AWS Glue als Iceberg-Katalog und Amazon S3 als Speicherebene verwendet, muss dem Oracle-Schema die Berechtigung erteilt werden, ausgehende HTTPS-Anforderungen an diese AWS-Services auszuführen. Oracle Database schränkt den Netzwerkzugriff standardmäßig ein. Daher müssen Sie die Network Access Control-Liste (ACL) aktualisieren, damit das Schema Folgendes erreichen kann:
    • AWS Glue, das die Iceberg-Katalog-API bereitstellt

    • Der regionale Endpunkt S3, in dem Iceberg-Metadaten und Datendateien gespeichert werden

    • Der nichtregionale S3-Endpunkt, der für bestimmte AWS-APIs und Regions-Lookup-Vorgänge erforderlich ist

    Beispiel für die Konfiguration von Netzwerk-ACLs
    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;
    /

    Ersetzen Sie die folgenden Platzhalter:

    • <region>: Die AWS-Region, in der sich Glue und der Bucket S3 befinden.

    • <bucket>: Der Name des S3-Buckets, der Iceberg-Daten- und Metadatendateien speichert.

    • <schema>: Das Oracle-Schema, das DBMS_CLOUD.CREATE_EXTERNAL_TABLE ausführt und HTTPS-Zugriff erfordert.

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: