Configurations prises en charge

Restrictions

Catalogue Iceberg

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 suivent les fichiers de données de la table ainsi que des informations telles que le partitionnement et les statistiques de colonne. Pour plus d'informations, reportez-vous à la section Iceberg Table Specification.

Transactions

Iceberg prend en charge les mises à jour au niveau ligne des tables à l'aide de la fonction de copie lors de l'écriture ou de la fonction de fusion lors de la lecture. La fonction de copie en écriture génère de nouveaux fichiers de données qui reflètent les lignes mises à jour, tandis que la fonction de fusion en lecture génère de nouveaux "fichiers de suppression" qui doivent être fusionnés avec les fichiers de données lors de la lecture. Oracle prend en charge la copie lors de l'écriture. Les requêtes sur les tables iceberg échouent si elles rencontrent un fichier de suppression. Pour plus d'informations, reportez-vous à RowLevelOperationMode.

Evolution de schéma

Iceberg prend en charge l'évolution des schémas. Les modifications de schéma sont reflétées dans les métadonnées de l'iceberg à l'aide d'un ID de schéma. Notez que les tables externes Oracle ont un schéma fixe, déterminé par la version de schéma la plus récente au moment de la création de la table. Les interrogations d'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, reportez-vous à 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 modification coûteuse de la disposition des données.

Interroger une table d'iceberg sur AWS à l'aide d'un catalogue de données de colle

Dans cet exemple, nous interrogeons la table Iceberg iceberg_parquet_time_dim.
Description de l'illustration example_1_table.png

La table appartient à la base de données Glue my-iceberg-db et est stockée dans le dossier s3://my-iceberg-bucket/iceberg-loc.

Les détails de la table pour iceberg_parquet_time_dim sont affichés ici :

Nous pouvons créer une table externe pour iceberg_parquet_time_dim comme suit :

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE (
    table_name       => 'iceberg_parquet_time_dim',
    credential_name  => 'AWS_CRED',
    file_uri_list    => '',
    format           =>
      '{"access_protocol":
        {
         "protocol_type": "iceberg",
         "protocol_config":
          {
           "iceberg_catalog_type": "aws_glue",
           "iceberg_glue_region": "us-west-1",
           "iceberg_table_path": "my-iceberg-db.iceberg_parquet_time_dim"
          }
        }
      }'
  );
END;
/

Dans la section protocol_config, nous indiquons que la table utilise AWS Glue comme type de catalogue et définissons la région du catalogue sur us-west-1.

Les informations d'identification AWS_CRED sont créées à l'aide de dbms_cloud.create_credential avec une clé d'API AWS. L'instance Glue Data Catalog est déterminée par l'ID de compte associé à AWS_CRED pour la région us-west-1, car il n'existe qu'une seule région Glue Data Catalog pour chaque compte. L'élément iceberg_table_path de la section protocol_config utilise un chemin $database_name.$table_name pour indiquer le nom de la table Glue et le nom de la base de données. Enfin, les paramètres column_list et field_list restent NULL car le schéma de la table est automatiquement dérivé des métadonnées de l'iceberg.

Pour plus d'informations sur la création des informations d'identification, reportez-vous à Procédure CREATE_CREDENTIAL. Pour plus d'informations sur les ressources AWS Glue, reportez-vous à Spécification des noms ARN des ressources AWS Glue.

Interroger une table Iceberg sur AWS à l'aide de l'emplacement du fichier de métadonnées racine

Si nous connaissons l'emplacement du fichier de métadonnées d'une table Iceberg, nous pouvons créer une table externe sans spécifier de catalogue, comme suit :

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE (
    table_name       => 'iceberg_parquet_time_dim',
    credential_name  => 'AWS_CRED',
    file_uri_list    => 'https://my-iceberg-bucket.s3.us-west-1.amazonaws.com/iceberg-loc/metadata/00004-1758ee2d-a204-4fd9-8d52-d17e5371a5ce.metadata.json',
    format           =>'{"access_protocol":{"protocol_type":"iceberg"}}');
END;
/

Le paramètre file_uri_list permet d'indiquer l'emplacement du fichier de métadonnées au format d'URL de type hébergé virtuel AWS S3. Pour plus d'informations sur ce format, reportez-vous à Méthodes d'accès à un bucket AWS S3.

Dans cet exemple, la base de données accède directement au fichier de métadonnées, il n'est donc pas nécessaire de fournir une section protocol_config dans le paramètre format. Lorsque vous utilisez l'emplacement du fichier de métadonnées pour créer une table externe, la base de données interroge le cliché le plus récent référencé par le fichier de métadonnées. Les mises à jour ultérieures de la table Iceberg, qui créent de nouveaux clichés et de nouveaux fichiers de métadonnées, ne seront pas visibles par la base de données.

Interroger une table Iceberg qui utilise le catalogue Hadoop sur OCI

Dans cet exemple, nous interrogeons la table d'iceberg icebergTablePy, créée à l'aide d'OCI Data Flow, où Spark utilise l'implémentation HadoopCatalog pour le catalogue d'iceberg. HadoopCatalog utilise un répertoire warehouse et place les métadonnées de l'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 de fichier de métadonnées la plus récente. Pour obtenir l'exemple sur Github, reportez-vous à Prise en charge d'Iceberg sur OCI Data Flow.

La table échantillon db.icebergTablePy a été créée à l'aide d'un dossier warehouse, nommé iceberg, dans le bucket OCI my-iceberg-bucket. La disposition de stockage sur OCI pour la table icebergTablePy est présentée ci-dessous :

Créez une table externe pour la table db.icebergTablePy comme suit :

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE (
    table_name       => 'iceberg_parquet_time_dim3',
    credential_name  => 'OCI_CRED',
    file_uri_list    => '',
    format           =>'{"access_protocol":{"protocol_type":"iceberg",
        "protocol_config":{"iceberg_catalog_type": "hadoop",
        "iceberg_warehouse":"https://objectstorage.uk-cardiff-1.oraclecloud.com/n/my-tenancy/b/my-iceberg-bucket/o/iceberg",
        "iceberg_table_path": "db.icebergTablePy"}}}');
END;
/

Interroger une table Iceberg sur OCI à l'aide de l'emplacement du fichier de métadonnées racine

Nous pouvons interroger la table Iceberg décrite dans la section précédente en utilisant directement l'URL du fichier de métadonnées, comme suit :

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE (
    table_name       => 'iceberg_parquet_time_dim4',
    credential_name  => 'OCI_CRED',
    file_uri_list    => 'https://objectstorage.uk-cardiff-1.oraclecloud.com/n/my-tenancy/b/my-iceberg-bucket/o/iceberg/db/icebergTablePy/metadata/v2.metadata.json',
    format           =>'{"access_protocol":{"protocol_type":"iceberg"}}'
    );
  END;
/

Dans cet exemple, nous utilisons le paramètre file_uri_list pour indiquer l'URI du fichier de métadonnées à l'aide du format d'URI OCI natif. Lorsque vous utilisez l'URI du fichier de métadonnées, la table externe interroge toujours le dernier cliché stocké dans le fichier spécifique. Les mises à jour suivantes qui génèrent de nouveaux clichés et de nouveaux fichiers de métadonnées ne sont pas accessibles à la requête.

Pour plus d'informations sur le format d'URI OCI natif, reportez-vous à Formats d'URI de stockage d'objet cloud.