構文
引数
引数の説明は、それぞれテーブル関数s3、azureBlobStorage、HDFS、file の引数の説明と同様です。
format は Iceberg テーブル内のデータファイルのフォーマットを表します。
icebergS3 では、ClickHouse Cloud でロールベースのアクセスを行うための role_arn を渡すために、オプションの extra_credentials パラメータを使用できます。設定手順については、Secure S3 を参照してください。
戻り値
指定した Iceberg テーブル内のデータを読み取るための、指定した構造のテーブル。例
named collection を定義する
URL と認証情報を保存するための named collection を設定する例を以下に示します。データカタログの使用
Iceberg テーブルは、REST Catalog、AWS Glue Data Catalog、Unity Catalog など、さまざまなデータカタログと組み合わせて使用することもできます。 これらを使用するには、IcebergS3 エンジンでテーブルを作成し、必要な設定を指定します。
たとえば、MinIO ストレージで REST Catalog を使用する場合は次のとおりです。
スキーマ進化
現時点では、CH を使用して、時間の経過とともにスキーマが変更された Iceberg テーブルを読み取ることができます。現在は、カラムの追加や削除、カラム順の変更が行われたテーブルの読み取りをサポートしています。また、値が必須のカラムを、NULL を許可するカラムに変更することもできます。さらに、単純型については、許可された型キャストとして次の変換をサポートしています。- int -> long
- float -> double
- decimal(P, S) -> decimal(P’, S) where P’ > P.
パーティションプルーニング
ClickHouse は、Iceberg テーブルに対する SELECT クエリでパーティションプルーニングをサポートしており、無関係なデータファイルをスキップすることでクエリ性能を最適化できます。パーティションプルーニングを有効にするには、use_iceberg_partition_pruning = 1 を設定します。Iceberg のパーティションプルーニングの詳細については、https://iceberg.apache.org/spec/#partitioning を参照してください
タイムトラベル
ClickHouse は Iceberg テーブルでのタイムトラベルをサポートしており、特定のタイムスタンプまたはスナップショット ID を指定して過去のデータをクエリできます。削除された行を含むテーブルの処理
ClickHouse は、position deletes および equality deletes を持つ Iceberg テーブルをサポートしています。equality deletes は v25.8 からサポートされています。 ClickHouse は 削除ベクター (v3 で導入) の読み取りもサポートしています。このサポートは読み取り専用です。ClickHouse は削除ベクターの書き込み、更新、コンパクションを行わず、Iceberg フォーマットバージョン 3 のテーブルではALTER TABLE ... DELETE および ALTER TABLE ... UPDATE はサポートされていません。
基本的な使い方
iceberg_timestamp_ms と iceberg_snapshot_id の両方のパラメータを指定することはできません。
重要な考慮事項
- スナップショット は通常、次のタイミングで作成されます:
- 新しいデータがテーブルに書き込まれたとき
- 何らかのデータ コンパクション が実行されたとき
- スキーマの変更では通常、スナップショットは作成されません - このため、スキーマ進化を経たテーブルで タイムトラベル を使用する際には、重要な挙動が生じます。
シナリオ例
これらのシナリオでは、外部の Iceberg writer によるスキーマ変更を Spark を使用して説明します。シナリオ 1: 新しいスナップショットがない場合のスキーマ変更
次の一連の操作を考えてみましょう。- ts1 & ts2: 元の 2 つのカラムのみが表示される
- ts3: 3 つのカラムがすべて表示され、1 行目の
priceは NULL になる
シナリオ 2: 履歴と現在のスキーマの違い
現時点でタイムトラベルクエリを実行すると、現在のテーブルとは異なるスキーマが表示されることがあります:ALTER TABLE では新しい スナップショット は作成されず、現在のテーブルでは Spark が スナップショット ではなく最新のメタデータファイルから schema_id の値を取得するために発生します。
シナリオ3: 履歴と現在のスキーマの違い
2つ目は、タイムトラベルを使っても、そのテーブルにまだデータが一度も書き込まれていなかった時点の状態は取得できないことです:メタデータファイルの特定
ClickHouseでicebergテーブル関数を使用する場合、システムはIcebergテーブルの構造を記述した適切なmetadata.jsonファイルを特定する必要があります。この特定プロセスは次のように機能します。
候補検索 (優先順)
- 直接パス指定:
*
iceberg_metadata_file_pathを設定すると、システムはこの正確なパスを Iceberg テーブルのディレクトリパスと組み合わせて使用します。
- この設定が指定されている場合、ほかのすべての解決用設定は無視されます。
-
テーブル UUID の照合:
*
iceberg_metadata_table_uuidが指定されている場合、システムは次のように動作します:metadataディレクトリ内の.metadata.jsonファイルのみを対象にします- 指定した UUID と一致する
table-uuidフィールドを含むファイルに絞り込みます (大文字と小文字は区別されません)
-
デフォルト検索:
*上記のいずれの設定も指定されていない場合、
metadataディレクトリ内のすべての.metadata.jsonファイルが候補になります
最新のファイルを選択する
上記のルールを使用して候補ファイルを特定した後、システムはその中から最新のものを判定します。-
iceberg_recent_metadata_file_by_last_updated_ms_fieldが有効な場合: -
last-updated-msの値が最も大きいファイルが選択されます - それ以外の場合:
- バージョン番号が最も大きいファイルが選択されます
-
(バージョンは、
V.metadata.jsonまたはV-uuid.metadata.json形式のファイル名ではVとして表されます)
iceberg テーブル関数 は S3 に保存されたファイルを Iceberg テーブルとして直接解釈するため、これらの解決ルールを理解しておくことが重要です。
メタデータキャッシュ
Iceberg テーブルエンジン と テーブル関数 は、マニフェストファイル、マニフェストリスト、metadata json の情報を保持するメタデータキャッシュをサポートしています。このキャッシュはメモリに保存されます。この機能は設定 use_iceberg_metadata_files_cache で制御されており、デフォルトで有効になっています。
別名
テーブル関数iceberg は現在、icebergS3 の別名です。
仮想カラム
_path— ファイルのパス。型:LowCardinality(String)._file— ファイル名。型:LowCardinality(String)._size— ファイルサイズ (バイト単位) 。型:Nullable(UInt64). ファイルサイズが不明な場合、値はNULLです。_time— ファイルの最終更新時刻。型:Nullable(DateTime). 時刻が不明な場合、値はNULLです。_etag— ファイルの etag。型:LowCardinality(String). etag が不明な場合、値はNULLです。
Icebergテーブルへの書き込み
バージョン25.7以降、ClickHouse は書き込み可能なストレージバックエンド上の Iceberg テーブルの変更をサポートしています。 Iceberg テーブルを変更または保守する前に、allow_insert_into_iceberg 設定を有効にしてください。一部の操作には、以下で説明する追加の設定が必要です。
Icebergテーブルの作成
書き込み可能なバックエンドに新しいスタンドアロンのIcebergテーブルを作成するには、Icebergテーブルエンジンを使用し、スキーマを明示的に指定します。 書き込みでは、Parquet、Avro、ORC など、Iceberg仕様で定義されているすべてのデータフォーマットをサポートしています。例
iceberg_use_version_hint 設定を有効にします。
metadata.json ファイルを圧縮する場合は、iceberg_metadata_compression_method 設定でcodec名を指定します。
INSERT
新しいテーブルを作成したら、通常の ClickHouse 構文を使用してデータを挿入できます。例
DELETE
ClickHouse は、merge-on-read フォーマットで余分な行を削除することにも対応しています。 このクエリは、position delete ファイル を含む新しいスナップショットを作成します。例
スキーマ進化
ClickHouse では、単純型 (Tuple、Array、Map 以外) のカラムを簡単に追加、削除、変更、または名前変更できます。例
コンパクション
ClickHouse は Iceberg テーブルのコンパクションをサポートしています。現在は、メタデータを更新しながら、position delete ファイル を data files にマージできます。以前のスナップショット ID とタイムスタンプは変更されないため、タイムトラベル機能も引き続き同じ値で利用できます。 使用方法:スナップショットの期限切れ処理
Iceberg テーブルでは、INSERT、DELETE、または UPDATE を実行するたびにスナップショットが蓄積されます。時間の経過とともに、これにより大量のスナップショットと、それに関連するデータファイルが生じる可能性があります。expire_snapshots コマンドは、古いスナップショットを削除し、保持されているどのスナップショットからも参照されなくなったデータファイルをクリーンアップします。
構文:
min-snapshots-to-keep、max-snapshot-age-ms、および ref ごとのオーバーライド) によって決まります。snapshot_ids を指定すると、保持ポリシーは適用されず、リストされたスナップショットだけが削除対象として扱われます。
引数:
'timestamp'(位置引数) またはexpire_before = 'timestamp'— サーバーのタイムゾーンで解釈される日時文字列 (例:'2024-06-01 00:00:00') 。安全弁として機能し、timestamp-msがこの値以上のスナップショットは、保持ポリシーでは削除対象になる場合でも保護されます。snapshot_idsと組み合わせることもでき、その場合はリストされたスナップショットのうち、指定した timestamp と同時刻以降のものは削除されません。retention_period = '<duration>'— この呼び出しに限り、テーブルレベルのhistory.expire.max-snapshot-age-msを上書きします。この期間より古いスナップショット (現在時刻を基準に判定) が、削除候補になります。値は、1 つ以上の{number}{unit}の組を連結した期間文字列です。サポートされる単位:y(365 日) 、w(7 日) 、d(24 時間) 、h(60 分) 、m(60 秒) 、s(1 秒) 、ms(1 ミリ秒) 。単位は組み合わせ可能で、例:'3d'、'12h'、'1d12h30m'、'500ms'。retain_last = N— この呼び出しに限り、テーブルレベルのhistory.expire.min-snapshots-to-keepを上書きします。少なくともN個のスナップショットは、古さに関係なく常に保持されます。snapshot_ids = [id1, id2, ...]— リストされたスナップショット ID のみを削除対象にします (現在のスナップショット、ブランチ、またはタグから参照されているスナップショットを除く) 。このモードでは保持ポリシーは完全に無視され、retention_periodまたはretain_lastとは組み合わせられません。dry_run = 1— 何が削除対象になるかを計算し、新しいメタデータの書き込みやファイル削除を行わずにメトリクスを返します。
retention_period と retain_last が上書きするのは、テーブルレベルの保持のデフォルト値だけです。Iceberg テーブルプロパティで設定された ref ごとの保持オーバーライド (例: refs.<branch>.min-snapshots-to-keep) は上書きされず、常にテーブルメタデータで指定されたとおりに適用されます。metric_name String、metric_value Int64) を持つテーブルを返します。このテーブルには、メトリクスごとに 1 行が含まれます。メトリクス名は Iceberg spec に従います。
このコマンドは次の手順を実行します。
- 保持ポリシー (以下を参照) を評価し、保持する必要があるスナップショットを特定します
- タイムスタンプ引数が指定されている場合は、そのタイムスタンプ以降のすべてのスナップショットも追加で保護します
- ポリシーによって保持されず、タイムスタンプによる保護も受けていないスナップショットを期限切れにします
- 期限切れになったスナップショットにのみ関連付けられているファイルを特定します
- 通常モード: 期限切れになったスナップショットを除外した新しいメタデータを生成します
- 通常モード: 到達不能になったマニフェストリスト、マニフェストファイル、データファイルを物理的に削除します
dry_run = 1モード: 手順 5 と 6 をスキップし、計算されたメトリクスのみを返します
スナップショット保持ポリシー
expire_snapshots コマンドは、Iceberg snapshot retention policy に従います。保持設定は、Iceberg テーブルのプロパティと参照ごとのオーバーライドで構成します。
各スナップショット参照 (Iceberg メタデータ内の
refs) では、参照ごとのフィールド min-snapshots-to-keep、max-snapshot-age-ms、max-ref-age-ms を使ってこれらの値を上書きできます。
保持の評価:
- 各ブランチ (
mainを含む) について: ブランチの先頭から祖先チェーンをたどります。次のいずれかの条件を満たす間、スナップショットは保持されます。- そのスナップショットが、チェーン内の先頭
min-snapshots-to-keep個に含まれている - そのスナップショットの経過時間が
max-snapshot-age-ms以内である (つまりnow - timestamp-ms <= max-snapshot-age-ms)
- そのスナップショットが、チェーン内の先頭
- タグについて: タグ付けされたスナップショットは、タグが
max-ref-age-msを超過しない限り保持されます。超過した場合は、タグ参照が削除されます main以外の参照で、経過時間がmax-ref-age-msを超えるものは完全に削除されます (mainブランチは削除されません)- 存在しないスナップショットを指す孤立した参照は、警告を出して削除されます
- 現在のスナップショットは常に保持されます。保持設定に関係なく保持されます
ALTER TABLE EXECUTE 権限が必要です。これは ClickHouse のアクセス制御階層では ALTER TABLE の子権限です。個別に付与することも、親権限を通じて付与することもできます。
- サポートされるのは Iceberg format version 2 のテーブルのみです (v1 の snapshot では
manifest-listが保証されず、クリーンアップ対象のファイルを安全に特定するためにこれが必要です) - 指定した timestamp より古い場合でも、現在の snapshot は常に保持されます
allow_insert_into_iceberg設定を有効にする必要がありますallow_experimental_expire_snapshots設定を有効にする必要があります- ClickHouse がメタデータを更新する際は、カタログ自体の認可 (REST カタログ認証、AWS Glue IAM など) が別途適用されます
孤立ファイルの削除
孤立ファイルとは、ストレージ上に存在するものの、Iceberg テーブルのメタデータ内にあるどのスナップショットからも参照されていないファイルのことです。これらは、書き込みの失敗、コンパクション 後の不完全なクリーンアップ、操作の中断などによって蓄積し、ストレージ使用量が際限なく増加する原因になります。remove_orphan_files コマンドは、こうした孤立ファイルを特定して削除します。
構文:
例:
metric_name と metric_value のカラムを持つテーブルを返します。ファイルカテゴリは、ファイル名の命名規則に基づくベストエフォートのヒューリスティクスで分類されます。特定のパターンに一致しないファイルは、デフォルトで deleted_data_files_count に分類されます。
設定:
- Iceberg format version 2 (またはそれ以上) が必要です。 version 1 のテーブルは、到達可能なファイル集合を安全に判定するために必要な、snapshot 内の
manifest-listポインタを持たないため拒否されます。v1 テーブルでこのコマンドを実行すると、BAD_ARGUMENTSエラーが返されます。 allow_insert_into_icebergとallow_iceberg_remove_orphan_filesの両方の設定を有効にする必要があります- 期限切れの snapshot だけが参照しているファイルを先にクリーンアップできるよう、
remove_orphan_filesの前にexpire_snapshotsを実行することを推奨します - 削除前に孤立ファイルを確認するには、
dry_run = 1を使用します older_thanのしきい値は、進行中の書き込みに由来するファイルが削除されるのを防ぎます。デフォルトの 3 日というしきい値には、十分な安全マージンがあります