Skip to main content
このセクションでは、dbt-clickhouse で利用可能なすべてのマテリアライゼーション (実験的な機能を含む) について説明します。

一般的なマテリアライゼーション設定

次の表は、利用可能なマテリアライゼーションの一部で共通して使用される設定を示しています。一般的な dbt モデル設定の詳細については、dbt documentationを参照してください。

サポートされているテーブルエンジン

: materialized view では、すべての *MergeTree エンジンがサポートされています。

実験的にサポートされているテーブルエンジン

上記のいずれかのエンジンを使用して dbt から ClickHouse に接続する際に問題が発生した場合は、 こちらから issue を報告してください。

モデル設定に関する注意

ClickHouse には、「設定」にいくつかの種類やレベルがあります。上記のモデル構成では、そのうち 2 種類を 設定できます。settings は、CREATE TABLE/VIEW 型の DDL ステートメントで使用される SETTINGS 句を指し、一般に特定の ClickHouse テーブルエンジン固有の設定を意味します。新しい query_settings は、モデルのマテリアライゼーションで使用される INSERT および DELETE クエリに SETTINGS 句を追加するためのものです ( 増分マテリアライゼーションを含む) 。 ClickHouse には何百もの設定があり、どれが「テーブル」設定で、どれが「ユーザー」 設定なのかが必ずしも明確ではありません (ただし後者は、一般に system.settings テーブルで確認できます) 。基本的にはデフォルト値の使用が推奨されており、これらのプロパティを使用する場合は 十分に調査と検証を行ってください。

カラム設定

注: 以下のカラム設定オプションを利用するには、モデルコントラクト が適用されている必要があります。

スキーマ設定の例

複雑な型の追加

dbt は、モデルの作成に使用される SQL を分析して、各カラムのデータ型を自動的に判定します。ただし、場合によってはこの処理でデータ型を正確に判定できず、contract の data_type プロパティで指定した型と競合することがあります。これを回避するには、モデルの SQL で CAST() 関数を使用して、意図した型を明示的に定義することを推奨します。たとえば、次のようになります。

マテリアライゼーション: ビュー

dbtのモデルは、ClickHouseビューとして作成でき、 次の構文で設定できます。 プロジェクトファイル (dbt_project.yml) :
または、設定ブロック (models/<model_name>.sql) :

マテリアライゼーション: テーブル

dbtモデルは ClickHouseテーブル として作成でき、 次の構文で設定できます。 プロジェクトファイル (dbt_project.yml):
または config ブロック (models/<model_name>.sql) :

データスキッピングインデックス

indexes 設定を使用すると、table マテリアライゼーションにデータスキッピングインデックスを追加できます:

プロジェクション

projections 設定を使用すると、table および distributed_table マテリアライゼーションにプロジェクションを追加できます。
: 分散テーブルでは、プロジェクションは分散プロキシテーブルではなく、_local テーブルに適用されます。

マテリアライゼーション: インクリメンタル

テーブルモデルは、dbt の実行のたびに再構築されます。これは、結果セットが大きい場合や変換が複雑な場合には現実的ではなく、コストが非常に高くなる可能性があります。この課題に対処し、ビルド時間を短縮するために、dbt モデルは インクリメンタル な ClickHouse テーブルとして作成でき、次の構文で設定します。 dbt_project.yml でのモデル定義:
または、models/<model_name>.sql の config ブロック:

設定

このマテリアライゼーションタイプ固有の設定を以下に示します。

インクリメンタルモデルの戦略

dbt-clickhouse は、3種類のインクリメンタルモデル戦略をサポートしています。

デフォルト (レガシー) 戦略

ClickHouse では従来、更新と削除のサポートは非同期の「mutation」による限定的なものしかありませんでした。 期待される dbt の動作を再現するため、 dbt-clickhouse はデフォルトで、影響を受けていない (削除も変更もされていない) 既存の レコードをすべて含み、さらに新規または更新されたレコードを加えた新しい一時テーブルを作成し、 その後、この一時テーブルを既存の インクリメンタル model リレーション とスワップまたは EXCHANGE します。これは、処理の完了前に何らかの 問題が発生した場合でも元の リレーション を保持できる唯一の戦略です。ただし、元のテーブル全体をコピーする必要があるため、 実行コストが高く、処理にも時間がかかる可能性があります。

Delete+Insert 戦略

ClickHouse はバージョン 22.8 で「論理削除」を実験的機能として追加しました。論理削除は、 ALTER TABLE … DELETE 操作よりも大幅に高速です。これは、ClickHouse のデータパーツを書き換える必要がないためです。インクリメンタル戦略 delete+insert は論理削除を利用して、 「legacy」戦略よりも大幅に高い性能を発揮するインクリメンタルマテリアライゼーションを実装します。ただし、この戦略を使用する際には重要な 注意点があります:
  • 論理削除を使用するには、設定 allow_experimental_lightweight_delete=1 を使って ClickHouse server で有効化するか、 profile で use_lw_deletes=true を設定する必要があります (これにより dbt のセッションでその設定が有効になります)
  • 論理削除は現在では本番利用可能ですが、23.3 より前の ClickHouse バージョンでは性能面やその他の問題が 発生する可能性があります。
  • この戦略は、影響を受ける table/リレーション に対して中間テーブルや一時テーブルを作成せずに直接動作するため、処理中に問題が発生した場合、 インクリメンタル model の データが無効な状態になる可能性があります
  • 論理削除を使用する場合、dbt-clickhouse は設定 allow_nondeterministic_mutations を有効にします。ごく まれに、非決定論的な incremental_predicates を使用すると、 更新または削除された項目 (および ClickHouse logs 内の関連する log messages) で race condition が発生する可能性があります。 一貫した結果を確実に得るには、 incremental predicates には、インクリメンタル materialization 中に変更されないデータに対するサブクエリだけを含めるようにしてください。

