Utiliser une base de données liée à un catalogue pour les tables Apache Iceberg™

Note

Update: We will start billing for catalog-linked databases sometime in December 2025.

Avec une base de données liée à un catalogue, vous pouvez accéder à plusieurs tables Iceberg distantes de Snowflake sans créer de tables gérées en externe individuellement.

Une base de données liée à un catalogue est une base de données Snowflake connectée à un catalogue REST Iceberg externe. Snowflake se synchronise automatiquement avec le catalogue externe pour détecter les espaces de noms et les tables Iceberg et enregistre les tables distantes dans la base de données liée au catalogue. Les bases de données liées à un catalogue prennent également en charge la création et la suppression de schémas ou de tables Iceberg.

Facturation pour les bases de données liées à un catalogue

When billing starts sometime in December 2025, Snowflake bills your account for the following usage:

  • Découverte automatique des tables, création de schémas, suppression de schémas et suppression de tables. Snowflake facturera votre compte pour cette utilisation sous le type d’utilisation CREDITS_USED_CLOUD_SERVICES. L’utilisation des services Cloud n’est facturée que si la consommation quotidienne de services Cloud dépasse 10 % de l’utilisation quotidienne des entrepôts virtuels. Pour plus d’informations, voir Comprendre la facturation pour l’utilisation des services Cloud.

  • Création de tables. Snowflake facturera votre compte pour cette utilisation sous le type d’utilisation CREDITS_USED_COMPUTE via l’actualisation automatique. Le coût de cette utilisation est décrit dans la table 5 du Tableau de consommation du service Snowflake sur le site Web de Snowflake. Reportez-vous à la colonne des calculs gérés par Snowflake pour consulter la ligne Actualisation automatique et Enregistrement des données.

Snowflake ne vous facturera pas les services Cloud que vous utilisez lors de la création de tables.

Note

Lorsque la facturation commencera, nous publierons une nouvelle vue CATALOG_LINKED_DATABASE_USAGE_HISTORY, que vous pourrez utiliser pour afficher l’utilisation du crédit pour vos bases de données liées à un catalogue.

Flux de travail pour configurer l’accès à votre catalogue externe et au stockage de tables

Les étapes suivantes expliquent comment créer une base de données liée à un catalogue, vérifier l’état de synchronisation entre Snowflake et votre catalogue, et créer ou interroger une table dans la base de données.

  1. Configurer l’accès à votre catalogue externe et au stockage de tables

  2. Créer une base de données liée à un catalogue

  3. Vérifier l’état de synchronisation du catalogue

  4. Interroger une table dans votre base de données liée à un catalogue ou Écrire dans votre catalogue distant

Configurer l’accès à votre catalogue externe et au stockage de tables

Avant de créer une base de données liée à un catalogue, vous devez configurer l’accès à votre catalogue externe et au stockage de tables. Pour configurer cet accès, vous devez configurez une intégration de catalogue avec des identifiants de connexion distribués. Avec cette option, votre catalogue Iceberg distant doit prendre en charge la distribution d’identifiants.

Pour obtenir des instructions, voir Utiliser des identifiants de connexion distribués par catalogue pour les tables Apache Iceberg™.

Note

Si votre catalogue Iceberg distant ne prend pas en charge le système de distribution d’identifiants de connexion, vous devez configurer un volume externe et une intégration de catalogue pour configurer l’accès à votre catalogue externe et à votre stockage de tables. D’abord, configurez un volume externe pour votre fournisseur de stockage Cloud. Ensuite, configurez une intégration de catalogue REST Apache Iceberg™ pour votre catalogue Iceberg distant.

Créer une base de données liée à un catalogue

Créez une base de données liée à un catalogue avec la commande CREATE DATABASE (liée à un catalogue) :

L’exemple suivant crée une base de données liée à un catalogue qui utilise des identifiants de connexion distribués. L’intervalle de synchronisation est de 30 secondes, ce qui correspond à la valeur par défaut. L’intervalle de synchronisation indique à Snowflake à quelle fréquence interroger votre catalogue distant.

CREATE DATABASE my_linked_db
  LINKED_CATALOG = (
    CATALOG = 'my_catalog_int'
  );
Copy

Note

