探索dbt 1.9的新特性：更快更灵活的数据处理

每隔四个月，dbt 会发布其 dbt core 和 dbt adapters 的新版本。在十月的前几天，dbt 1.9.0 发布了，带来了非常令人兴奋的新功能。在这篇文章中，我们将深入探讨此次发布的核心功能“微批增量”，同时也会介绍此次发布的其他新功能和优化。

免责声明：本次发布仍处于测试版阶段，预计将于2024年十一月的前半段正式可用。本文中描述的概念和配置很可能会保持不变。

dbt 1.9 引入了增量模型的一个新功能：微批处理方法（完整文档此处）。此前，增量模型之前只能通过单一字段（通常是时间戳）来批次处理新数据。这在处理大量数据时可能会造成性能瓶颈。具体来说，以前增量模型只能基于单个列批量处理新数据。

使用微批处理功能，你现在可以定义多个批处理列，让dbt可以处理更小、更易管理的数据块。这将使增量模型的刷新更快，减轻数据仓库的压力，最终实现更高效的数据管道。

这种方法有以下几个好处

• 效率：通过处理较小的数据块，你可以更有效地利用资源并减少处理时间。
• 容错性：如果某个批次失败，可以单独重试失败的批次。
• 并发性：在未来更新中，可以并发处理批次，进一步加快数据转换。
• 幂等性：由于每个批次都是独立的，重处理该批次应产生相同的结果。

与之前的增量配置相比，最大的变化是您不再需要在模型中指定“_isincremental”标识符。当运行微批处理模型时，dbt 会自动评估并确定哪些批次需要加载，将每个批次拆解成独立的 SQL 查询，并使每个批次独立加载。

如果不指定增量逻辑，那它怎么运作呢？微批处理配置包括四个参数，其中关键在于 event_time 参数。

• event_time : 表示“行发生的时间”的这一列是您的微批处理模型及其任何直接父项都需要的参数，这一点非常重要。您的微批处理模型的直接父项也需要配置此参数。
• Begin: 微批处理模型的开始时间。此参数在全量刷新构建时用于标识我们希望获取的最早历史数据。
• Batch_size: 您批次的时间粒度。支持的值为小时、天、月和年。
• Lookback: 在最新书签之前的批次数量，用于捕获滞后到达的记录。

我们来看一个名为“sessions.sql”的文件，它包含如下配置和查询：

    -- session.sql

    {{ config(
        materialized='incremental',
        incremental_strategy='microbatch',
        event_time='session_start',
        begin='2020-01-01',
        batch_size='day',
        lookback='1',
    ) }}

    -- 在此配置中，我们定义了增量模式和微批处理策略，事件时间设定为会话开始时间，从2020年1月1日开始，批处理大小为每天，回溯时间为1。

    select
          page_view_start as session_start
    from {{ ref('page_views') }}

    -- 该查询从页面视图表中选择页面视图开始时间作为会话开始时间。

这将被转换为基于查询运行天数的以下数据。

每个批次（例如，每天处理的）都会独立启动各自的查询，并在您的查询引擎中分别运行，采用“分而治之”策略。

这些微批次使得重新处理特定批次的旧数据比以往任何时候都更加容易，因此我们能轻易地回溯处理过往的数据。重新处理10月前五天的数据就像执行以下dbt（数据库处理工具）命令一样简单：

运行dbt，从开始事件时间 "2024-10-01" 到结束事件时间 "2024-10-05"。  
dbt run --event-time-start "2024-10-01" --event-time-end "2024-10-05"

这个命令用于在特定时间段内运行数据任务。

重新尝试失败的任务也变得更为简单。想象一下，如果你运行一个全面刷新，时间跨度为两年，粒度细化到每天。这将运行超过700个独立的任务，如果某些任务失败，你可以通过运行“dbt retry”命令轻松重试那些任务。下面的示意图展示了一个有三个任务失败的例子。

和每个新功能一样，它还有改进的空间，我非常推荐大家阅读Christophe Oudar关于这个话题的文章。他的建议非常有参考价值，希望dbt labs团队能在未来版本中考虑这些建议。

dbt 1.9 带来了许多令人兴奋的快照更新，使它们更加灵活和用户友好。以下是关键更改。

你现在可以使用 YAML 文件来定义数据快照，而不再需要使用 SQL。这在 dbt 中定义数据源时提供了一致性，并且提供了一种更简洁的方法。

YAML（snapshots/orders_snapshot.yml）:

    快照:  
    - 名称: orders_snapshot  
      关系源: source('jaffle_shop', 'orders')  
      配置选项:  
        模式: snapshots  
        数据库: analytics  
        唯一键: id  
        策略类型: timestamp  
        更新时间字段: updated_at 

需要应用转换吗？没问题！定义一个短暂的模型并在您的快照中引用它。

SQL（用于处理短暂订单的模型文件 models/ephemeral_orders.sql）:

    -- 配置为临时表
    {{ config(materialized='ephemeral') }}  

    -- 从源数据表 'jaffle_shop', 'orders' 中选择所有列
    select *   
    from {{ source('jaffle_shop', 'orders') }}  
    -- 满足某些条件
    where some_condition

YAML (配置文件/订单配置文件.yml):

    快照:  
    - 名字: orders_snapshot  
      关联: ref('ephemeral_orders')  
      配置信息:  
        # ... 快照配置

之前，所有的快照都写入相同的模式，不管是在哪个环境。现在，你可以根据各个环境（例如开发、生产）定义不同的模式，或者使用一个模式适用于所有环境。这样可以简化开发流程，让你有更多的控制权。

dbt 会自动在你的快照中添加元数据列（例如 dbt_valid_from dbt_valid_to）。在 dbt 1.9 版本之后，你可以在 YAML 配置中直接修改这些列名：

YAML（.yaml或.yml文件的标记语言）（snapshots/orders_snapshot.yml）：

    快照配置:  
    - 名字: orders_snapshot  
      # ... 你的配置  
      配置项:  
        # ...  
        元数据列名:  
          dbt_valid_from start_date  
          dbt_valid_to end_date

这些更新让 dbt 快照变得更加强大且更容易管理。更多详细信息请参阅官方 dbt 文档，https://docs.getdbt.com/docs/build/snapshots。

这篇文章探讨了让dbt 1.9对任何数据专家来说值得升级的两个主要特性。但这次发布还包括了一系列显眼的改进，比如。

• 确保在有人通过删除、重命名或禁用 合约化模型 时，dbt 返回错误（版本化模型）或警告（未版本化的模型），从而维护数据质量。
• 记录 单一数据测试。
• 在 外键约束 中使用 ref 和 source 函数。
• 使用 dbt test 并通过 —resource-type 或 —exclude-resource-type 标志，可以选择包含或排除数据测试或单元测试。

由于此版本没有引入任何破坏性更改，我们强烈建议您在发布稳定版后升级您的 dbt 项目。通过紧跟最新的发展脚步并利用新的功能，这能帮助您轻松维护最佳实践，提高数据管道的效率并确保其可靠性，并使您的 dbt 项目避免未来可能出现的兼容性问题。

如果你喜欢这篇文章，那就继续关注吧，因为我们会经常发布关于dbt和数据分析工程的文章。你就可以收到下一篇文章的通知了。可以关注 Astrafy 的 LinkedIn、Medium 和 YouTube 账号，以获取最新内容。

如果您想了解现代数据栈或 Google Cloud 解决方案的支持，欢迎随时联系我们 sales@astrafy.io。