Microbatch 戦略 (dbt-core >= 1.9 が必要)

インクリメンタル戦略 microbatch は dbt-core 1.9 で導入された機能で、大規模な 時系列データの変換を効率的に処理できるよう設計されています。dbt-clickhouse では、既存の delete_insert インクリメンタル戦略をベースに、event_timebatch_size のモデル設定に基づいて、インクリメントをあらかじめ定義された時系列バッチに分割して処理します。 大規模な変換の処理に加えて、microbatch には次のような利点があります。 microbatch の詳細な使い方については、公式ドキュメントを参照してください。
利用可能な Microbatch 設定

Append 戦略

この戦略は、以前のバージョンの dbt-clickhouse における inserts_only 設定の代わりとなるものです。この方式では、既存のリレーションに新しい行を単純に追加します。 そのため、重複した行は排除されず、一時テーブルや中間テーブルも作成されません。データ内で重複が許容されている場合、またはインクリメンタルクエリの WHERE 句/フィルタで除外される場合は、これが最も高速な方式です。

insert_overwrite 戦略 (実験的)

[IMPORTANT] 現在、insert_overwrite 戦略は分散マテリアライゼーションでは完全には機能しません。
次の手順を実行します。
  1. incremental model の リレーション と同じ structure を持つ staging (一時) table を作成します: CREATE TABLE <staging> AS <target>.
  2. 新しいレコード (SELECT によって生成されたもの) のみを staging table に insert します。
  3. 新しいパーティション (staging table に存在するもの) のみをターゲットテーブルに置き換えます。
このアプローチには、次の利点があります。
  • テーブル全体をコピーしないため、デフォルトの戦略より高速です。
  • INSERT 操作が正常に完了するまで元のテーブルを変更しないため、他の戦略より安全です。途中で障害が発生した場合でも、元のテーブルは変更されません。
  • データエンジニアリングにおける「パーティション不変性」のベストプラクティスを実現します。これにより、増分処理、並列データ処理、ロールバックなどが簡単になります。
この戦略を使用するには、model configuration で partition_by を設定する必要があります。model config のそのほかの戦略固有の parameter はすべて無視されます。

マテリアライゼーション: materialized_view

materialized_view マテリアライゼーションは、挿入トリガーとして機能する ClickHouse の materialized view を作成し、ソーステーブルからターゲットテーブルへ新しい行を自動的に変換して挿入します。これは、dbt-clickhouse で利用できるマテリアライゼーションの中でも特に強力なものの 1 つです。 このマテリアライゼーションは内容が多岐にわたるため、専用のページを用意しています。完全なドキュメントについては、**Materialized Views ガイド**をご覧ください。

マテリアライゼーション: Dictionary (実験的)

ClickHouse Dictionary の マテリアライゼーションを実装する方法の 例については、 https://github.com/ClickHouse/dbt-clickhouse/blob/main/tests/integration/adapter/dictionary/test&#95;dictionary.py のテストを参照してください

マテリアライゼーション: distributed_table (実験的)

分散テーブルは、次の手順で作成されます:
  1. 適切な構造を取得するためのSQLクエリを使って一時ビューを作成する
  2. ビューに基づいて空のローカルテーブルを作成する
  3. ローカルテーブルに基づいて分散テーブルを作成する。
  4. データは分散テーブルに挿入されるため、重複することなく各分片に分散される。
注:
  • dbt-clickhouse のクエリには現在、設定 insert_distributed_sync = 1 が自動的に含まれており、これにより 下流のインクリメンタル マテリアライゼーション操作が正しく実行されることが保証されます。そのため、一部の分散テーブルへの挿入が 想定より遅くなる可能性があります。

分散テーブルモデルの例

生成された移行

設定

このマテリアライゼーション種別に固有の設定を以下に示します。

materialization: distributed_incremental (実験的)

分散テーブルと同じ考え方に基づく増分モデルですが、主な難しさは、すべての増分 戦略を正しく処理することにあります。
  1. The Append Strategy は、データを分散テーブルに insert するだけです。
  2. The Delete+Insert Strategy では、各分片上のすべてのデータを処理するために分散一時テーブルを作成します。
  3. The Default (Legacy) Strategy では、同じ理由で分散一時テーブルと中間テーブルを作成します。
分散テーブル自体はデータを保持しないため、置き換えられるのは分片テーブルのみです。 分散テーブルが再読み込みされるのは、full_refresh モードが有効な場合、またはテーブル構造が変更された可能性がある場合のみです。

Distributed incrementalモデルの例

生成された移行

スナップショット

dbt の snapshot を使用すると、変更可能なモデルに加えられた変更を時系列で記録できます。これにより、モデルに対して特定時点の クエリを実行できるようになり、アナリストはモデルの過去の状態を「さかのぼって」確認できます。この機能は ClickHouse コネクタでサポートされており、次の構文で設定します。 snapshots/<model_name>.sql の設定ブロック:
設定について詳しくは、スナップショット設定のリファレンスページを参照してください。

コントラクトと制約

サポートされるのは、完全に一致するカラム型のコントラクトのみです。たとえば、UInt32 のカラム型を持つコントラクトでは、モデルが UInt64 やその他の整数型を返すと失敗します。 また、ClickHouse でサポートされるのは、テーブル/モデル全体に対する CHECK 制約 のみ です。主キー、外部キー、一意制約、および カラムレベルの CHECK 制約はサポートされていません。 (主キー / ORDER BY キーについては、ClickHouse のドキュメントを参照してください。)
最終更新日 2026年7月3日