Pour créer une base de données liée à un catalogue qui utilise un volume externe, consultez CREATE DATABASE (liée à un catalogue), y compris l’exemple.

Votre base de données liée à un catalogue comprend une icône de lien.

Formulaire de soumission d'un nouveau ticket

Vérifier l’état de synchronisation du catalogue

Pour savoir si Snowflake a bien lié votre catalogue distant à votre base de données, utilisez la fonction SYSTEM$CATALOG_LINK_STATUS.

Cette fonction fournit également des informations pour vous aider à identifier les tables du catalogue distant qui ne parviennent pas à se synchroniser.

SELECT SYSTEM$CATALOG_LINK_STATUS('my_linked_db');
Copy

Identifier les tables qui ont été créées, mais qui n’ont pas pu être initialisées

Pour identifier les tables du catalogue distant qui se sont synchronisées correctement, mais qui échouent à s’actualiser automatiquement, exécutez la commande SHOW ICEBERG TABLES, puis reportez-vous à la colonne auto_refresh_status dans la sortie. Ces tables ont un executionState de ICEBERG_TABLE_NOT_INITIALIZED dans la sortie.

Par exemple, Snowflake peut détecter et créer correctement une table dans votre catalogue distant vers votre base de données liée au catalogue, mais cette table contient un fichier de données corrompu dans votre catalogue distant. Par conséquent, Snowflake ne peut pas actualiser automatiquement la table tant que vous n’avez pas résolu l’erreur.

L’actualisation automatique est désactivée pour ce type de tables. L’interrogation de la table dans Snowflake renvoie donc une erreur indiquant que la table n’a jamais été initialisée. Pour interroger la table, vous devez corriger l’erreur, puis activer l’actualisation automatique pour la table.

Interroger une table dans votre base de données liée à un catalogue

Une fois que vous avez créé une base de données liée à un catalogue, Snowflake démarre le processus de découverte de la table et interroge automatiquement votre catalogue lié en utilisant la valeur du paramètre SYNC_INTERVAL_SECONDS (avec un intervalle par défaut de 30 secondes) pour vérifier les modifications.

Dans la base de données, les espaces de noms autorisés du catalogue distant apparaissent sous la forme de schémas, et les tables Iceberg apparaissent sous leurs schémas respectifs.

Vous pouvez interroger les tables distantes en utilisant une instruction SELECT.

Note

Pour connaître les exigences relatives à l’identification d’objets dans une base de données liée à un catalogue, consultez Exigences pour la résolution des identificateurs dans une base de données liée à un catalogue.

Pour plus d’informations sur les identificateurs d’objets, consultez Exigences relatives à l’identificateur.

Par exemple :

USE DATABASE my_linked_db;

SELECT * FROM my_namespace.my_iceberg_table
  LIMIT 20;
Copy

Écrire dans votre catalogue distant

Vous pouvez utiliser Snowflake pour créer des espaces de noms et des tables Iceberg dans votre catalogue lié. Pour plus d’informations, consultez les rubriques suivantes :

Exigences pour la résolution des identificateurs dans une base de données liée à un catalogue

L’exigence de résolution d’un identificateur dépend des éléments suivants :

Note

  • Ces exigences s’appliquent à l’identification des schémas, des tables et des colonnes de tables qui existent déjà. Elles comprennent également certains cas particuliers pour la création ou la modification d’un objet.

  • Lorsque vous créez un nouveau schéma, une nouvelle table ou une nouvelle colonne dans un catalogue sensible à la casse, par exemple AWS Glue ou Unity Catalog, vous devez utiliser des lettres minuscules et mettre le nom du schéma, de la table et de la colonne entre guillemets doubles. Cela est également requis pour les autres catalogues REST Iceberg qui ne prennent en charge que les identificateurs en minuscules.

Le tableau suivant montre l’exigence pour chaque scénario :

Valeur CATALOG_CASE_SENSITIVITY

Utilisations d’un catalogue Iceberg externe

Exigence

CASE_SENSITIVE

Identificateurs sensibles à la casse

Snowflake fait correspondre les identificateurs exactement tels qu’ils apparaissent, en respectant la casse. Snowflake convertit automatiquement les identificateurs sans guillemets en majuscules, mais les identificateurs entre guillemets doivent correspondre exactement à la casse dans votre catalogue externe.

