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 更永續。

建議下一步

參考資料