dbt - DBT 是否支持创建临时表，如 create table #temp1 as select * from tab1 或者它仅适用于 CTE 方式

Question

我找到了一种处理 DBT 中临时表的方法，将所有这些写在预钩中并在预钩外部调用最终临时表，经过测试并且工作正常，能够减少代码运行时间超过 20 分钟到 1 分钟。但是我看到一个问题，我们在 DBT 文档中看不到谱系图。
除了 pre-hook 和 Docs 中的 lineage 之外，还有什么方法可以处理临时表吗？

Answer 1

您认为 dbt 不支持临时表是正确的。那是因为临时表只在单个​​ session 中持续存在，而 dbt 每个线程打开一个连接/ session 。因此，在一个线程上创建的任何临时表对于在不同线程上运行的模型都是不可见的。
听起来 CTE 对您来说是一种性能拖累——出于兴趣，您使用的是哪个仓库？
您已经确定了两种解决方法，还有另一种值得讨论:
选项 1:使用 ephemeral 将您的模型具体化为 CTE物化 ( docs )
优点:

模型显示在谱系图中

您可以通过 ref 在多个下游模型中重复使用这些转换。 - 他们

您可以测试和记录这些模型

缺点:

在某些时候，堆叠 CTE 过多会导致性能下降(尤其是在较旧版本的 postgres 上，其中 CTE 是优化栅栏)

编译后的 SQL 可能更难调试

选项 2:使用预 Hook 创建临时表
我通常不建议这样做 - 您无法测试或记录您的模型，并且它们不会出现在谱系图中(正如您所指出的)。
选项 3:将这些模型具体化为单独模式中的表，并在运行结束时删除模式
我认为迈克尔的建议很好!我会稍微调整一下:

使用 schema配置以在单独的模式中实现模型

{{ config(
  materialized='table',
  schema='my_temporary_schema'
) }}

然后，在运行结束时，使用 on-run-end钩子(Hook) ( docs ) 以删除该模式 - 在您的 dbt_project.yml 中:

on-run-end: "drop schema my_temporary_schema cascade"

优点:

选项 1 的所有优势

听起来它可能比使用 CTE 的性能更高

缺点:

确保在该架构之上没有任何依赖 View !当您运行 drop cascade 时，它们可能会被丢弃。命令!这给您的项目带来了脆弱性!