L’exemple suivant montre une requête valide pour la création d’une table :

CREATE TABLE "Table1" (id INT, name STRING);
Copy

Snowflake crée la table dans le catalogue externe sous le nom Table1, et conserve donc la capitalisation que vous avez utilisée. Notez que vous pouvez également créer une table table1 en minuscules, si nécessaire.

L’exemple suivant montre une requête valide pour la sélection de la table Table1 :

SELECT * FROM "Table1";
Copy

Dans l’exemple précédent, les guillemets doubles sont nécessaires pour que la capitalisation corresponde exactement.

L’exemple suivant montre une requête non valide, à moins qu’une table TABLE1 existe :

SELECT * FROM table1;
Copy

Dans l’exemple précédent, la requête n’est pas valide si une TABLE1 n’existe pas, car l’identificateur n’est pas entre guillemets doubles. Par conséquent, Snowflake convertit l’identificateur en majuscules.

L’exemple suivant montre une requête non valide dans le cas où une TABLE1 tout en majuscules n’existe pas :

SELECT * FROM TABLE1;
Copy

CASE_SENSITIVE

Identificateurs insensibles à la casse

Si le catalogue Iceberg externe est réellement insensible à la casse, et s’il normalise en minuscules, vous devez mettre les identificateurs entre guillemets doubles.

L’exemple suivant montre une requête valide :

SELECT * from "s1";
SELECT * from "lowercasetablename";
Copy

CASE_INSENSITIVE

Identificateurs insensibles à la casse

  • Si votre catalogue insensible à la casse comporte une table table1 en minuscules, toutes les requêtes suivantes sont valides :

    SELECT * from table1;
SELECT * from TABLE1;
SELECT * from Table1;
SELECT * from "table1";
    Copy

  • Pour toutes les commandes suivantes, vous devez mettre les noms de schémas, de tables et de colonnes entre guillemets doubles :

    • CREATE ICEBERG TABLE

    • CREATE SCHEMA

    • ALTER ICEBERG TABLE ADD COLUMN

    • ALTER ICEBERG TABLE RENAME COLUMN

CASE_INSENSITIVE

Identificateurs sensibles à la casse

Si le catalogue Iceberg externe est réellement sensible à la casse, Snowflake traite les identificateurs sans guillemets comme insensibles à la casse et convertit automatiquement les identificateurs sans guillemets en majuscules. Lorsque vous créez ou interrogez des objets, Snowflake fait correspondre les identificateurs, indépendamment de la casse, à condition qu’ils ne soient pas entre guillemets.

L’utilisation de ce modèle est déconseillée, car Snowflake ne peut pas résoudre deux identificateurs différents qui diffèrent par leur casse. Ce modèle ne fonctionne que lorsque deux identificateurs ne diffèrent pas uniquement par leur casse.

Considérons le cas où le catalogue distant contient une table Table1. Toutes les requêtes suivantes sont valides pour interroger cette table.

SELECT * from table1;
SELECT * from TABLE1;
SELECT * from Table1;
SELECT * from "Table1";
Copy

Les identificateurs entre guillemets conservent la casse et correspondent exactement. Cependant, en mode CASE_INSENSITIVE, les formes entre guillemets et sans guillemets sont toutes deux prises en charge.

Considérations relatives à l’utilisation d’une base de données liée à un catalogue pour les tables Iceberg

