`.
2. 仅将新记录 (由 `SELECT` 生成) 插入到暂存表中。
3. 仅将新分区 (即暂存表中存在的分区) 替换到目标表中。
这种方法具有以下优点：
* 它比默认策略更快，因为不需要复制整个表。
* 它比其他策略更安全，因为在 INSERT 操作成功完成之前，不会修改原始表：
如果中途失败，原始表不会被修改。
* 它实现了“分区不可变性”这一数据工程最佳实践，从而简化增量和并行数据
处理、回滚等操作。
该策略要求在模型配置中设置 `partition_by`。模型配置中所有其他特定于策略的
参数都会被忽略。
## 物化：materialized\_view
`materialized_view` 物化会创建一个 ClickHouse [materialized view](/docs/zh/reference/statements/create/view#materialized-view)，它可充当插入触发器，自动将源表中的新行转换后插入到目标表中。这是 dbt-clickhouse 中最强大的物化类型之一。
由于这一物化较为复杂，我们为其提供了单独的页面。完整文档请参阅 **[Materialized Views 指南](/docs/zh/integrations/connectors/data-ingestion/etl-tools/dbt/materialization-materialized-view)**
## 物化：字典 (Experimental)
有关如何为
ClickHouse 字典实现物化的示例，请参阅测试
[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 (experimental)
按以下步骤创建分布式表：
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));
```
### 配置
下面列出了此物化类型特有的配置：
| 选项 | 描述 | 默认值 (如有) |
| ------------- | ----------------------------------------------------------- | --------- |
| sharding\_key | 分片键决定了向 Distributed 引擎表中插入数据时的目标服务器。分片键可以是随机值，也可以是哈希函数的输出结果 | `rand()`) |
## materialization: distributed\_incremental (experimental)
基于与分布式表相同思路的增量模型，主要难点在于正确处理各种增量
策略。
1. *追加策略* 只是将数据插入分布式表。
2. *Delete+Insert* 策略会创建分布式临时表，以便在每个分片上处理全部数据。
3. *默认 (旧版) 策略* 出于同样的原因，会创建分布式临时表和中间表。
只有分片表会被替换，因为分布式表本身不存储数据。
只有在启用 full\_refresh 模式或表结构可能发生变化时，分布式表才会重新加载。
### Distributed 增量模型示例
```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 快照可用于记录可变模型随时间发生的变化。这进一步支持对模型执行时间点
查询，使分析人员能够“回溯”查看模型先前的状态。此功能由
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` 约束。
(参见 ClickHouse 关于主键 / ORDER BY 键的文档。)