dbt中的“短暂材料化”到底是什么意思？

什么是短暂的？它适用于哪些场景？什么时候该用它，什么时候不该用它？

DBT: 什么是瞬时的物质化？

在 dbt (数据构建工具) 中，“ephemeral” 指的是一种瞬时类型的实现。在 dbt 中，实现决定了 dbt 如何保存模型的结果。主要的实现类型有：

• 表：在数据库中创建表。
• 视图：在数据库中创建视图。
• 增量更新：创建一个可增量更新的表。
• 瞬时：不创建任何数据库对象，而是将瞬时模型的 SQL 代码内联到下游模型中。

注：此处翻译为“瞬息的实体化”更加直接地表达了“materialization”的意思。

瞬态模型的独特之处在于它们不会在数据库中创建任何物理表示，这意味着它们不会生成实际的数据库对象。相反，当将模型配置为瞬态时，dbt 会直接将 SQL 代码插入引用它的任何模型中。这使得中间转换可以被简化，而无需创建中间表或视图，从而避免了额外的数据库对象和存储空间的浪费。

短暂的模型特别有用，比如：

1. 中间转换：为了提高可读性和可维护性，最好将复杂的转换分为几个步骤，但不需要持久化中间结果。
2. 可重用逻辑：当你在多个模型中需要使用相同的逻辑时，可以将其定义在临时模型或组件中，并可以在不创建额外数据库对象的情况下重用它。

假设你有两个模型：base_orders 和 filtered_orders。你可以创建一个临时模型 clean_orders，做一些中间的清理工作：

    -- 下面的代码是英语，是SQL代码
    -- models/clean_orders.sql  
    {{  
      config(  
        materialized='ephemeral'  
      )  
    }}  

    select  
        id,  
        order_date,  
        customer_id  
    from {{ ref('base_orders') }}  
    where order_date is not null

     -- models/filtered_orders.sql  
    -- 从清洗后的订单表中筛选出customer_id不为空的订单记录
    select  
        id,  
        order_date,  
        customer_id  
    from {{ ref('clean_orders') }} -- 'clean_orders'是清洗后的订单表
    where customer_id is not null -- 其中 customer_id 不为空

在这个例子中，clean_orders 中的 SQL 会直接嵌入到 filtered_orders，这样就只有一个查询，它既包含了清理也包含了过滤两个步骤，而且不需要为 clean_orders 创建任何中间表或视图。

• 性能：通过将转换合并到一个查询中，减少数据库对象的数量，从而可能加快查询执行速度。
• 可维护性：通过将复杂的转换分解为更小、可重用的组件，提高代码的可读性和可维护性。
• 资源效率：避免额外创建、管理及存储数据库中的表或视图所带来的开销。

临时模型是DBT中的一个强大功能，如果使用得当，可以提升你数据转换工作流程的效率和可维护性。

当一个短暂或瞬时模型被多个下游模型使用时，它的SQL逻辑会被重新计算并整合到每个下游模型里，这种情况既有优点也有缺点。

1. 无额外存储开销：由于瞬态模型不会创建任何数据库对象，从而节省了存储空间。
2. 简单性和可维护性：将转换逻辑分解成可重用的模块，使其更容易管理和理解。
3. 内联优化：当瞬态模型内联时，可以受益于数据库引擎的查询优化，从而可能减少多个中间表带来的额外开销。

(Choose one based on the context, either "缺点：" or "缺点，")

1. 重新计算开销：瞬态模型的SQL逻辑每次使用时都会重新计算，如果瞬态模型复杂并频繁被多个下游模型使用，可能会导致性能开销。
2. 重复计算：如果同一个瞬态模型在一个下游模型中被多次引用，它的计算逻辑将重复执行每次引用。