概述
物化是在仓库中保留 DBT 模型的策略。dbt 中内置了四种类型的物化。它们是：
表
视图
增量
临时
配置物化
默认情况下，dbt 模型物化为“视图”。通过提供如下所示的配置参数，可以使用不同的具体化来配置模型。materialized
dbt_project.yml
name: my_project
version: 1.0.0
config-version: 2
models:
my_project:
events:
# materialize all models in models/events as tables
+materialized: table
csvs:
# this is redundant, and does not need to be set
+materialized: view
或者，可以直接在模型 sql 文件中配置具体化。如果您还要为特定型号设置 [性能优化] 配置（例如，Redshift 特定配置或 BigQuery 特定配置），这将非常有用。
物化
- 视图
使用物化时，模型将在每次运行时通过语句重新生成为视图。viewcreate view as
优点：不会存储其他数据，源数据顶部的视图将始终包含最新记录。
缺点：执行重大转换或堆叠在其他视图之上的视图查询速度很慢。
建议：
通常从模型的视图开始，只有在注意到性能问题时才更改为另一个物化。
视图最适合不进行重大转换的模型，例如重命名、重新转换列。
- 表
使用物化时，您的模型将重建为table表在每次运行时，通过语句。create table as
优点：表查询速度很快
缺点：
表可能需要很长时间才能重建，尤其是对于复杂的转换
基础源数据中的新记录不会自动添加到表中
建议：
将表物化用于 BI 工具查询的任何模型，为最终用户提供更快的体验
还可以将表物化用于许多下游模型使用的任何较慢的转换
- 增量
incremental模型允许 DBT 自上次运行 DBT 以来将记录插入或更新到表中。
优点：只需转换新记录即可显著缩短构建时间
缺点：增量模型需要额外的配置，并且是 dbt 的高级用法。在此处阅读有关使用增量模型的更多信息。
建议：
增量模型最适合事件样式数据
当您变得太慢时，使用增量模型（即不要从增量模型开始）dbt run
- 临时
ephemeral模型不直接内置到数据库中。相反，dbt 会将此模型中的代码作为公共模型插入到依赖模型中表表达。
优点：
您仍然可以编写可重用的逻辑
临时模型可以帮助您保持数据仓库通过减少混乱进行清理（还可以考虑使用自定义架构将模型拆分到多个架构中）。
缺点：
不能直接从此模型中进行选择。
操作（例如，通过不能临时节点调用的宏）dbt run-operationref()
过度使用临时物化也会使查询更难调试。
建议：将临时物化用于：
DAG 早期的非常轻量级转换
仅用于一个或两个下游型号，并且
不需要直接查询
Python 具体化
Python 模型支持两种物化：
- table
- incremental
增量 Python 模型支持与其 SQL 对应项相同的所有增量策略。支持的特定策略取决于您的适配器。