`.
2. 新しいレコード (`SELECT` によって生成されたもの) のみを staging table に insert します。
3. 新しいパーティション (staging table に存在するもの) のみをターゲットテーブルに置き換えます。
このアプローチには、次の利点があります。
* テーブル全体をコピーしないため、デフォルトの戦略より高速です。
* `INSERT` 操作が正常に完了するまで元のテーブルを変更しないため、他の戦略より安全です。途中で障害が発生した場合でも、元のテーブルは変更されません。
* データエンジニアリングにおける「パーティション不変性」のベストプラクティスを実現します。これにより、増分処理、並列データ処理、ロールバックなどが簡単になります。
この戦略を使用するには、model configuration で `partition_by` を設定する必要があります。model config のそのほかの戦略固有の parameter はすべて無視されます。
## マテリアライゼーション: materialized\_view
`materialized_view` マテリアライゼーションは、挿入トリガーとして機能する ClickHouse の [materialized view](/docs/ja/reference/statements/create/view#materialized-view) を作成し、ソーステーブルからターゲットテーブルへ新しい行を自動的に変換して挿入します。これは、dbt-clickhouse で利用できるマテリアライゼーションの中でも特に強力なものの 1 つです。
このマテリアライゼーションは内容が多岐にわたるため、専用のページを用意しています。完全なドキュメントについては、\*\*[Materialized Views ガイド](/docs/ja/integrations/connectors/data-ingestion/etl-tools/dbt/materialization-materialized-view)\*\*をご覧ください。
## マテリアライゼーション: Dictionary (実験的)
ClickHouse Dictionary の
マテリアライゼーションを実装する方法の
例については、
[https://github.com/ClickHouse/dbt-clickhouse/blob/main/tests/integration/adapter/dictionary/test\_dictionary.py](https://github.com/ClickHouse/dbt-clickhouse/blob/main/tests/integration/adapter/dictionary/test\_dictionary.py) のテストを参照してください
## マテリアライゼーション: distributed\_table (実験的)
分散テーブルは、次の手順で作成されます:
1. 適切な構造を取得するためのSQLクエリを使って一時ビューを作成する
2. ビューに基づいて空のローカルテーブルを作成する
3. ローカルテーブルに基づいて分散テーブルを作成する。
4. データは分散テーブルに挿入されるため、重複することなく各分片に分散される。
注:
* dbt-clickhouse のクエリには現在、設定 `insert_distributed_sync = 1` が自動的に含まれており、これにより
下流のインクリメンタル
マテリアライゼーション操作が正しく実行されることが保証されます。そのため、一部の分散テーブルへの挿入が
想定より遅くなる可能性があります。
### 分散テーブルモデルの例
```sql theme={null}
{{
config(
materialized='distributed_table',
order_by='id, created_at',
sharding_key='cityHash64(id)',
engine='ReplacingMergeTree'
)
}}
select id, created_at, item
from {{ source('db', 'table') }}
```
### 生成された移行
```sql theme={null}
CREATE TABLE db.table_local on cluster cluster (
`id` UInt64,
`created_at` DateTime,
`item` String
)
ENGINE = ReplacingMergeTree
ORDER BY (id, created_at);
CREATE TABLE db.table on cluster cluster (
`id` UInt64,
`created_at` DateTime,
`item` String
)
ENGINE = Distributed ('cluster', 'db', 'table_local', cityHash64(id));
```
### 設定
このマテリアライゼーション種別に固有の設定を以下に示します。
| Option | Description | Default if any |
| ------------- | -------------------------------------------------------------------------------------------------- | -------------- |
| sharding\_key | 分片キーは、Distributed engine テーブルに insert する際の宛先サーバーを決定します。分片キーには、ランダムな値、または hash function の出力を使用できます。 | `rand()`) |
## materialization: distributed\_incremental (実験的)
分散テーブルと同じ考え方に基づく増分モデルですが、主な難しさは、すべての増分
戦略を正しく処理することにあります。
1. *The Append Strategy* は、データを分散テーブルに insert するだけです。
2. *The Delete+Insert* Strategy では、各分片上のすべてのデータを処理するために分散一時テーブルを作成します。
3. *The Default (Legacy) Strategy* では、同じ理由で分散一時テーブルと中間テーブルを作成します。
分散テーブル自体はデータを保持しないため、置き換えられるのは分片テーブルのみです。
分散テーブルが再読み込みされるのは、full\_refresh モードが有効な場合、またはテーブル構造が変更された可能性がある場合のみです。
### Distributed incrementalモデルの例
```sql theme={null}
{{
config(
materialized='distributed_incremental',
engine='MergeTree',
incremental_strategy='append',
unique_key='id,created_at'
)
}}
select id, created_at, item
from {{ source('db', 'table') }}
```
### 生成された移行
```sql theme={null}
CREATE TABLE db.table_local on cluster cluster (
`id` UInt64,
`created_at` DateTime,
`item` String
)
ENGINE = MergeTree;
CREATE TABLE db.table on cluster cluster (
`id` UInt64,
`created_at` DateTime,
`item` String
)
ENGINE = Distributed ('cluster', 'db', 'table_local', cityHash64(id));
```
## スナップショット
dbt の snapshot を使用すると、変更可能なモデルに加えられた変更を時系列で記録できます。これにより、モデルに対して特定時点の
クエリを実行できるようになり、アナリストはモデルの過去の状態を「さかのぼって」確認できます。この機能は
ClickHouse コネクタでサポートされており、次の構文で設定します。
`snapshots/.sql` の設定ブロック:
```python theme={null}
{{
config(
schema = "",
unique_key = "",
strategy = "",
updated_at = "",
)
}}
```
設定について詳しくは、[スナップショット設定](https://docs.getdbt.com/docs/build/snapshots#snapshot-configs)のリファレンスページを参照してください。
## コントラクトと制約
サポートされるのは、完全に一致するカラム型のコントラクトのみです。たとえば、UInt32 のカラム型を持つコントラクトでは、モデルが
UInt64 やその他の整数型を返すと失敗します。
また、ClickHouse でサポートされるのは、テーブル/モデル全体に対する `CHECK` 制約 *のみ* です。主キー、外部キー、一意制約、および
カラムレベルの `CHECK` 制約はサポートされていません。
(主キー / ORDER BY キーについては、ClickHouse のドキュメントを参照してください。)