dbt核心原理与工程实践：从数据仓库定位到DAG血缘治理 1. 这不是又一篇“dbt入门指南”——而是一份数据工程师亲手写给自己的实操备忘录我带过六支数据工程团队从零搭建过四套核心数仓体系也亲手把三家公司从Excel报表时代拖进dbt云数仓的现代流水线。过去三年里我面试过127位声称“熟悉dbt”的候选人其中能说清ref()和source()根本区别、能在5分钟内定位dbt test失败是schema问题还是逻辑问题、知道为什么dbt run --select stg_orders会连带跑出17个上游模型的不到11人。这不是能力问题而是市面上90%的dbt教程都在教“怎么敲命令”却没人告诉你“为什么必须这样敲”“敲错一个空格会炸掉哪条链路”“生产环境里哪个配置项改错会导致整张宽表凌晨三点重跑失败”。这篇内容就是我把这六年踩过的坑、调过的夜、被凌晨报警电话叫醒后记下的笔记浓缩成七根真正支撑你日常工作的“钢筋”。它不讲dbt有多酷、社区多活跃、文档多庞大——那些话术留着去融资PPT里用。这里只讲当你坐在工位上面对一个新需求、一张脏数据表、一个突然报错的CI流水线时你该打开哪个文件、查哪行日志、改哪个参数、心里默念哪三句口诀。关键词就七个数据仓库定位、Core与Cloud分野、项目结构即契约、profile是命门、模型即SQL契约、DAG是血缘图谱、测试是上线前最后一道安检门。全文没有一句“通过本文你可以……”因为真实世界里没有“通过”只有“跑通”和“炸了”。接下来所有内容都来自我本地终端里反复rm -rf target dbt clean dbt deps dbt build的真实记录以及生产环境里dbt debug --config-dir输出的第37行错误堆栈。2. 数据仓库不是“存数据的地方”而是dbt所有动作的物理坐标系很多人学dbt卡在第一步——连自己连的是什么都不知道。他们以为dbt init之后点几下就进了数据世界结果第一次dbt run就报Database Error: no such table stg_users然后开始疯狂搜“dbt 表不存在”。其实问题根本不在这儿而在于没搞懂dbt和数据仓库之间那个最朴素的关系dbt不是数据库它是一把精密的扳手而数据仓库才是那台正在运转的发动机。dbt只负责拧紧、校准、更换零件但绝不提供发动机本身。举个生活化例子你家厨房有冰箱数据仓库、有菜刀砧板ETL工具、有食谱dbt项目。dbt干的活就是按食谱把冰箱里的生肉、蔬菜切配成半成品再按步骤组装成一道菜。但它既不造冰箱也不管冰箱里有没有肉——那是Airflow或Fivetran的事它也不决定这道菜端给谁吃——那是BI工具的事。它只确保当食谱写着“取200g五花肉”你切出来的真是200g肥瘦比例符合要求且切法能让后续红烧时不散不柴。所以理解数据仓库本质是理解dbt的“作用域边界”。你必须明确回答三个问题我的数据仓库物理位置在哪是Snowflake账号acme-prod.us-east-1下的ANALYTICS数据库是BigQuery项目acme-data-312456里的raw数据集还是本地DuckDB文件/Users/alex/dbt_learn/dev.duckdb这个路径决定了profiles.yml里type字段填什么snowflake/bigquery/duckdb决定了pip install时该装哪个adapterdbt-snowflake/dbt-bigquery/dbt-duckdb更决定了dbt debug连不通时你该先查网络策略、IAM权限还是本地文件权限。我的数据仓库当前状态是否可信很多人跳过这步直接写模型结果发现stg_orders表里order_id字段全是NULL——不是dbt错了是上游ELT任务昨天挂了根本没把数据灌进来。正确做法是在dbt run前先手动连进仓库执行SELECT COUNT(*) FROM raw.orders LIMIT 1;确认基础表存在且有数据。我团队强制要求所有新成员入职第一周每天早会前必须手写三条SQL验证三个核心源表这是比背ref()语法更重要的基本功。我的数据仓库权限模型是否匹配dbt操作dbt默认用CREATE TABLE AS SELECTCTAS方式生成模型。这意味着你的数据库用户必须拥有对目标schema的CREATE权限、对源表的SELECT权限、对目标表的INSERT/UPDATE权限。我在某次迁移中栽过跟头DBA只给了SELECT权限dbt run报错Permission denied: cannot create table in schema analytics。查了两小时日志最后发现是权限问题。现在我们所有项目的profiles.yml里user字段后面必加一行注释# 需具备analytics.*: CREATE, raw.*: SELECT, staging.*: INSERT新同事入职第一天就抄这行注释到自己的配置里。提示别被“云数仓”概念迷惑。Snowflake、BigQuery、Redshift本质都是关系型数据库的云化形态它们支持标准SQL、有schema、有table、有role-based access control。dbt之所以能“一套代码打天下”正因为它只依赖这些共性能力而非某个厂商的私有特性。你今天用DuckDB练熟的ref(stg_users)明天换到Snowflake只要profiles.yml里type改成snowflake、account填对代码一行不用改。3. dbt Core vs. dbt Cloud选错就像给赛车装自行车轮胎刚接触dbt的人常问“我该学Core还是Cloud”这个问题本身就暴露了认知偏差——这不是“学哪个”而是“在哪个阶段用哪个”。我把它们的关系比作汽车制造dbt Core是发动机总成图纸和装配手册dbt Cloud是已经组装好、上了牌照、能直接开上路的整车。3.1 dbt Core你的本地作战指挥室dbt Core是开源的命令行工具安装命令就一行pip install dbt-adapter_name。它的价值不在“能做什么”而在“让你看清每一步怎么做”。比如dbt compile不执行SQL只做Jinja渲染和依赖解析生成target/compiled/下的纯SQL文件。这是调试Jinja逻辑的黄金命令。当你写了个复杂macro不确定{{ loop.index }}是否生效dbt compile后直接看生成的SQL比猜强一万倍。dbt parse只解析项目结构检查models/下SQL文件语法、models/*.yml配置格式、macros/宏定义是否合法。耗时不到1秒却是CI流水线里dbt test前必跑的“语法体检”。dbt ls --select stg_*列出所有匹配stg_*前缀的模型不运行只展示依赖关系。当你想快速确认stg_users到底被哪些模型引用这条命令比翻代码快十倍。我坚持让所有新人从Core起步原因很实在所有Cloud功能底层都是Core在跑。Cloud界面上点一下“Run Job”后台实际执行的就是dbt run --select stg_users --target prod。如果你连本地dbt run --models stg_users都跑不通上了Cloud只会更懵——因为Cloud把错误日志包装得更友好反而掩盖了真实问题。注意dbt Core不是“免费版”它是dbt Labs的开源根基。Cloud的付费功能如Web IDE、Job Scheduler、SLA监控都是在Core之上叠加的运营层。就像Linux内核和Ubuntu桌面版的关系——你非得先懂ls、cd、grep才能用好图形界面。3.2 dbt Cloud团队协作的高速公路收费站dbt Cloud的核心价值是把原本需要手动维护的运维工作变成可配置、可审计、可复用的服务。它解决的不是“技术能不能实现”而是“一群人怎么安全高效地一起干活”。典型场景环境隔离自动化你在Cloud里创建dev、staging、prod三个环境每个环境绑定独立的profiles.yml实际是Cloud后台管理的Connection配置。开发时dbt run自动走dev连接提PR后CI自动触发staging环境测试合并主干后一键部署到prod。而用Core你得手动维护三套profiles.yml切换时改target字段一不小心就把测试SQL跑到了生产库。权限与审计闭环Cloud里可以设置只有data_engineering组能修改models/staging/目录analysts组只能读models/marts/所有dbt run操作自动记录执行人、时间、SQL哈希值、影响行数。某次线上事故我们5分钟就定位到是实习生误删了stg_customers的WHERE条件而不是翻两天Git日志。调度与告警集成dbt Cloud的Job Scheduler支持Cron表达式、依赖触发如“等Airflow的load_raw_data任务成功后再跑dbt run”、失败重试、邮件/Slack告警。而Core要实现同样效果得自己写Python脚本调subprocess.run([dbt, run])再塞进Airflow的BashOperator中间任何一环断掉就得半夜爬起来修。实操心得我们团队采用“Core开发 Cloud交付”混合模式。新人本地用Core写模型、调Jinja、跑测试代码提交后CI流水线用Core做语法检查和单元测试最终部署到Cloud由Cloud统一调度、监控、告警。这样既保证开发灵活性又守住生产稳定性。千万别用Cloud Web IDE写复杂逻辑——没有本地IDE的智能提示和Git集成写macro时少个括号都能调试半小时。4. dbt项目结构不是文件夹而是数据契约的法律文书dbt init my_project生成的目录远不止是一堆文件。它是你和未来自己、和队友、和下游分析师签订的一份数据契约。每个目录名、文件名、YAML字段都在声明“我承诺这样组织数据这样定义逻辑这样保障质量”。破坏这个结构轻则模型跑不通重则整个数据链路信任崩塌。4.1 核心目录语义每个名字都是责任状models/数据产品的生产车间。这里放的不是“SQL脚本”而是“数据产品说明书”。每个.sql文件对应一张对外交付的表/视图文件名就是这张表的业务名称如stg_orders.sql内容必须是完整的SELECT语句禁止INSERT INTO或CREATE TABLE。我见过最离谱的案例有人把models/staging/下所有文件命名为a.sql、b.sql、c.sql三个月后连他自己都记不清b.sql到底是处理订单还是用户。models/staging/原始数据的缓冲区。这里只做三件事重命名列order_id AS order_id、类型转换CAST(created_at AS TIMESTAMP)、过滤无效记录WHERE _fivetran_deleted FALSE。绝不做聚合、关联、业务逻辑计算。原则是“让原始数据尽可能干净地透传把脏活留给下游”。我们团队规定staging/目录下任何模型SQL行数不得超过50行超过必须拆分或质疑设计。models/marts/面向业务的交付层。这里产出的表名字直接对应业务术语dim_customers、fct_orders、agg_daily_revenue。它们是分析师写Dashboard、产品经理看数据的唯一可信来源。marts/下的模型可以复杂但必须有清晰的业务归属——比如marts/marketing/下的所有模型只服务市场部需求财务部无权访问。seeds/静态配置数据的保险柜。存放不会变的维表如国家代码表、产品分类码表。用CSV文件seeds/country_codes.csv通过dbt seed命令加载。优势是版本可控Git里看得到变更、加载快比SQL建表快10倍、无需维护SQL逻辑。我们把所有accepted_values测试的白名单都放在这里比如seeds/payment_methods.csvtests/里直接{{ ref(payment_methods) }}引用一改全改。macros/SQL函数的中央厨房。所有重复逻辑必须抽象成macro。比如日期处理macros/date_utils.sql里定义{% macro get_fiscal_year(date_col) %}...{% endmacro %}全项目统一调用{{ get_fiscal_year(order_date) }}。好处是一处修复全局生效且macro可单独测试dbt run-operation get_fiscal_year --args {date_col: 2023-01-01}。关键细节dbt_project.yml里的model-paths、analysis-paths等配置本质是在重定义这套契约的物理边界。如果你把models/挪到src/models/就必须在dbt_project.yml里显式声明model-paths: [src/models]否则dbt根本找不到你的模型。这不是“约定俗成”而是dbt强制执行的契约条款。4.2 文件命名铁律名字即接口缩写即隐患模型文件名必须可读stg_orders.sql✅so.sql❌。后者在dbt ls输出里就是一团乱码dbt run --select so更是灾难——万一还有个so_payments.sql呢目录层级即业务层级models/staging/salesforce/✅明确来源系统models/staging/sf/❌缩写模糊新人看不懂s f代表salesforce还是service feeYAML配置文件名必须匹配models/staging/orders.yml必须与models/staging/orders.sql同名不含扩展名。dbt靠这个关联模型和其配置。我曾因把orders.yml错命名为stg_orders.yml导致所有not_null测试失效排查了4小时才发现是文件名不匹配。5. profiles.yml不是配置文件而是dbt连接数据世界的唯一签证profiles.yml是dbt项目里最危险、也最重要的文件。它不包含业务逻辑却掌控着所有数据的生死。我把它比作“数字世界的签证”——没有它dbt连数据仓库的大门都摸不到写错一个字符整个团队的开发流就会瘫痪。5.1 物理位置与安全红线profiles.yml绝不能放在项目目录里必须放在用户主目录下的.dbt/文件夹macOS/Linux:~/.dbt/profiles.ymlWindows:%USERPROFILE%\.dbt\profiles.yml。这是dbt硬编码的路径改不了。原因很现实项目目录会Git提交而profiles.yml里有数据库密码或密钥。把它放项目里等于把公司数据库密码上传到GitHub——我们真见过这种事后果是全员强制重置密码、审计所有数据访问日志。提示生产环境严禁明文密码。Snowflake用private_key_path指向本地密钥文件BigQuery用keyfile指向JSON密钥DuckDB用path指向本地文件。所有敏感信息必须通过环境变量注入password: {{ env_var(DBT_PASSWORD) }}然后在CI或Cloud里配置环境变量。5.2 结构解析target、outputs、profile三层嵌套逻辑# ~/.dbt/profiles.yml acme_analytics: # profile名称必须与dbt_project.yml里profile字段一致 target: dev # 默认激活的output outputs: dev: # output名称对应target字段 type: duckdb # 数据库类型必须与已安装adapter匹配 path: ./dev.duckdb # DuckDB特有本地文件路径相对项目根目录 # 其他数据库需填account, user, password, database, schema, warehouse等 prod: type: snowflake account: acme-prod.us-east-1 user: {{ env_var(SNOWFLAKE_USER) }} password: {{ env_var(SNOWFLAKE_PASSWORD) }} role: DBT_PROD_ROLE database: ACME_PROD schema: ANALYTICS warehouse: DBT_WH关键点profile是顶层命名空间用于区分不同项目acme_analyticsvsacme_marketing。dbt_project.yml里profile: acme_analytics必须与之完全一致。outputs是具体连接实例每个output对应一个环境dev/staging/prod。target: dev指定了默认连接dbt run不加--target就走这里。type字段是生命线pip install dbt-duckdb后type: duckdb才有效装dbt-snowflake后type: snowflake才有效。装错adapterdbt debug直接报Runtime Error: No adapter found for duckdb。5.3 调试神技dbt debug不是“看看就行”而是逐层验尸dbt debug命令会执行四层检查每层失败都给出精准定位Profile Validity检查profiles.yml语法是否合法YAML格式、缩进、冒号后空格。常见错误password: abc写成password:abc缺空格或outputs:下面忘了缩进。Connection Test尝试用outputs.dev配置连接数据库。失败时明确提示Connection failed: unable to open database file ./dev.duckdb文件路径错或Authentication failed密码错。Adapter Compatibility确认已安装对应adapter。失败提示Runtime Error: No adapter found for duckdb该装dbt-duckdb。Project Config检查dbt_project.yml是否存在且语法正确。实操心得每次换环境如从dev切到prod必跑dbt debug --target prod。我团队CI流水线里dbt debug是第一个stage失败直接阻断后续所有步骤。宁可多花10秒也不让错误SQL污染生产数据。6. dbt模型不是SQL文件而是可编译、可依赖、可测试的数据合约models/下的.sql文件表面看是SQL实则是dbt编译器的输入源码。它必须满足三个硬性条件可被Jinja渲染、可被ref()引用、可被test()验证。违反任一条件它就不是dbt模型只是普通SQL脚本。6.1 模型编写黄金法则SELECT是唯一出口dbt模型必须以SELECT语句开头且整个文件只能有一个SELECT除非用Jinja条件分支。禁止出现INSERT INTO ... SELECT ...❌dbt自动生成CTASCREATE TABLE ... AS SELECT ...❌dbt自动处理WITH cte AS (...) SELECT ...✅CTE是SELECT的一部分正确写法-- models/staging/stg_orders.sql SELECT id AS order_id, customer_id, CAST(created_at AS TIMESTAMP) AS order_timestamp, total_amount, status FROM {{ source(raw, orders) }} WHERE _fivetran_deleted FALSE注意{{ source(raw, orders) }}这是引用源表的标准方式比硬编码raw.orders更安全——它会在sources.yml里校验表是否存在且支持跨环境切换dev环境raw指向raw_devschemaprod指向raw_prod。6.2 ref()与source()血缘关系的两种DNA{{ ref(stg_orders) }}引用同一dbt项目内的其他模型。dbt据此构建DAG确保stg_orders先于依赖它的int_orders执行。ref()的参数必须是模型文件名不含路径和扩展名如stg_orders.sql→ref(stg_orders)。{{ source(raw, orders) }}引用外部数据源表即ELT工具灌入的原始表。必须在models/sources.yml里预先声明# models/sources.yml version: 2 sources: - name: raw database: ACME_PROD # Snowflake中database名 schema: RAW # Snowflake中schema名 tables: - name: orders description: Raw orders from Fivetran关键区别ref()是项目内依赖source()是项目外依赖。混淆二者是高频错误。比如在stg_orders.sql里写{{ ref(raw.orders) }}会报错因为raw.orders不是模型名正确写法是{{ source(raw, orders) }}。6.3 模型配置YAML不是装饰而是执行指令集模型行为由models/*.yml文件控制而非SQL内注释。例如# models/staging/schema.yml version: 2 models: - name: stg_orders description: Staged orders with cleaned columns and types config: materialized: table # 生成物理表非视图 persist_docs: relation: true # 生成表级文档 columns: true # 生成字段级文档 columns: - name: order_id description: Unique identifier for the order tests: - unique - not_null - name: total_amount description: Order total in USD tests: - relationships: to: ref(dim_currency) field: currency_code这里config.materialized: table告诉dbt“为这个模型创建物理表”而非默认的view。persist_docs开启后dbt docs generate会把description注入数据库COMMENT让SELECT * FROM INFORMATION_SCHEMA.COLUMNS也能看到中文说明。注意tests必须写在columns下不能写在models下。- not_null是简写完整形式是- test: not_null。简写仅适用于内置测试自定义测试必须用完整形式。7. DAG不是图表而是dbt执行引擎的拓扑地图dbt run之所以能自动确定执行顺序全靠DAGDirected Acyclic Graph。它不是你画在白板上的示意图而是dbt解析ref()和source()后在内存中构建的实时依赖树。理解DAG就是理解dbt如何“思考”。7.1 DAG生成原理ref()是唯一的路标dbt扫描所有.sql文件提取所有{{ ref(xxx) }}和{{ source(yyy, zzz) }}构建节点关系每个模型文件是一个节点每个ref(model_name)是一条有向边从被引用模型指向当前模型source()是外部入口节点无入边只有出边例如-- models/marts/fct_orders.sql SELECT o.order_id, o.customer_id, c.country_code, o.total_amount FROM {{ ref(stg_orders) }} o JOIN {{ ref(dim_customers) }} c ON o.customer_id c.customer_idDAG节点fct_orders←stg_ordersfct_orders←dim_customers执行顺序先stg_orders再dim_customers最后fct_orders若两者无依赖则并行7.2 DAG可视化dbt docs不是摆设而是血缘诊断仪dbt docs generate dbt docs serve启动的Web界面核心价值不是“好看”而是交互式血缘追踪点击任意模型如fct_orders右侧显示Upstream所有被它ref()的模型stg_orders,dim_customersDownstream所有ref()它的模型如agg_monthly_revenueSource Tables它直接读取的源表通过source()点击stg_orders的Upstream显示raw.orders源表再点进去看到Fivetran同步任务名——这就是端到端血缘。实操技巧当dbt run --select fct_orders失败先打开dbt docs找到fct_orders看Upstream里哪个模型标红表示未成功构建。90%的问题根源在上游模型。不要一上来就查fct_orders的SQL先查stg_orders是否跑通。7.3 DAG陷阱循环依赖是死结必须手动破除DAG禁止循环Acyclic即不能出现A → B → C → A。常见诱因错误的ref()链路int_users.sql里ref(stg_users)✅但stg_users.sql里又ref(int_users)❌逻辑错误宏滥用在macros/calc_revenue.sql里ref(fct_orders)而fct_orders.sql又调用此macro ❌破除方法dbt list --select fct_orders --output json输出所有上游模型人工检查是否有闭环。更彻底的是在CI里加入dbt deps后执行dbt list --select fct_orders | wc -l设定阈值如50个模型超限则告警——这往往是隐性循环的征兆。8. Jinja模板不是“SQL里写Python”而是SQL的元编程语言Jinja在dbt里不是炫技工具而是解决SQL原生缺陷的手术刀。SQL缺乏变量、循环、条件判断Jinja补上了这些缺口但必须严守边界Jinja只生成SQL绝不执行SQL。8.1 ref()和config()最常用也最易错的两个函数{{ ref(model_name) }}生成目标模型的完整限定名。在DuckDB中是stg_orders在Snowflake中是ACME_PROD.ANALYTICS.STG_ORDERS。它确保跨环境一致性——你不用管prod里schema叫ANALYTICS还是PROD_ANALYTICSref()自动适配。{% set my_schema config.get(schema, analytics) %}从模型配置中取值。配合config:在YAML里定义# models/marts/marketing/schema.yml models: - name: agg_campaign_performance config: schema: marketing_analytics # 覆盖project-level schemaSQL中即可用{{ my_schema }}动态生成CREATE TABLE marketing_analytics.agg_campaign_performance。常见错误{{ ref(stg_orders) }}写成{{ ref(stg_orders) }}漏引号或{{ ref(stg_orders) }}写成{{ ref(stg_orders) }}双引号在某些shell里会被解释。必须单引号且引号内是字符串字面量。8.2 宏MacroSQL函数的终极形态宏是预编译的SQL代码块解决重复逻辑。例如标准化时间分区-- macros/time_partition.sql {% macro time_partition(column_name, partition_typeday) %} {% if partition_type day %} DATE({{ column_name }}) {% elif partition_type month %} DATE_TRUNC(month, {{ column_name }}) {% endif %} {% endmacro %}在模型中调用-- models/marts/fct_orders.sql SELECT {{ time_partition(order_timestamp, month) }} AS order_month, COUNT(*) AS order_count FROM {{ ref(stg_orders) }} GROUP BY 1编译后生成SELECT DATE_TRUNC(month, order_timestamp) AS order_month, COUNT(*) AS order_count FROM ANALYTICS.STG_ORDERS GROUP BY 1关键原则宏必须放在macros/目录且文件名与宏名一致time_partition.sql→time_partition宏。调用宏时{% call %}用于生成DDL{{ }}用于生成DML表达式。9. dbt测试不是“锦上添花”而是数据上线前的熔断开关dbt test不是开发完成后的附加步骤而是每个模型提交前的强制安检。它不保证业务逻辑正确但保证数据基础可靠主键不重复、关键字段不为空、外键有对应值、数值在合理范围。没过测试的模型连dbt run都不该让它执行。9.1 四大内置测试每个都是数据质量的基石测试名作用典型场景配置示例unique检查字段值是否全局唯一order_id,customer_id- uniquenot_null检查字段是否无NULL值order_timestamp,status- not_nullaccepted_values检查字段值是否在预设白名单内status只能是pending,shipped,delivered- accepted_values: {values: [pending, shipped, delivered]}relationships检查外键是否在目标表存在customer_id在dim_customers表有对应记录- relationships: {to: ref(dim_customers), field: customer_id}9.2 测试执行策略不是“全量跑”而是“精准打”dbt test运行所有测试慢适合CIdbt test --models stg_orders只跑stg_orders相关测试快适合开发中dbt test --select test_type:generic只跑通用测试unique,not_null等dbt test --select test_type:singular只跑自定义SQL测试见下文实操心得我们团队规定git commit前必须执行dbt test --models modified_model。CI流水线里dbt test是第二步第一步是dbt debug失败则阻断部署。曾有一次accepted_values测试发现payment_method新增了crypto值但业务方未同步更新白名单测试立刻捕获避免了下游报表数据异常。9.3 自定义测试Singular Test应对复杂业务规则内置测试解决通用问题自定义测试解决特定规则。例如订单金额不能为负数且必须大于运费。-- tests/order_amount_check.sql SELECT order_id, total_amount, shipping_cost FROM {{ ref(stg_orders) }} WHERE total_amount 0 OR total_amount shipping_cost文件名order_amount_check.sql放在tests/目录。dbt test会自动发现并执行——返回非空结果即视为测试失败。关键点自定义测试文件必须是.sql且内容是SELECT语句。dbt将查询返回行数 0 视为失败即“找到违规数据”。这与通用测试逻辑相反通用测试是“找到违规数据”才失败但语义一致测试的目的是暴露问题。10. 典型工作流不是线性步骤而是PDCA循环dbt不是“写完代码→跑一次→完事”的工具而是嵌入数据开发全生命周期的协作协议。我们团队实践的最小可行工作流MVP Workflow如下10.1 日常开发循环PDCAPlan计划接到需求如“新增用户地域维度”在dbt docs里查dim_customers现有字段确认缺失country_code规划新建stg_customers_geo.sql和dim_customers_enhanced.sql。Do执行touch models/staging/stg_customers_geo.sql写SQL{{ source(raw, customers_geo) }}touch models/marts/dim_customers_enhanced.sql{{ ref(stg_customers_geo) }}touch models/staging/schema.yml添加stg_customers_geo的not_null测试Check检查dbt compile --models stg_customers_geo→ 看生成SQL是否正确dbt run --models stg_customers_geo→ 确认执行成功dbt test --models stg_customers_geo→ 确认测试通过Act行动git add、git commit -m feat: add customers geo staging、git push触发CI。10.2 CI/CD流水线自动化守门员我们CI流水线GitHub Actions固定四步dbt debug --target dev验证配置