Matrice de compatibilité

Matrices de compatibilité complètes pour les intégrations ClickHouse avec les formats de table ouverts et les connexions aux catalogues de données.

Cette page présente des matrices de compatibilité complètes pour les intégrations lac de données de ClickHouse. Elle détaille les fonctionnalités disponibles pour chaque format de table ouvert, les catalogues auxquels ClickHouse peut se connecter, ainsi que les fonctionnalités prises en charge par chaque catalogue.

​

Prise en charge des formats de table ouverts

ClickHouse s’intègre à quatre formats de table ouverts : Apache Iceberg, Delta Lake, Apache Hudi et Apache Paimon. Sélectionnez un format ci-dessous pour consulter sa matrice de compatibilité.

Légende : ✅ Pris en charge | ⚠️ Partiel / Expérimental | ❌ Non pris en charge

Apache Iceberg

Fonctionnalité	Statut	Notes
Backends de stockage
AWS S3	✅	Via icebergS3() ou l’alias iceberg()
GCS	✅	Via icebergS3() ou l’alias iceberg()
Azure Blob Storage	✅	Via icebergAzure()
HDFS	⚠️	Via icebergHDFS(). Déprécié.
Système de fichiers local	✅	Via icebergLocal()
Méthodes d’accès
Fonction de table	✅	icebergS3() avec des variantes selon le backend
Moteur de table	✅	IcebergS3 avec des variantes selon le backend
Lectures distribuées sur cluster	✅	icebergS3Cluster, icebergAzureCluster, icebergHDFSCluster
Collections nommées	✅	Définir une collection nommée
Fonctionnalités de lecture
Prise en charge de la lecture	✅	Prise en charge complète de SELECT, avec toutes les fonctions ClickHouse SQL
Élagage des partitions	✅	Voir Élagage des partitions.
Partitionnement masqué	✅	Prise en charge du partitionnement basé sur les transformations Iceberg
Évolution du partitionnement	✅	Prise en charge de la lecture de tables dont les spécifications de partition évoluent au fil du temps
Évolution du schéma	✅	Ajout, suppression et réorganisation des colonnes. Voir Évolution du schéma.
Promotion / élargissement des types	✅	int → long, float → double, decimal(P,S) → decimal(P',S) où P’ > P. Voir Évolution du schéma.
Voyage dans le temps / instantanés	✅	Via les paramètres iceberg_timestamp_ms ou iceberg_snapshot_id. Voir Voyage dans le temps.
Suppressions par position	✅	Voir Traitement des lignes supprimées.
Suppressions par égalité	✅	Moteur de table uniquement, à partir de la v25.8+. Voir Traitement des lignes supprimées.
Merge-on-read	⚠️	Expérimental. Pris en charge pour les opérations de suppression.
Versions de format	⚠️	v1 et v2 pris en charge. V3 n’est pas pris en charge.
Statistiques de colonnes	✅
Filtres Bloom / fichiers puffin	❌	Les index Bloom filter dans les fichiers puffin ne sont pas pris en charge
Colonnes virtuelles	✅	_path, _file, _size, _time, _etag. Voir Colonnes virtuelles.
Fonctionnalités d’écriture
Création de table	✅	Expérimental. Nécessite allow_insert_into_iceberg = 1. À partir de la v25.7+. Voir Créer une table.
INSERT	✅	Bêta à partir de la version 26.2. Nécessite allow_insert_into_iceberg = 1. Voir Insertion de données.
DELETE	✅	Expérimental. Nécessite allow_insert_into_iceberg = 1. Via ALTER TABLE ... DELETE WHERE. Voir Suppression de données.
ALTER TABLE (changements de schéma)	✅	Expérimental. Nécessite allow_insert_into_iceberg = 1. Ajouter, supprimer, modifier et renommer des colonnes. Voir Évolution du schéma.
Compaction	⚠️	Expérimental. Nécessite allow_experimental_iceberg_compaction = 1. Fusionne les fichiers de suppression positionnelle dans les fichiers de données. Voir Compaction. Les autres opérations de compaction d’Iceberg ne sont pas prises en charge.
UPDATE / MERGE	❌	Non pris en charge. Voir Compaction.
Copy-on-write	❌	Non pris en charge
Expire snapshots	❌	Non pris en charge
Remove orphan files	❌	Non pris en charge
Writing partitions	✅	Pris en charge.
Altering partitions	❌	La modification du schéma de partitionnement depuis ClickHouse n’est pas prise en charge. ClickHouse peut écrire dans des tables Iceberg dont le partitionnement a évolué.
Métadonnées
Branching and tagging	❌	Les références de branches/tags Iceberg ne sont pas prises en charge
Metadata file resolution	✅	Prise en charge de la résolution des fichiers de métadonnées via des catalogs, un simple parcours de répertoire, l’utilisation de ‘version-hint’ et un chemin spécifique. Configurable via iceberg_metadata_file_path et iceberg_metadata_table_uuid. Voir Résolution des fichiers de métadonnées.
Data caching	✅	Même mécanisme que pour les moteurs de stockage S3/Azure/HDFS. Voir Cache de données.
Metadata caching	✅	Les fichiers manifest et les fichiers de métadonnées sont mis en cache en mémoire. Activé par défaut via use_iceberg_metadata_files_cache. Voir Cache de métadonnées.

Delta Lake

À partir de la version 25.6, ClickHouse lit les tables Delta Lake à l’aide du noyau Rust de Delta Lake, ce qui offre une prise en charge plus étendue des fonctionnalités ; toutefois, des problèmes connus surviennent lors de l’accès aux données dans Azure Blob Storage. C’est pourquoi le noyau est désactivé lors de la lecture de données sur Azure Blob Storage. Nous indiquons ci-dessous quelles fonctionnalités nécessitent ce noyau.

Fonctionnalité	Statut	Notes
Backends de stockage
AWS S3	✅	Via deltaLake() ou deltaLakeS3()
GCS	✅	Via deltaLake() ou deltaLakeS3()
Azure Blob Storage	✅	Via deltaLakeAzure()
HDFS	❌	Non pris en charge
Système de fichiers local	✅	Via deltaLakeLocal()
Méthodes d’accès
Fonction de table	✅	deltaLake() avec des variantes selon le backend
Moteur de table	✅	DeltaLake
Lectures distribuées en cluster	✅	deltaLakeCluster, deltaLakeAzureCluster
Collections nommées	✅	Collection nommée
Fonctionnalités de lecture
Prise en charge de la lecture	✅	Prise en charge complète de SELECT avec toutes les fonctions ClickHouse SQL
Élagage des partitions	✅	Nécessite Delta Kernel.
Évolution du schéma	✅	Nécessite Delta Kernel.
Time travel	✅	Nécessite Delta Kernel.
Vecteurs de suppression	✅
Mappage des colonnes	✅
Flux de données modifiées	✅	Nécessite Delta Kernel.
Colonnes virtuelles	✅	_path, _file, _size, _time, _etag. Voir Colonnes virtuelles.
Fonctionnalités d’écriture
INSERT	✅	Experimental. Nécessite allow_experimental_delta_lake_writes = 1. Voir moteur DeltaLake. Nécessite Delta Kernel.
DELETE / UPDATE / MERGE	❌	Non pris en charge
CREATE table vide	❌	La création d’une nouvelle table Delta Lake vide n’est pas prise en charge. L’opération CREATE TABLE suppose l’existence d’une table Delta Lake sur le stockage d’objets.
Mise en cache
Mise en cache des données	✅	Même mécanisme que pour les moteurs de stockage S3/Azure/HDFS. Voir Cache de données.

Apache Hudi

Fonctionnalité	Statut	Notes
Backends de stockage
AWS S3	✅	Via hudi()
GCS	✅	Via hudi()
Azure Blob Storage	❌	Non pris en charge
HDFS	❌	Non pris en charge
Système de fichiers local	❌	Non pris en charge
Méthodes d’accès
Fonction de table	✅	hudi()
Moteur de table	✅	Hudi
Lectures distribuées en cluster	✅	hudiCluster (S3 uniquement)
Collections nommées	✅	Arguments de Hudi
Fonctionnalités de lecture
Prise en charge en lecture	✅	Prise en charge complète de SELECT avec toutes les fonctions ClickHouse SQL
Évolution du schéma	❌	Non pris en charge
Time travel	❌	Non pris en charge
Colonnes virtuelles	✅	_path, _file, _size, _time, _etag. Voir Colonnes virtuelles.
Fonctionnalités d’écriture
INSERT / DELETE / UPDATE	❌	Intégration en lecture seule
Mise en cache
Mise en cache des données	❌	Non pris en charge

Apache Paimon

Fonctionnalité	Statut	Notes
Backends de stockage
S3	✅	Expérimental. Via paimon() ou paimonS3()
GCS	✅	Expérimental. Via paimon() ou paimonS3()
Azure Blob Storage	✅	Expérimental. Via paimonAzure()
HDFS	⚠️	Expérimental. Via paimonHDFS(). Obsolète.
Système de fichiers local	✅	Expérimental. Via paimonLocal()
Méthodes d’accès
Fonction de table	✅	Expérimental. paimon() avec des variantes selon le backend
Moteur de table	❌	Aucun moteur de table dédié
Lectures distribuées en cluster	✅	Expérimental. paimonS3Cluster, paimonAzureCluster, paimonHDFSCluster
Collections nommées	✅	Expérimental. Définir une collection nommée
Fonctionnalités de lecture
Prise en charge en lecture	✅	Expérimental. Prise en charge complète de SELECT avec toutes les fonctions ClickHouse SQL
Évolution du schéma	❌	Non pris en charge
Voyage dans le temps	❌	Non pris en charge
Colonnes virtuelles	✅	Expérimental. _path, _file, _size, _time, _etag. Voir Colonnes virtuelles.
Fonctionnalités d’écriture
INSERT / DELETE / UPDATE	❌	Intégration en lecture seule
Mise en cache
Cache des données	❌	Non pris en charge

​

Prise en charge des catalogues

ClickHouse peut se connecter à des catalogues de données externes à l’aide du moteur de base de données DataLakeCatalog, qui expose le catalogue comme une base de données ClickHouse. Les tables enregistrées dans le catalogue apparaissent automatiquement et peuvent être interrogées avec du SQL standard.

Les catalogues suivants sont actuellement pris en charge. Consultez le guide de référence de chaque catalogue pour les instructions de configuration complètes.

Catalogue	Formats	Lecture	Créer une table	INSERT	Guide de référence
AWS Glue Catalog	Iceberg	✅ Bêta	❌	❌	Guide du Glue catalog
BigLake Metastore	Iceberg	✅ Bêta	❌	❌	Guide de BigLake Metastore
Databricks Unity Catalog	Delta, Iceberg	✅ Bêta	✅ Bêta	✅ Bêta	Guide de Unity Catalog
Iceberg REST	Iceberg	✅ Bêta	❌	❌	Guide du REST catalog
Lakekeeper	Iceberg	✅ Bêta	❌	❌	Guide du catalogue Lakekeeper
Project Nessie	Iceberg	✅ Expérimental	❌	❌	Guide du catalogue Nessie
Microsoft OneLake	Iceberg	✅ Bêta	✅ Bêta	✅ Bêta	Guide du catalogue OneLake

Toutes les intégrations de catalogues exigent actuellement l’activation d’un paramètre expérimental ou bêta. À l’exception de Microsoft OneLake et de Databricks Unity Catalog, tous les catalogues offrent un accès en lecture seule — les tables peuvent être interrogées, mais il n’est pas possible de les créer ni d’y écrire des données via la connexion au catalogue. Pour charger des données depuis un catalogue dans ClickHouse afin d’accélérer l’analytics, utilisez INSERT INTO SELECT comme indiqué dans le guide d’accélération de l’analytics. Pour réécrire des données dans des formats de table ouverts, créez des tables Iceberg autonomes comme indiqué dans le guide d’écriture des données.