Utiliser une base de données liée à un catalogue pour les tables Apache Iceberg™¶
Note
We will start billing for catalog-linked databases on November 17, 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.
Billing for catalog-linked databases¶
Lorsque la facturation commencera le 17 novembre 2025, Snowflake facturera votre compte pour l’utilisation suivante :
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.
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) :
The following example creates a catalog-linked database that uses vended credentials. The sync interval is 30 seconds, which is the default. The sync interval tells Snowflake how often to poll your remote catalog.
CREATE DATABASE my_linked_db
LINKED_CATALOG = (
CATALOG = 'my_catalog_int'
);
Note
To create a catalog-linked database that uses an external volume, see CREATE DATABASE (liée à un catalogue), including the example.
Your catalog-linked database includes a link icon.
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');
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 Requirements for identifier resolution in a catalog-linked database.
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;
É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 :
Requirements for identifier resolution in a catalog-linked database¶
L’exigence de résolution d’un identificateur dépend des éléments suivants :
La valeur que vous avez spécifiée pour le paramètre CATALOG_CASE_SENSITIVITY lorsque vous avez créé votre base de données liée à un catalogue.
Le fait que votre catalogue Iceberg externe utilise des identificateurs sensibles à la casse ou non.
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.
When you create a new schema, table, or column in a case-sensitive catalog such as AWS Glue or Unity Catalog, you must use lowercase letters and surround the schema, table, and column names in double quotes. This is also required for other Iceberg REST catalogs that only support lowercase identifiers.
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. The following example shows a valid query for creating a table: CREATE TABLE "Table1" (id INT, name STRING);
Snowflake crée la table dans le catalogue externe sous le nom The following example shows a valid query for selecting the SELECT * FROM "Table1";
Dans l’exemple précédent, les guillemets doubles sont nécessaires pour que la capitalisation corresponde exactement. The following example shows an invalid query, unless a SELECT * FROM table1;
Dans l’exemple précédent, la requête n’est pas valide si une L’exemple suivant montre une requête non valide dans le cas où une SELECT * FROM TABLE1;
|
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. The following example shows valid queries: SELECT * from "s1";
SELECT * from "lowercasetablename";
|
CASE_INSENSITIVE |
Identificateurs insensibles à la casse |
|
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 SELECT * from table1;
SELECT * from TABLE1;
SELECT * from Table1;
SELECT * from "Table1";
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¶
Consider the following items when you use a catalog-linked database:
Prise en charge uniquement lorsque vous utilisez une intégration de catalogue pour REST Iceberg (par exemple, Snowflake Open Catalog).
Nous commencerons la facturation le 17 novembre 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 doesn’t sync remote catalog access control for users or roles.
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.
You can’t create database roles in a catalog-linked database.
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-uuidd’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.
Masking policies and tags are supported. Other Snowflake-specific features, including replication and cloning, aren’t supported.
The character that you choose for the NAMESPACE_FLATTEN_DELIMITER parameter can’t appear in your remote namespaces. During the auto discovery process, Snowflake skips any namespace that contains the delimiter, and doesn’t create a corresponding schema in your catalog-linked database.
If you specify anything other than
_,$, or numbers for the NAMESPACE_FLATTEN_DELIMITER parameter, you must put the schema name in quotes when you query the 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";
Les instructions suivantes ne sont pas valides, car elles utilisent des lettres majuscules ou omettent les guillemets doubles :
CREATE SCHEMA s1; CREATE SCHEMA "Schema1";
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 :
Creating tables in nested namespaces isn’t currently supported.
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_READsur FALSE au niveau de la table, du schéma ou de la base de données.