原始資料到暫存層橋接器(Source-to-Staging Bridge)

每位資料工程師在 Airbyte/Fivetran 與 dbt 之間手動填補的缺口,每次都要重來一遍

最高頻率缺口 嚴重程度從 9 降至 7 可自動化

問題說明

業務副總裁說:「我需要在週五之前在 Looker 看到 HubSpot 的資料。」初級資料工程師啟用了 Airbyte 的 HubSpot 連接器。它同步了 47 個資料流到 BigQuery,建立了如下的資料表:

raw_hubspot.deals
raw_hubspot.deals_properties_hs_deal_amount
raw_hubspot.deals_associations_company_ids
raw_hubspot.contacts
raw_hubspot.contacts_properties_hs_email
... (另外 42 張資料表)

接著資料工程師需要將這些資料表轉換為乾淨的 dbt 暫存模型,這包括:

  • 從 47 張資料表中找出實際需要的部分
  • deals_properties_hs_deal_amount 重新命名為 deal_amount
  • 將字串型金額轉型為數值(SUM(amount) 在字串上會失敗)
  • 將負責人 ID 對應到姓名(否則儀表板只顯示「12345」而非「陳小明」)
  • 撰寫 schema.yml,包含欄位描述與測試

這需要 4 到 8 小時的手動作業。每次都要重來。每新增一個資料來源都一樣。

多智能體模擬的實證結果

9→7
使用工具後的嚴重程度降幅
4-8h
每個來源的手動對應時間
2-3x/月
新來源整合頻率
47
單次 HubSpot 同步產生的資料表數
模擬發現 — HubSpot 情境

這是唯一一個使用工具後嚴重程度從 9 降至 7 的情境。在其他所有情境(結構漂移、效能問題、遷移)中,嚴重程度無論使用何種工具都維持在 8 到 9 之間。這表示此問題確實可以透過自動化來解決。

觀察員識別的瓶頸點
  • 「擷取層(Airbyte)和轉換層(dbt)之間的過渡點對工程師來說是一個『黑盒子』」
  • 「將 Airbyte 自動生成的扁平化欄位名稱對應到 dbt 暫存模型」——預估需 2 到 4 小時,自動化潛力:高
  • 「接受在 Airbyte 中『按下按鈕』是一件高風險、令人不安的事」

使用前與使用後對比

無橋接器(現狀)

-- 手動作業:每個來源 4-8 小時
-- 步驟一:找出存在哪些資料表
SELECT table_name FROM
  information_schema.tables
  WHERE dataset_id = 'raw_hubspot';
-- (回傳 47 張資料表,大多不明用途)

-- 步驟二:逐一檢查每張資料表的結構
-- 步驟三:猜測哪些欄位重要
-- 步驟四:手動撰寫暫存模型
SELECT
  id AS deal_id,
  -- 等等,欄位名稱是 'amount' 還是
  -- 'properties_hs_deal_amount'?
  -- 而且它是字串型別??
  CAST(properties_hs_deal_amount
    AS NUMERIC) AS deal_amount,
  -- 怎麼取得負責人姓名...?
  properties_hubspot_owner_id
    AS owner_id  -- 顯示為 "12345"
FROM raw_hubspot.deals

有橋接器(自動生成)

-- 30 秒內自動生成
-- 來源:raw_hubspot.deals
-- 已偵測相關資料流:47 中的 5 個

SELECT
  id AS deal_id,
  CAST(properties_hs_deal_amount
    AS NUMERIC) AS deal_amount,
  properties_dealstage AS deal_stage,
  properties_closedate AS closed_at,
  o.owner_name,
  a.company_id
FROM raw_hubspot.deals d
LEFT JOIN raw_hubspot.owners o
  ON d.properties_hubspot_owner_id
   = o.owner_id
LEFT JOIN raw_hubspot
  .deals_associations_company_ids a
  ON d.id = a.deal_id

-- schema.yml 同步生成,包含:
--   欄位描述
--   deal_id 的 not_null 測試
--   deal_stage 的 accepted_values 測試
--   deal_amount 的正值測試

為何存在此缺口

Airbyte 的職責終止於「資料已落地至倉儲」。它不知道 dbt 需要什麼。

dbt 的職責從「這是我的來源資料表」開始。它不知道 Airbyte 建立了什麼。

兩者之間的缺口——理解原始結構、清理命名、修正型別、新增關聯、生成測試——完全依賴人工。Fivetran 也是如此。


現有工具功能不涵蓋的範圍
Airbyte將資料同步至倉儲不生成 dbt 模型
Fivetran dbt packages針對部分來源的預建模型僅涵蓋約 30 個來源;不處理自訂屬性
dbt codegen從來源生成基礎模型無智慧重新命名、無型別偵測、無關聯推斷
原始資料到暫存層橋接器(Source-to-Staging Bridge)讀取原始結構與樣本資料 → 生成完整暫存模型,包含智慧命名、型別轉換、關聯推斷與測試

產品設計

觸發條件

在 BigQuery/Snowflake 落地結構中偵測到新的原始資料表(透過 information_schema 輪詢或事件觸發)。

工作流程

  1. 結構掃描(Schema scan):讀取資料表結構並取樣 100 筆資料
  2. 資料流分類(Stream triage):將資料表分類為核心/關聯/中繼資料/無關
  3. 智慧重新命名(Smart rename):deals_properties_hs_deal_amountdeal_amount
  4. 型別修正(Type fix):偵測字串編碼的數字、日期、布林值 → 生成 CAST 語句
  5. 關聯推斷(Join inference):偵測外鍵(owner_id → owners 資料表、關聯資料表)
  6. 測試生成(Test generation):主鍵的 not_null、金額的正值、列舉的 accepted_values
  7. 輸出(Output):暫存模型 SQL + schema.yml + 可直接提交 PR 的 commit

市場規模

50K+
同時使用 Airbyte/Fivetran 與 dbt 的公司數
2-3x
每個團隊每月新增來源數
$300-600
每次手動整合的工程師成本

收益模型

方案價格功能
免費(Agent Skill)$0透過 CLI 隨需生成暫存模型
專業版(Pro)$49/月持續監控新資料表 + 自動建立 PR
團隊版(Team)$199/月多來源支援、命名慣例強制執行、成本估算
企業版(Enterprise)$499/月自訂連接器、個資偵測(PII detection)、合規模板

第一年預測

競爭優勢