Lantide Data
← 返回博客
与 Lantide 集成

使用 dbt 时，为什么还需要 Lantide？

dbt 适合生产转换、测试与 CI；对一次性假说验证，不必每次都开完整 model／CI。可用 Lantide 在本机沙盒探索，确认口径后再把标准 SQL 回写 dbt repo。

dbt 擅长把通过审查的 SQL 变成可重复部署的模型：测试、版本控制、CI，以及 defer／clone／selector 这类降低重建成本的开发手段。Defer · dbt clone · Optimize costs

你不必为每个「今天下午突然想改分母」的假说都开 PR。Lantide 当本机沙盒：在不污染 dbt repo、也不对云端仓库反覆全量扫描的前提下验证口径，确认值得长期维护后，再回写成 ref() 模型。

什么时候会卡在生产管线

1. 临时逻辑挤进 repo

每个一次性问题都新增 tmp_marketing_analysis_v2.sql、开 PR、跑 CI，专案很快会堆满短命模型。即使有 Slim CI，审查与合并成本还在。

2. 探索回圈和部署回圈摩擦不同

Defer／clone 能减少「为了改一个下游而重建整条上游」。但若你在仓库上对大表反覆试 JOIN、改过滤条件，仍可能产生可观的 compute。探索期需要更快的试错节奏；部署期需要更严的测试与审查。

3. 假说往往超前于正式语义

Semantic Layer 适合已定义、需要高准确度的企业指标。adhoc 与小范围探索，可以先用更灵活的查询验证，再决定要不要进语义层。Semantic Layer vs. Text-to-SQL

建议流程：Marts 当真源，本机当沙盒

dbt production marts（权威转换与测试）
        │
        │  透过已设定的 DB／MCP 来源读取或物化
        ▼
Lantide 本机沙盒（DuckDB 探索、Plan、分页快取）
        │
        │  确认值得长期维护后
        ▼
回写 dbt model（ref()、test、CI review）

Lantide 没有官方 dbt connector。你连接的是 dbt 已写入的仓库表，或可暴露这些表的 MCP／资料库来源，再在本机查询。见 MCP Sources 入门 与 USER_GUIDE §4.6。

沙盒里具体能做什么

物化后在本机反覆查

对已连线来源使用 mcp_pull_table 等工具，把需要的表物化到本机后再探索。首次拉取与之后的 refresh 仍有远端与储存成本；省下的是同一份物化结果上的反覆试错，避免每改 10 行条件就打回大仓库。

分页快取与 Source Run

探索 SQL 可落成 persist 分页；需要时用 Source Run 重跑上游链。本机物化快取通常是工作阶段／工作区层级的 TEMP 结果，重开或切换工作区后可能要重新连线并 Source Run——它不是永久数仓。见 USER_GUIDE §7–8。

回写 dbt 时改写成工程产物

本机验证通过后，要把逻辑改成 dbt 风格，而不是直接贴上带本机表名的 SQL：

-- Lantide 沙盒中验证过的逻辑（示意）
SELECT
    o.customer_id,
    COUNT(o.order_id) AS total_orders,
    SUM(o.amount) AS lifetime_value
FROM "mcp_wh__fct_orders" o
INNER JOIN "mcp_wh__dim_customers" c
    ON o.customer_id = c.customer_id
WHERE c.is_active = true
GROUP BY 1;

-- 回写 dbt 时改写
WITH orders AS (
    SELECT * FROM {{ ref('fct_orders') }}
),
customers AS (
    SELECT * FROM {{ ref('dim_customers') }}
)
SELECT
    o.customer_id,
    COUNT(o.order_id) AS total_orders,
    SUM(o.amount) AS lifetime_value
FROM orders o
INNER JOIN customers c ON o.customer_id = c.customer_id
WHERE c.is_active = true
GROUP BY 1;

回写后仍要补 test、materialization、命名与 PR／CI。

实务三步骤

  1. 确认来源：仓库直连或 MCP Source 能读到相关 marts；只物化本次假说需要的表。
  2. 本机验证：用 Plan 写清分母与时间窗，在 DuckDB 反覆改 SQL；JOIN 前检查 fan-out。见 JOIN fan-out。
  3. 值得长期维护再进 dbt：改写 ref()、补测试、走既有 Slim CI／defer 流程。
维度 主要留在 dbt 搭配 Lantide
生产转换与测试 是 —
一次性格口假说 摩擦较高 本机沙盒
远端 compute 每次 build／大查询计费 物化后本机重复查询
Repo 整洁度 易被临时 model 污染 先验证再进 repo

结语

dbt 把正确的转换变成可部署资产；Lantide 在那之前提供低摩擦、可审阅的本机沙盒。先验证、再 ref()，通常比把每个问题都塞进 CI 更永续。

建议下一步

参考资料