構文
引数
s3、azureBlobStorage、HDFS、file の引数の説明と同様です。
format は Iceberg テーブル内のデータファイルのフォーマットを表します。
icebergS3 では、ClickHouse Cloud でロールベースのアクセスを行うための role_arn を渡すために、オプションの extra_credentials パラメータを使用できます。設定手順については、Secure S3 を参照してください。
戻り値
例
named collection を定義する
データカタログの使用
IcebergS3 エンジンでテーブルを作成し、必要な設定を指定します。
たとえば、MinIO ストレージで REST Catalog を使用する場合は次のとおりです。
スキーマ進化
- int -> long
- float -> double
- decimal(P, S) -> decimal(P’, S) where P’ > P.
パーティションプルーニング
use_iceberg_partition_pruning = 1 を設定します。Iceberg のパーティションプルーニングの詳細については、https://iceberg.apache.org/spec/#partitioning を参照してください
タイムトラベル
削除された行を含むテーブルの処理
- Equality deletes
- Deletion vectors (v3 で導入)
基本的な使い方
iceberg_timestamp_ms と iceberg_snapshot_id の両方のパラメータを指定することはできません。
重要な考慮事項
- スナップショット は通常、次のタイミングで作成されます:
- 新しいデータがテーブルに書き込まれたとき
- 何らかのデータ コンパクション が実行されたとき
- スキーマの変更では通常、スナップショットは作成されません - このため、スキーマ進化を経たテーブルで タイムトラベル を使用する際には、重要な挙動が生じます。
シナリオ例
シナリオ 1: 新しいスナップショットがない場合のスキーマ変更
- ts1 & ts2: 元の 2 つのカラムのみが表示される
- ts3: 3 つのカラムがすべて表示され、1 行目の
priceは NULL になる
シナリオ 2: 履歴と現在のスキーマの違い
ALTER TABLE では新しい スナップショット は作成されず、現在のテーブルでは Spark が スナップショット ではなく最新のメタデータファイルから schema_id の値を取得するために発生します。
シナリオ3: 過去と現在のスキーマの違い
メタデータファイルの特定
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テーブルへの書き込み
Icebergテーブルの作成
例
iceberg_use_version_hint 設定を有効にします。
metadata.json ファイルを圧縮する場合は、iceberg_metadata_compression_method 設定でcodec名を指定します。
INSERT
例
DELETE
例
スキーマ進化
例
コンパクション
スナップショットの期限切れ処理
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 など) が別途適用されます
孤立ファイルの削除
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 日というしきい値には、十分な安全マージンがあります