2. 云数仓平台选型与 dbt 适配

dbt 本身不存储数据，它通过 adapter（适配器） 把标准 SQL 模型翻译成目标平台能执行的方言，并调用平台的能力完成建表、增量合并、快照、测试等动作。因此“选 dbt 适配器”本质上不是选一个软件包，而是选一套云数仓平台。平台决定了 SQL 方言、计算与存储的耦合方式、并发与成本模型，也决定了 dbt 能用到哪些高级特性。本节围绕 Snowflake、BigQuery、Redshift、Databricks SQL 四个主流平台，从 dbt 适配角度做对比，并给出选型判断方法。

一、四个平台的 dbt 适配特征

Snowflake 的 dbt 适配最成熟。dbt-snowflake 支持标准物化视图、增量模型、快照、Python 模型，以及 merge、delete+insert、append、insert_overwrite 等多种增量策略。Snowflake 的虚拟数仓（Virtual Warehouse）与存储分离，计算可独立扩缩，天然适合 dbt 的“按模型并发跑”模式。它的 transient table、clone 零拷贝克隆、时间旅行等特性，也能被 dbt 的临时表与快照机制利用。代价是计算按秒计费，仓库空转也会产生费用，需要合理设置 auto_suspend 与仓库规模。

BigQuery 的 dbt 适配同样成熟。dbt-bigquery 支持分区表、聚簇表、增量模型、快照，以及 insert_overwrite 这类针对分区覆盖的增量策略。BigQuery 是全托管、无服务器架构，没有“仓库开关”的概念，按扫描字节数计费，因此 dbt 模型写得好不好，直接体现在账单上——SELECT *、缺少分区过滤、重复扫描大表都会显著推高成本。BigQuery 对嵌套与数组（STRUCT/ARRAY）支持强，适合半结构化数据建模，但 SQL 方言与标准 SQL 有差异，跨平台迁移时需要注意。

Redshift 的 dbt 适配可用但更“传统”。dbt-redshift 基于 PostgreSQL 生态，支持增量模型、快照，但物化视图、Python 模型等能力受限。Redshift 是 MPP 架构，计算与存储曾强耦合（RA3 后有所解耦），性能高度依赖分布键（DISTKEY）与排序键（SORTKEY）的设计。dbt 模型如果没配好分布键，join 时会产生大量数据重分布（redistribute），性能急剧下降。因此用 Redshift 时，dbt 模型配置里往往要显式声明 dist 和 sort，这是它与其他平台最大的差异点。

Databricks SQL 的 dbt 适配近年快速完善。dbt-databricks 基于 Spark SQL 方言，支持 Delta Lake 表、增量模型、快照，并可用 merge 做 upsert。Databricks 的 Lakehouse 架构让存储层是开放格式（Delta/Parquet），计算层可弹性伸缩，适合已有数据湖、需要同时做批处理与 SQL 分析的团队。它的 SQL 方言与 Spark 一致，函数丰富，但与传统数仓的 SQL 习惯差异较大，且 dbt 的部分高级特性（如某些物化策略）支持程度不如 Snowflake/BigQuery。

二、选型时真正要看的四个维度

第一是SQL 方言与迁移成本。如果团队已有大量 PostgreSQL 或标准 SQL 资产，Redshift 迁移最平滑；如果从零开始且接受新方言，Snowflake 与 BigQuery 的学习曲线都不陡；Databricks 的 Spark SQL 与标准 SQL 差异最大，需要额外投入。

第二是增量与物化能力。dbt 的增量模型依赖平台的 merge/upsert 或分区覆盖能力。Snowflake 与 BigQuery 的增量策略最丰富，Redshift 与 Databricks 也能用 merge，但在大表上的表现和配置复杂度不同。如果业务以“每日全量覆盖分区”为主，BigQuery 的 insert_overwrite 非常高效；如果以“按主键 upsert”为主，Snowflake 与 Databricks 的 merge 更顺手。

第三是计费模型与成本可控性。Snowflake 按仓库运行时间计费，dbt 跑批时开仓库、跑完自动挂起，成本可预测；BigQuery 按扫描量计费，模型写得差会直接体现在账单上，需要靠分区裁剪和列裁剪控制；Redshift 按集群小时计费，集群常开成本固定，适合稳定负载；Databricks 按 DBU 加云资源计费，弹性好但需要监控集群规格。

第四是团队既有技术栈与运维能力。已经在用 AWS 且熟悉 PostgreSQL 的团队，Redshift 上手快；已经在用 GCP 的团队，BigQuery 几乎零运维；已经有数据湖、需要批流一体的团队，Databricks 更合适；追求最成熟 dbt 生态、愿意接受新平台的团队，Snowflake 是稳妥选择。

三、一个可执行的选型判断流程

实际选型时，可以按下面的顺序收敛，避免一上来就比功能清单：

1. 先定云厂商：数据已经在 AWS/GCP/Azure 上，优先选同云平台，减少跨云传输成本与延迟。
2. 再看负载形态：以固定批处理为主，Redshift/Snowflake 合适；以弹性、突发查询为主，BigQuery/Databricks 更省心。
3. 再看增量需求：需要频繁 upsert 且表很大，优先 Snowflake 或 Databricks；以分区覆盖为主，BigQuery 更高效。
4. 最后看成本模型：把预估的 dbt 跑批频率、数据量、并发数代入各平台计费方式，做一次粗略月成本估算，再决定。

四、dbt 项目中的适配器配置示例

选定平台后，dbt 项目通过 profiles.yml 指定 adapter 与连接信息。下面以 Snowflake 为例，展示关键字段（示例参数，非真实凭据）：

dbt_project:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: "xy12345.ap-southeast-1"
      user: "dbt_user"
      password: "{{ env_var('DBT_PASSWORD') }}"
      role: "TRANSFORMER"
      database: "ANALYTICS"
      warehouse: "DBT_WH"
      schema: "DEV"
      threads: 8
      client_session_keep_alive: false

其中 threads 控制 dbt 并发执行的模型数，需要与仓库规模匹配：仓库太小、threads 太大，模型会排队；仓库太大、threads 太小，资源闲置。Snowflake 上通常把 threads 设为 8～16，配合 auto_suspend=60 的仓库，兼顾速度与成本。BigQuery 的 profile 则用 method: oauth 或 service-account，并可通过 priority 控制查询优先级；Redshift 需要额外配置 ra3_node 等参数；Databricks 需要 host、http_path、token。

五、选型后的落地检查清单

把这张表当作落地前的核对依据：确认 adapter 包版本与平台版本兼容、增量策略与业务更新方式匹配、分区/分布键已在模型配置中声明、成本控制点已设置。完成这些检查后，dbt 项目才算真正“适配”了所选平台，而不是仅仅能连上数据库。