Skip to content

dbt-deep-dive.md

Latest commit

 

History

History
93 lines (66 loc) · 5.92 KB

dbt-deep-dive.md

File metadata and controls

93 lines (66 loc) · 5.92 KB

现代数据栈的核心：dbt详解与最佳实践

引言：数据转换（T）的文艺复兴

在传统的数据管道中，ETL（Extract, Transform, Load）是主流模式：数据在加载到数据仓库之前，需要经过一个独立的转换层进行处理。然而，随着现代云数据仓库（如Snowflake, BigQuery, Redshift）计算能力的飞速提升，一种更高效的模式——ELT（Extract, Load, Transform）——开始兴起。

在ELT流程中，原始数据被直接加载（Load）到数据仓库中，所有的转换（Transform）工作都在仓库内部完成。这种模式充分利用了云数仓强大的计算能力，但同时也带来了一个新问题：如何高效、可靠、可维护地管理这些在数据仓库内部执行的、日益复杂的SQL转换逻辑？

dbt (data build tool) 正是为解决这一挑战而生的革命性工具。它不是一个ETL工具，而是一个专注于 T（Transform） 环节的开发框架。dbt通过将软件工程的最佳实践（如版本控制、模块化、测试和文档）引入数据分析和转换工作，彻底改变了数据团队的工作方式。

dbt的核心理念：将分析代码化

dbt的核心思想是：分析师和数据工程师应该像软件工程师一样工作。它允许你只用SQL（或者结合Python）来编写数据转换逻辑，然后dbt会负责处理将这些SQL编译成数据库可执行的视图或表，并管理它们之间的依赖关系。

dbt如何工作？ 你用SELECT语句编写数据模型（models），dbt会处理物化（materialization）的DDL和DML（如CREATE TABLE AS...）。你只需关注数据转换的业务逻辑本身。

dbt的核心概念

1. 模型 (Models)

  • 定义：一个模型就是一个.sql文件，其中包含一个SELECT语句。
  • 作用：每个模型定义了一个转换逻辑，其结果将成为数据仓库中的一个新表或视图。文件名通常就是最终的表名。
  • 示例 (models/orders.sql): 
    SELECT
    order_id,
    customer_id,
    status,
    amount
FROM raw_orders
WHERE amount > 0

2. 引用函数 ref()

  • 定义：dbt中最重要、最核心的函数。
  • 作用：用于引用其他的模型。你不需要硬编码表名（如analytics.orders），而是使用{{ ref('orders') }}。
  • 好处：dbt会根据ref函数自动推断出模型之间的依赖关系，构建一个有向无环图（DAG），并按照正确的顺序执行它们。这也使得你可以在不同环境（开发、生产）之间无缝切换，而无需更改代码。

3. 数据源 (Sources)

  • 定义：在.yml文件中定义，用于描述从数据仓库加载的原始数据表。
  • 作用：允许你像引用模型一样引用原始数据表（使用{{ source('jaffle_shop', 'orders') }}），并可以对源数据进行测试（如非空、唯一性）。

4. 测试 (Tests)

  • 定义：dbt将测试视为一等公民，用于断言你的数据模型和数据源产出的数据质量。
  • 类型：
    • 通用测试（Generic Tests）：开箱即用的测试，如unique, not_null, accepted_values, relationships。可以直接在.yml文件中配置。
    • 单体测试（Singular Tests）：当你需要编写更复杂的业务逻辑断言时，可以编写一个SQL查询，如果查询返回行，则测试失败。

5. 物化 (Materializations)

  • 定义：模型在数据仓库中被创建的方式。
  • 主要类型：
    • view（默认）：构建为视图。速度快，不额外存储数据。
    • table：构建为表。查询速度快，但构建较慢。
    • incremental：增量模型。dbt只转换自上次运行以来新到达的源数据行，极大地提升了大型表的更新性能。
    • ephemeral：短暂模型。不会在数据库中创建，而是作为公共表表达式（CTE）被注入到引用它的模型中。

dbt项目最佳实践

dbt官方和社区总结了一系列最佳实践，以确保项目的可维护性和可扩展性。

  1. 规范的项目结构：

    • 将模型按层次组织在不同的目录中，如staging（源数据清洗、重命名）、intermediate（中间转换）、marts（最终暴露给业务用户的宽表）。

  2. 只在Staging层引用Source：

    • 下游的所有模型都应引用staging层的模型，而不是直接引用原始数据。这确保了数据清洗和统一的逻辑只在一个地方进行。

  3. 模型拆分：

    • 保持每个模型逻辑的单一和简洁。将复杂的转换逻辑拆分成多个中间模型，可以提高可读性和可维护性。

  4. 编码风格统一：

    • 制定团队统一的SQL编码风格（如命名规范、CTE的使用等），以提升代码的可读性。

  5. 为一切添加测试和文档：

    • 为模型的关键列添加not_null和unique测试。
    • 使用.yml文件为每个模型和列添加清晰的描述（description），dbt会自动将这些描述生成为一份可交互的数据文档网站。

结论：dbt是现代数据团队的加速器

dbt的出现，成功地将数据转换工作从一门“手艺”变成了一门“工程学科”。它让数据团队能够：

  • 专注于业务逻辑：将繁琐的DDL/DML操作自动化，让分析师和工程师能更专注于实现业务价值。
  • 提升数据质量与可靠性：通过内置的测试和文档功能，确保产出的数据是可信赖的。
  • 加速迭代：通过版本控制和自动化测试，团队可以更自信、更快速地对数据模型进行修改和迭代。

在现代数据栈中，dbt已经成为连接数据加载工具（如Fivetran, Airbyte）和BI工具（如Tableau, Looker）之间不可或-

  • 缺的核心转换层。掌握dbt，已经成为每一位现代数据工程师和分析师的必备技能。