Skip to main content
Skip to main content
Edit this page

Iceberg Table Engine

danger

We recommend using the Iceberg Table Function for working with Iceberg data in ClickHouse. The Iceberg Table Function currently provides sufficient functionality, offering a partial read-only interface for Iceberg tables.

The Iceberg Table Engine is available but may have limitations. ClickHouse wasn't originally designed to support tables with externally changing schemas, which can affect the functionality of the Iceberg Table Engine. As a result, some features that work with regular tables may be unavailable or may not function correctly, especially when using the old analyzer.

For optimal compatibility, we suggest using the Iceberg Table Function while we continue to improve support for the Iceberg Table Engine.

This engine provides a read-only integration with existing Apache Iceberg tables in Amazon S3, Azure, HDFS and locally stored tables.

Create Table​

Note that the Iceberg table must already exist in the storage, this command does not take DDL parameters to create a new table.

Engine arguments​

Description of the arguments coincides with description of arguments in engines S3, AzureBlobStorage, HDFS and File correspondingly. format stands for the format of data files in the Iceberg table.

Engine parameters can be specified using Named Collections

Example​

Using named collections:

Aliases​

Table engine Iceberg is an alias to IcebergS3 now.

Schema Evolution​

At the moment, with the help of CH, you can read iceberg tables, the schema of which has changed over time. We currently support reading tables where columns have been added and removed, and their order has changed. You can also change a column where a value is required to one where NULL is allowed. Additionally, we support permitted type casting for simple types, namely:  

  • int -> long
  • float -> double
  • decimal(P, S) -> decimal(P', S) where P' > P.

Currently, it is not possible to change nested structures or the types of elements within arrays and maps.

To read a table where the schema has changed after its creation with dynamic schema inference, set allow_dynamic_metadata_for_data_lakes = true when creating the table.

Partition Pruning​

ClickHouse supports partition pruning during SELECT queries for Iceberg tables, which helps optimize query performance by skipping irrelevant data files. Now it works with only identity transforms and time-based transforms (hour, day, month, year). To enable partition pruning, set use_iceberg_partition_pruning = 1.

Time Travel​

ClickHouse supports time travel for Iceberg tables, allowing you to query historical data with a specific timestamp or snapshot ID.

Basic usage​

Note: You cannot specify both iceberg_timestamp_ms and iceberg_snapshot_id parameters in the same query.

Important considerations​

  • Snapshots are typically created when:

    • New data is written to the table
    • Some kind of data compaction is performed

  • Schema changes typically don't create snapshots - This leads to important behaviors when using time travel with tables that have undergone schema evolution.

Example scenarios​

All scenarios are written in Spark because CH doesn't support writing to Iceberg tables yet.

Scenario 1: Schema Changes Without New Snapshots​

Consider this sequence of operations:

Query results at different timestamps:

  • At ts1 & ts2: Only the original two columns appear
  • At ts3: All three columns appear, with NULL for the price of the first row

Scenario 2: Historical vs. Current Schema Differences​

A time travel query at a current moment might show a different schema than the current table:

This happens because ALTER TABLE doesn't create a new snapshot but for the current table Spark takes value of schema_id from the latest metadata file, not a snapshot.

Scenario 3: Historical vs. Current Schema Differences​

The second one is that while doing time travel you can't get state of table before any data was written to it:

In Clickhouse the behavior is consistent with Spark. You can mentally replace Spark Select queries with Clickhouse Select queries and it will work the same way.

Data cache​

Iceberg table engine and table function support data caching same as S3, AzureBlobStorage, HDFS storages. See here.

See also​