Atheon建立了这样一个dbt案例：CTE（通用表表达式）是passthrough的，性能的影响是可以忽略不计的，因为现代数据仓库优化器识别这种模式。该博客通过比较“导入的 CTE” 和“直接在 CTE 中引用基表”的情况，讲述了 Snowflake 的情况并非如此。
其结果是，建立时间从超过 30 分钟减少到不到 10 分钟，大约在一个表中节省了 600 美元。
在 Atheon Analytics，我们每天通过数据管道输送数十亿行杂货零售数据。为了改进这个过程，今年早些时候我们已经开始在我们所有的项目中推出 dbt，并努力完全接受推荐的良好实践。
企业里的新同事长期以来一直在为我们复杂的SQL查询而苦恼，他们成功地说服了甚至像我这样持怀疑态度（只是通过丰富的经验！）的SQL开发人员，认为dbt提出的看似多余的东西是有一定价值的。
我们做了报告：引用了文章（CTEs are passthroughs)），最后每个dbt模型都被正确地格式化了。我们生活在dbt诱导的幸福中......直到我们加载我们的传统数据，看着我们不断上升的数据库成本。
毫无疑问，dbt 不仅是一个了不起的工具，而且是一个超越交付软件的整体运动。其中一个重要部分是 dbt 实验室为倡导适当的 SQL 样式（dbt 样式指南）所做的大量工作。
“换行很便宜，大脑时间很昂贵”绝对是我们在 Atheon Analytics 的代码审查中互相问候的一句话。
然而，我们最近了解到，样式的关键元素 ：the proliferation of CTEs ， 可以将表构建扩展高达 600%，这意味着相当大的成本影响，至少在我们使用的数据库 (Snowflake) 中是这样。
....
提高 SQL 代码可读性的论据非常强烈，dbt 运动在这个方向上取得了巨大的进步，将整个学科提升到了一个新的水平。然而，似乎有一个限制，换行变得比大脑时间更昂贵，这会大大降低数据管道的速度，以至于您必须牺牲一些样式元素并将精力集中在实质上。
详细点击标题