Tenez compte des éléments suivants lorsque vous utilisez une base de données liée à un catalogue :

  • Prise en charge uniquement lorsque vous utilisez une intégration de catalogue pour REST Iceberg (par exemple, Snowflake Open Catalog).

  • Update: We will start billing sometime in December 2025.

  • Pour limiter la découverte automatique des tables à un ensemble spécifique d’espaces de noms, utilisez le paramètre ALLOWED_NAMESPACES. Vous pouvez également utiliser le paramètre BLOCKED_NAMESPACES pour bloquer un ensemble d’espaces de noms.

  • Snowflake ne synchronise pas le contrôle d’accès au catalogue distant pour les utilisateurs ou les rôles.

  • Vous pouvez créer des schémas ou des tables Iceberg gérées en externe dans une base de données liée à un catalogue. La création d’autres objets Snowflake n’est actuellement pas prise en charge.

  • Vous ne pouvez pas créer de rôles de base de données dans une base de données liée à un catalogue.

  • Latence :

    • Pour les bases de données liées à 7 500 espaces de noms dans un catalogue distant, la découverte des espaces de noms et des tables prend environ une heure.

    • Pour les catalogues distants comportant 500 000 tables, le processus d’actualisation automatique prend environ une heure. Pour les espaces de noms ayant des exigences de latence différentes, nous vous recommandons de créer des bases de données liées à un catalogue distinctes. Chaque base de données doit référencer une intégration de catalogue avec un intervalle d’actualisation automatique approprié (REFRESH_INTERVAL_SECONDS).

  • Pour les tables Iceberg dans une base de données liée à un catalogue :

    • Snowflake ne copie pas les propriétés de la table de catalogue distante (telles que les politiques de conservation ou les tampons) et ne prend actuellement pas en charge la modification des propriétés de la table.

    • L’actualisation automatique est activée par défaut. Si l’table-uuid d’une table externe et la table de la base de données liée au catalogue ne correspondent pas, l’actualisation échoue et Snowflake supprime la table de la base de données liée au catalogue. Snowflake ne modifie pas la table distante.

    • Si vous supprimez une table du catalogue distant, Snowflake supprime la table de la base de données liée au catalogue. Cette action est asynchrone, de sorte que vous ne verrez peut-être pas immédiatement cette modification dans le catalogue distant.

    • Si vous renommez une table dans le catalogue distant, Snowflake supprime la table existante de la base de données liée au catalogue et crée une table avec le nouveau nom.

    • Les politiques de masquage et les balises sont prises en charge. Les autres fonctionnalités spécifiques à Snowflake, notamment la réplication et le clonage, ne sont pas prises en charge.

    • Le caractère que vous choisissez pour le paramètre NAMESPACE_FLATTEN_DELIMITER ne peut pas apparaître dans vos espaces de noms distants. Pendant le processus de découverte automatique, Snowflake ignore tout espace de noms contenant le délimiteur et ne crée pas de schéma correspondant dans votre base de données liée à un catalogue.

    • Si vous spécifiez autre chose que _, $ ou des chiffres pour le paramètre NAMESPACE_FLATTEN_DELIMITER, vous devez mettre le nom du schéma entre guillemets lorsque vous interrogez la table.

    • Pour les bases de données liées à AWS Glue, vous devez utiliser des minuscules et mettre les noms de schémas, de tables et de colonnes entre guillemets doubles. Cela est également requis pour les autres catalogues REST Iceberg qui ne prennent en charge que les identificateurs en minuscules.

      L’exemple suivant montre une requête valide :

      CREATE SCHEMA "s1";
      Copy

      Les instructions suivantes ne sont pas valides, car elles utilisent des lettres majuscules ou omettent les guillemets doubles :

      CREATE SCHEMA s1;
CREATE SCHEMA "Schema1";
      Copy

    • L’utilisation de UNDROP ICEBERG TABLE n’est pas prise en charge.

    • Partage :

      • Le partage avec une annonce n’est actuellement pas pris en charge.

      • Le partage direct est pris en charge.

  • Pour l’écriture dans les tables d’une base de données liée à un catalogue :

    • La création de tables dans des espaces de noms imbriqués n’est actuellement pas prise en charge.

    • L’écriture dans des tables dans des espaces de noms imbriqués n’est actuellement pas prise en charge.

    • Les suppressions de position au niveau des lignes sont prises en charge pour les tables stockées sur Amazon S3, Azure ou Google Cloud. Les suppressions au niveau des lignes avec des fichiers de suppression d’égalité ne sont pas prises en charge. Pour plus d’informations sur les suppressions au niveau des lignes, consultez Utiliser les suppressions de niveau ligne. Pour désactiver les suppressions de position, qui permettent l’exécution des opérations du langage de manipulation des données (DML) en mode copie sur écriture, définissez le paramètre ENABLE_ICEBERG_MERGE_ON_READ sur FALSE au niveau de la table, du schéma ou de la base de données.

Langage: Français