3. dbt核心概念
在金融数据治理场景中，dbt 不只是一个 SQL 执行器，它更像一套“数据资产装配线”。模型、源、种子、快照、宏、测试、文档与项目结构，分别承担了数据加工、数据接入、静态映射、历史追踪、逻辑复用、质量校验、元数据沉淀和工程组织八类职责。理解它们之间的边界与协作方式，是后续做测试治理和文档治理的前提。
一、核心原理：八类对象各司其职
dbt 项目中的每一类对象，本质上都在回答一个不同的问题：数据从哪里来、如何变换、如何复用、如何验证、如何解释、如何组织。下面这张结构关系图展示了八类核心对象在 dbt 项目中的位置与数据流向。
从图中可以看出，源和种子是数据入口，快照负责历史留存，模型是核心加工单元，宏提供逻辑复用，测试和文档分别从质量和元数据两个维度对模型进行约束与说明，而项目结构则决定了这些对象如何被组织和发现。
二、方法流程：从原始数据到可信资产
在金融数据项目中，一个典型的 dbt 工作流如下：
- 定义源：在
sources.yml中声明上游业务库表，如core_banking.account、trade.order，并配置新鲜度检查。 - 加载种子：将行业分类码、币种映射、机构对照表等静态数据以 CSV 形式放入
seeds/，通过dbt seed加载。 - 建立快照：对客户风险等级、账户状态等需要追踪历史变化的表配置
snapshot，采用timestamp或check策略。 - 编写模型：按 staging → intermediate → marts 分层，staging 做清洗与重命名，marts 做业务聚合与宽表输出。
- 抽取宏：将重复的利息计算、汇率转换、日期维度生成等逻辑封装为宏，减少复制粘贴。
- 配置测试：对主键、外键、枚举值、非空、唯一性、接受值范围等设置通用测试与自定义测试。
- 生成文档：在 YAML 中补充模型描述、字段说明、负责人和标签，通过
dbt docs generate产出可浏览的血缘图。
关键命令示例：
dbt seed --select currency_mapping
dbt snapshot --select customer_risk_snapshot
dbt run --select staging.core_banking+
dbt test --select marts.finance
dbt docs generate && dbt docs serve三、案例场景：金融数据治理中的对象协作
假设某银行需要构建“客户资产视图”。源系统包括核心银行系统、理财系统和信贷系统。种子表提供产品类别映射，快照表追踪客户风险等级变化，模型层先做 staging 清洗，再在 marts 层汇总总资产、总负债和净值。宏用于统一计算年化收益率，测试用于校验客户号唯一性和资产金额非负，文档则记录每个字段的业务含义和监管口径。
| 对象 | 金融场景示例 | 治理关注点 |
|---|---|---|
| 源 sources | 核心系统客户表、交易流水表 | 新鲜度、权限、上游变更通知 |
| 种子 seeds | 币种代码、产品分类、机构对照 | 版本控制、变更审计 |
| 快照 snapshots | 客户风险等级、账户状态历史 | SCD2 准确性、时间戳边界 |
| 模型 models | 客户资产宽表、产品收益汇总 | 分层规范、命名一致、口径统一 |
| 宏 macros | 利息计算、汇率转换、日期维度 | 可测试性、参数校验、复用边界 |
| 测试 tests | 客户号唯一、金额非负、枚举合法 | 覆盖率、失败告警、阻断策略 |
| 文档 docs | 字段业务含义、监管口径、负责人 | 完整性、时效性、血缘可追溯 |
四、误区与复盘：常见治理陷阱
误区一：把种子当生产表用。种子适合静态码表，不适合频繁更新的业务数据。若将每日汇率放入种子，会导致版本膨胀和加载延迟。
误区二：快照策略选错。金融场景中客户风险等级变化必须用 timestamp 策略精确到生效时间，若用 check 策略可能漏掉同一天多次变更。
误区三：测试只做 not_null。金融数据对唯一性、外键、枚举和数值范围要求极高，仅做非空测试无法发现重复入账或金额异常。
误区四：文档与模型脱节。模型字段变更后未同步更新 YAML，导致血缘图和字段说明失真，影响监管报送和下游信任。
复盘建议：在项目初期就建立 models/staging、models/intermediate、models/marts 三层目录规范，并在 dbt_project.yml 中统一配置物化策略、标签和测试阈值。将宏按业务域拆分到 macros/finance/、macros/utils/，避免单一宏文件过度膨胀。测试和文档应作为模型交付的一部分，而不是事后补做。