Syntaxe
Arguments
La description des arguments est identique à celle des fonctions de tables3, azureBlobStorage, HDFS et file.
format désigne le format des fichiers de données de la table Iceberg.
Pour icebergS3, le paramètre facultatif extra_credentials peut être utilisé pour transmettre un role_arn afin d’activer l’accès basé sur les rôles dans ClickHouse Cloud. Voir Secure S3 pour connaître les étapes de configuration.
Valeur renvoyée
Une table ayant la structure spécifiée pour lire les données de la table Iceberg indiquée.Exemple
Définir une collection nommée
Voici un exemple de configuration d’une collection nommée pour stocker l’URL et les informations d’authentification :Utilisation d’un catalogue de données
Les tables Iceberg peuvent également être utilisées avec différents catalogues de données, tels que REST Catalog, AWS Glue Data Catalog et Unity Catalog. Pour les utiliser, créez une table avec le moteurIcebergS3 et fournissez les paramètres nécessaires.
Par exemple, en utilisant REST Catalog avec le stockage MinIO :
Évolution du schéma
À ce stade, avec CH, vous pouvez lire des tables Iceberg dont le schéma a évolué au fil du temps. Nous prenons actuellement en charge la lecture de tables dans lesquelles des colonnes ont été ajoutées ou supprimées, et dont l’ordre a été modifié. Vous pouvez également transformer une colonne où une valeur est obligatoire en colonne où NULL est autorisé. De plus, nous prenons en charge les conversions de type autorisées pour les types simples, à savoir :- int -> long
- float -> double
- decimal(P, S) -> decimal(P’, S) where P’ > P.
Élagage des partitions
ClickHouse prend en charge l’élagage des partitions lors des requêtes SELECT sur les tables Iceberg, ce qui permet d’optimiser les performances des requêtes en ignorant les fichiers de données non pertinents. Pour activer l’élagage des partitions, définissezuse_iceberg_partition_pruning = 1. Pour en savoir plus sur l’élagage des partitions dans Iceberg, consultez https://iceberg.apache.org/spec/#partitioning
Time travel
ClickHouse prend en charge le time travel pour les tables Iceberg, ce qui permet d’interroger des données historiques à l’aide d’un horodatage spécifique ou d’un ID de snapshot.Traitement des tables contenant des lignes supprimées
ClickHouse prend en charge les tables Iceberg avec des suppressions par position et des suppressions par égalité. Les suppressions par égalité sont prises en charge à partir de la v25.8. ClickHouse prend également en charge la lecture des vecteurs de suppression (introduits en v3). Cette prise en charge est en lecture seule : ClickHouse n’écrit, ne met à jour ni ne compacte les vecteurs de suppression, etALTER TABLE ... DELETE et ALTER TABLE ... UPDATE ne sont pas pris en charge pour les tables Iceberg au format version 3.
Utilisation de base
iceberg_timestamp_ms et iceberg_snapshot_id dans une même requête.
Points importants
- Les snapshots sont généralement créés dans les cas suivants :
- De nouvelles données sont écrites dans la table
- Une opération de compaction des données est effectuée
- Les modifications du schéma ne créent généralement pas de snapshots - Cela entraîne des comportements importants lors de l’utilisation du time travel sur des tables ayant subi une évolution du schéma.
Exemples de scénarios
Ces scénarios utilisent Spark pour illustrer les modifications de schéma effectuées par un writer Iceberg externe.Scénario 1 : Modifications de schéma sans nouveaux snapshots
Considérez la séquence d’opérations suivante :- À ts1 & ts2 : seules les deux colonnes d’origine sont présentes
- À ts3 : les trois colonnes sont présentes, avec NULL pour le prix de la première ligne
Scénario 2 : Différences entre le schéma historique et le schéma actuel
Une requête de time travel exécutée à l’instant présent peut afficher un schéma différent de celui de la table actuelle :ALTER TABLE ne crée pas de nouvel instantané ; pour la table actuelle, Spark prend la valeur de schema_id dans le fichier de métadonnées le plus récent, et non dans un instantané.
Scénario 3 : Différences entre le schéma historique et le schéma actuel
Le second point est que, lors d’un time travel, vous ne pouvez pas obtenir l’état de la table avant que des données n’y aient été écrites :Résolution du fichier de métadonnées
Lors de l’utilisation de la fonction de tableiceberg dans ClickHouse, le système doit trouver le fichier metadata.json approprié, qui décrit la structure de la table Iceberg. Voici comment ce processus de résolution fonctionne :
Recherche des candidats (par ordre de priorité)
- Spécification directe du chemin :
*Si vous définissez
iceberg_metadata_file_path, le système utilisera exactement ce chemin en le combinant avec le chemin du répertoire de la table Iceberg.
- Lorsque ce paramètre est fourni, tous les autres paramètres de résolution sont ignorés.
-
Correspondance de l’UUID de la table :
*Si
iceberg_metadata_table_uuidest spécifié, le système : *N’examinera que les fichiers.metadata.jsondu répertoiremetadata*Filtrera les fichiers contenant un champtable-uuidcorrespondant à l’UUID spécifié (sans distinction de casse) -
Recherche par défaut :
*Si aucun des paramètres ci-dessus n’est fourni, tous les fichiers
.metadata.jsondu répertoiremetadatadeviennent des candidats
Sélection du fichier le plus récent
Après avoir identifié les fichiers candidats à l’aide des règles ci-dessus, le système détermine lequel est le plus récent :-
Si
iceberg_recent_metadata_file_by_last_updated_ms_fieldest activé : -
Le fichier dont la valeur
last-updated-msest la plus élevée est sélectionné - Sinon :
- Le fichier dont le numéro de version est le plus élevé est sélectionné
-
(La version apparaît sous la forme
Vdans les noms de fichiers au formatV.metadata.jsonouV-uuid.metadata.json)
iceberg de ClickHouse interprète directement les fichiers stockés dans S3 comme des tables Iceberg ; il est donc important de comprendre ces règles de résolution.
Cache de métadonnées
Le moteur de tableIceberg et la fonction de table prennent en charge un cache de métadonnées qui stocke les informations des fichiers manifest, de la liste des manifests et du JSON de métadonnées. Ce cache est stocké en mémoire. Cette fonctionnalité est contrôlée par le paramètre use_iceberg_metadata_files_cache, activé par défaut.
Aliases
La fonction de tableiceberg est désormais un alias pour icebergS3.
Colonnes virtuelles
_path— Chemin du fichier. Type :LowCardinality(String)._file— Nom du fichier. Type :LowCardinality(String)._size— Taille du fichier en octets. Type :Nullable(UInt64). Si la taille du fichier est inconnue, la valeur estNULL._time— Date et heure de la dernière modification du fichier. Type :Nullable(DateTime). Si cette date et heure sont inconnues, la valeur estNULL._etag— ETag du fichier. Type :LowCardinality(String). Si l’ETag est inconnu, la valeur estNULL.
Écriture dans une table Iceberg
À partir de la version 25.7, ClickHouse prend en charge la modification des tables Iceberg sur des backends de stockage accessibles en écriture. Avant de modifier ou de maintenir une table Iceberg, activez le paramètreallow_insert_into_iceberg. Certaines opérations nécessitent des paramètres supplémentaires, comme indiqué ci-dessous :
Création d’une table
Pour créer une nouvelle table Iceberg autonome sur un backend accessible en écriture, utilisez un moteur de table Iceberg et indiquez explicitement le schéma. L’écriture prend en charge tous les formats de données définis par la spécification Iceberg, tels que Parquet, Avro et ORC.Exemple
iceberg_use_version_hint.
Si vous souhaitez compresser le fichier metadata.json, indiquez le nom du codec dans le paramètre iceberg_metadata_compression_method.
INSERT
Après avoir créé une nouvelle table, vous pouvez insérer des données à l’aide de la syntaxe ClickHouse standard.Exemple
DELETE
La suppression des lignes supplémentaires dans le format merge-on-read est également prise en charge par ClickHouse. Cette requête créera un nouveau snapshot avec des fichiers de suppression par position.Exemple
Évolution du schéma
ClickHouse vous permet d’ajouter, de supprimer, de modifier ou de renommer des colonnes à types simples (hors Tuple, Array et Map).Exemple
Compaction
ClickHouse prend en charge la compaction des tables Iceberg. Actuellement, elle peut fusionner les fichiers de suppression par position avec les fichiers de données tout en mettant à jour les métadonnées. Les ID et les timestamps des snapshots précédents restent inchangés, de sorte que la fonctionnalité de time travel peut toujours être utilisée avec les mêmes valeurs. Comment l’utiliser :Expiration des snapshots
Les tables Iceberg accumulent des snapshots à chaque opération INSERT, DELETE ou UPDATE. Au fil du temps, cela peut entraîner un grand nombre de snapshots et de fichiers de données associés. La commandeexpire_snapshots supprime les anciens snapshots et nettoie les fichiers de données qui ne sont plus référencés par aucun snapshot conservé.
Syntaxe :
min-snapshots-to-keep, max-snapshot-age-ms et surcharges par référence). Lorsque snapshot_ids est spécifié, la politique de rétention est ignorée et seuls les snapshots listés sont pris en compte pour l’expiration.
Arguments :
'timestamp'(positionnel) ouexpire_before = 'timestamp'— une chaîne DateTime (par ex.'2024-06-01 00:00:00') interprétée dans le fuseau horaire du serveur. Sert de garde-fou : les snapshots donttimestamp-msest égal ou postérieur à cette valeur sont protégés contre l’expiration, même si la politique de rétention les ferait autrement expirer. Peut être combiné avecsnapshot_ids; dans ce cas, les snapshots listés dont la date est égale ou postérieure à l’horodatage n’expirent pas.retention_period = '<duration>'— remplacehistory.expire.max-snapshot-age-msdéfini au niveau de la table, pour cet appel uniquement. Les snapshots plus anciens que cette durée (calculée à partir de maintenant) deviennent candidats à l’expiration. La valeur est une chaîne de durée composée d’une ou plusieurs paires{number}{unit}concaténées. Unités prises en charge :y(365 jours),w(7 jours),d(24 heures),h(60 minutes),m(60 secondes),s(1 seconde),ms(1 milliseconde). Les unités peuvent être combinées, par ex.'3d','12h','1d12h30m','500ms'.retain_last = N— remplacehistory.expire.min-snapshots-to-keepdéfini au niveau de la table, pour cet appel uniquement. Au moinsNsnapshots sont toujours conservés, quel que soit leur âge.snapshot_ids = [id1, id2, ...]— fait expirer exactement les ID de snapshot listés (à l’exception des snapshots référencés par le snapshot actuel, des branches ou des tags). Ce mode contourne entièrement la politique de rétention et ne peut pas être combiné avecretention_periodouretain_last.dry_run = 1— calcule ce qui expirerait et renvoie des métriques sans écrire de nouvelles métadonnées ni supprimer de fichiers.
retention_period et retain_last ne remplacent que les valeurs de rétention par défaut au niveau de la table. Les surcharges de rétention par référence (branche/tag) configurées dans les propriétés de la table Iceberg (par ex. refs.<branch>.min-snapshots-to-keep) ne sont jamais remplacées — elles s’appliquent toujours telles qu’elles sont spécifiées dans les métadonnées de la table.metric_name String, metric_value Int64) et contenant une ligne par métrique. Les noms des métriques suivent la spécification Iceberg :
La commande effectue les étapes suivantes :
- Évalue la politique de rétention (voir ci-dessous) afin de déterminer quels snapshots doivent être conservés
- Si un argument d’horodatage a été fourni, protège également tous les snapshots correspondant à cet horodatage ou plus récents
- Fait expirer les snapshots qui ne sont ni conservés par la politique ni protégés par le seuil d’horodatage
- Détermine quels fichiers sont associés exclusivement aux snapshots expirés
- En mode normal : génère de nouvelles métadonnées sans les snapshots expirés
- En mode normal : supprime physiquement les listes de manifests, les fichiers manifest et les fichiers de données devenus inaccessibles
- En mode
dry_run = 1: ignore les étapes 5 et 6 et renvoie uniquement les métriques calculées
Politique de rétention des snapshots
La commandeexpire_snapshots respecte la politique de rétention des snapshots d’Iceberg. La rétention se configure via les propriétés de table Iceberg et des remplacements par référence :
Chaque référence de snapshot (
refs dans les métadonnées Iceberg) peut remplacer ces valeurs au moyen de champs propres à la référence : min-snapshots-to-keep, max-snapshot-age-ms et max-ref-age-ms.
Évaluation de la rétention :
- Pour chaque branche (y compris
main) : la chaîne d’ancêtres est parcourue à partir de la tête de la branche. Les snapshots sont conservés tant qu’au moins l’une des conditions suivantes est vraie :- Le snapshot fait partie des
min-snapshots-to-keeppremiers snapshots de la chaîne - L’âge du snapshot ne dépasse pas
max-snapshot-age-ms(c.-à-d.now - timestamp-ms <= max-snapshot-age-ms)
- Le snapshot fait partie des
- Pour les tags : le snapshot tagué est conservé, sauf si le tag a dépassé sa valeur
max-ref-age-ms, auquel cas la référence du tag est supprimée - Les références autres que
maindont l’âge dépassemax-ref-age-mssont entièrement supprimées (la branchemainn’est jamais supprimée) - Les références orphelines qui pointent vers des snapshots inexistants sont supprimées avec un avertissement
- Le snapshot actuel est toujours conservé, quels que soient les paramètres de rétention
ALTER TABLE EXECUTE est requis. Il s’agit d’un privilège enfant de ALTER TABLE dans la hiérarchie du contrôle d’accès de ClickHouse. Vous pouvez l’accorder spécifiquement ou via le parent :
- Seules les tables Iceberg format version 2 sont prises en charge (les snapshots v1 ne garantissent pas
manifest-list, requis pour identifier en toute sécurité les fichiers à nettoyer) - Le snapshot actuel est toujours conservé, même s’il est antérieur à l’horodatage spécifié
- Nécessite que le paramètre
allow_insert_into_icebergsoit activé - Nécessite que le paramètre
allow_experimental_expire_snapshotssoit activé - Le mécanisme d’autorisation propre au catalog (authentification du catalogue REST, AWS Glue IAM, etc.) est appliqué indépendamment lorsque ClickHouse met à jour les métadonnées
Supprimer les fichiers orphelins
Les fichiers orphelins sont des fichiers présents dans le stockage qui ne sont référencés par aucun snapshot dans les métadonnées de la table Iceberg. Ils s’accumulent à la suite d’écritures ayant échoué, d’un nettoyage partiel après la compaction et d’opérations interrompues, ce qui entraîne une augmentation incontrôlée du stockage. La commanderemove_orphan_files identifie et supprime ces fichiers orphelins.
Syntaxe :
Exemples :
metric_name et metric_value, indiquant le nombre de fichiers supprimés (ou qui seraient supprimés en mode dry_run) par catégorie. Les catégories de fichiers sont déterminées au mieux à l’aide d’heuristiques basées sur les conventions de nommage des fichiers ; les fichiers qui ne correspondent à aucun motif spécifique sont comptabilisés par défaut dans deleted_data_files_count :
Paramètres :
- Nécessite Iceberg format version 2 (ou supérieure). Les tables version 1 sont rejetées, car elles ne contiennent pas de pointeurs
manifest-listdans les snapshots, nécessaires pour déterminer en toute sécurité l’ensemble des fichiers accessibles. L’exécution de la commande sur une table v1 renvoie une erreurBAD_ARGUMENTS. - Les paramètres
allow_insert_into_icebergetallow_iceberg_remove_orphan_filesdoivent tous deux être activés - Il est recommandé d’exécuter
expire_snapshotsavantremove_orphan_filesafin que les fichiers référencés uniquement par des snapshots expirés soient d’abord nettoyés - Utilisez
dry_run = 1pour prévisualiser les fichiers orphelins avant leur suppression - Le seuil
older_thanévite la suppression de fichiers issus d’écritures en cours — le seuil par défaut de 3 jours offre une marge de sécurité confortable