Jordan Tigani 如何從 BigQuery 到 MotherDuck 重寫 AI 分析資料庫？

<

p class=”wp-block-paragraph”>Jordan Tigani 的職涯提供一條理解現代 AI 分析資料層的清楚路線：他曾是 Google BigQuery 的 founding engineer，之後從大規模雲端資料倉儲的成功經驗反過來追問，多數企業查詢真的需要把所有工作都交給大型分散式叢集嗎？他共同創辦 MotherDuck，與 DuckDB 生態合作，把本機高效執行、雲端共享、按需計算與 AI agent 的分析需求組成另一種資料倉儲想像。

從 BigQuery 成功者到「Big Data is Dead」的挑戰者

MotherDuck 官方作者頁介紹 Tigani 曾任 SingleStore Chief Product Officer，之前則是 Google BigQuery 的 founding engineer、工程與產品領導者。這讓他的批判不是站在巨量資料系統之外，而是來自親手建立、推廣並觀察雲端分析服務的經驗。

他看到的問題並非 BigQuery 沒有價值，而是產業把極端規模當成所有公司的預設需求。當系統先為 petabyte、數千節點與共享叢集優化，小型互動查詢也會承受協調、啟動、排程與計費複雜度。AI 時代大量 agent 查詢短、小、突發且需要低延遲，這些歷史折衷重新變得值得檢查。

「Big Data is Dead」真正反對的是錯誤問題定義

Tigani 的〈Big Data is Dead〉並不是宣稱大型資料集消失，而是指出許多企業難以取得洞察的主因未必是資料太大。他依據查詢紀錄、客戶問題、產品指標與實務觀察，認為很多工作負載只觸碰整體資料的一小部分，而硬體成長已讓單機能處理過去需要叢集的規模。

這個區分對 AI 產品很重要。訓練 frontier model 確實需要極端資料與運算，但企業 RAG、營運分析與 agent 工具常只查某位客戶、最近事件或一小段欄位。若架構只以總資料量選型，就可能為不會出現在熱路徑的冷資料支付協調成本。

從 scale-out 回到 scale-up，不是回到單機孤島

〈The Simple Joys of Scaling Up〉比較二十年來軟體的橫向擴充與硬體的縱向成長。scale-out 能線性增加資源，但需要網路、分區、容錯與調度；scale-up 則可直接利用更多核心、記憶體與向量化執行，避免許多分散式協調。

這不表示所有資料都該困在筆電。MotherDuck 的設計是讓 DuckDB 可在本機、瀏覽器與雲端執行，依資料位置和共享需求決定工作放在哪裡。真正的選擇不是「單機或雲端」二選一，而是讓查詢計畫把計算推到合理位置，只有需要時才支付分散式成本。

MotherDuck 的起點：替 DuckDB 補上協作與服務層

MotherDuck 官方 origin story記錄，Tigani 看見 DuckDB 後想到建立 serverless 版本，並與 DuckDB 創作者 Hannes Mühleisen、Mark Raasveldt 及 DuckDB Labs 建立合作。這個關係不是 fork 一份引擎再各走各路，而是讓開源核心與商業雲端能力分工。

DuckDB 擅長嵌入式、列式與向量化分析；雲端服務則要補上身份、共享、持久儲存、資源隔離與協作。把邊界畫好，開發者可以保留本機工具的速度，也能在需要多人與持續服務時連到雲端。這種組合比把全部功能重寫成另一套封閉 warehouse 更能利用既有生態。

Dual execution：資料在哪裡，就考慮在哪裡算

MotherDuck 對 dual execution 的官方說明指出，系統透過 DuckDB extension 接入 parser、optimizer、catalog 與 storage，讓本機與雲端協同執行，而不是只把 DuckDB 包在遠端伺服器。查詢可以使用本地檔案、瀏覽器資源與雲端共享資料。

對 AI agent 而言，這提供延遲與隱私上的新選項。敏感資料可以在使用者端先篩選，雲端只處理共享部分；小查詢不用每次啟動大型叢集；需要共享或較大資源時再推往雲端。代價是 planner、權限與資料新鮮度更複雜，所以系統必須清楚顯示計算位置與傳輸邊界。

Hypertenancy：每個使用者或 agent 有隔離的 DuckDB

Tigani 的 AI analytics 講座把 hypertenancy 描述為替每個使用者或 agent 提供獨立、可縮放的 DuckDB instance。這和大型共享叢集的 multi-tenancy 不同：不是讓所有工作負載搶同一組 executor，而是以大量小型隔離單元降低 noisy neighbor。

這個模型很適合 agent 的爆發式查詢。每個代理可以有自己的暫存表、cache 與資源上限，錯誤查詢不必拖慢整個組織。但隔離單元數量增加後，catalog、連線、冷啟動、監控與成本歸屬必須自動化；若控制平面不成熟，hypertenancy 只會把叢集問題改成大量 instance 問題。

分析資料庫補足 LLM 不擅長的計算

Tigani 指出 LLM 能理解語言，卻可能在精確計算、最新私有資料與可重複查詢上出錯。把 agent 接到分析引擎，讓 SQL 處理聚合、filter、join 與統計，再由模型解釋結果，是比要求模型在文字裡心算更可靠的分工。

這種 tool use 仍需要約束。agent 產生的 SQL 必須受到唯讀角色、schema allowlist、查詢 timeout、掃描上限與結果大小限制；高風險修改不能因自然語言介面而獲得更寬權限。資料庫是計算工具，也是安全邊界。

從 self-service analytics 到 answering machine

〈Building an answering machine〉描述 MotherDuck MCP server 如何讓 Claude、ChatGPT 或 Gemini 連接資料並以自然語言提問。Tigani 把它視為 self-service analytics 的新介面：使用者不一定要會 SQL，agent 可以探索 schema、產生查詢並整理答案。

真正困難的不只是把 endpoint 接上模型。企業名稱、指標定義、資料權限與時間口徑若沒有治理，agent 仍會生成語法正確但商業意義錯誤的 SQL。可靠 answering machine 需要 semantic layer、測試查詢、可見引用與人類確認流程，而不是只依賴更長 prompt。

低延遲在 agent 世界比 dashboard 更敏感

傳統 BI 使用者願意等待數秒看報表，agent 卻可能在一個任務中連續執行十幾次查詢。每一步增加半秒，整條 reasoning loop 就會變慢；若 agent 平行分支，排隊與啟動成本還會放大。因此 Tigani 對 scale-up 與小型隔離執行器的關注，在 agent workflow 中獲得新的理由。

但單看單次 latency 仍不夠。平台要量測整個任務的查詢次數、掃描量、失敗重試與最終答案品質。更快的錯誤 SQL 沒有價值；好的系統會先縮小 schema、使用 metadata 指引，再讓 agent 查詢，降低探索成本與錯誤面積。

DuckDB 的列式與向量化執行為何適合互動分析

分析查詢常只讀寬表中的少數欄位，再對大量值做 filter、aggregate 與 join。列式儲存讓引擎少搬不需要的欄，向量化執行則一次處理一批值，較能利用現代 CPU cache 與 SIMD。這些能力讓單一節點在適合的資料量上擁有很高吞吐，也使「先加機器」不再是唯一擴充答案。

可是列式分析不等於線上交易。頻繁單筆更新、強制唯一性與高競爭寫入仍需要交易資料庫；DuckDB／MotherDuck 比較適合分析副本、檔案與讀多工作負載。AI 平台應把 agent 的查詢型工具與真正改動業務狀態的工具分開，前者可由分析引擎加速，後者則由 system of record 驗證與提交。

協調成本會被大量小查詢放大

分散式查詢有固定成本：排程 worker、交換資料、等待慢節點、合併結果與維護共享資源。對掃描數十 TB 的任務，這些成本相對很小；對只讀幾 MB 的 agent 查詢，固定協調可能比實際計算更久。Tigani 的 scale-up 論述要求團隊先量測 working set，再選擇執行形態。

成本也不能只看每秒單價。若每次 agent 任務啟動多個 warehouse、重複掃描相同資料並因 timeout 重試，總費用會隨工具迴圈成長。比較平台時應計算每個完成答案的查詢數、CPU 時間、傳輸與失敗率；把快取、prepared data 與語意限制納入，才是完整的 agent economics。

自然語言介面更需要 semantic contract

SQL 使用者通常知道自己選了哪些欄位，agent 卻可能把「活躍客戶」「收入」或「流失」解讀成不同口徑。若資料庫只提供原始 schema，模型會根據欄名猜測。semantic contract 應為重要指標保存定義、時間區間、排除條件、owner 與可接受範例，並讓 agent 在產生 SQL 前讀取。

這些定義必須像程式碼一樣測試。團隊可以建立幾十個固定商業問題，保存預期 SQL 特徵與結果範圍，每次 schema、模型或 prompt 更新都重跑。當答案改變時，先分辨資料真的變了、指標定義改了，還是 agent 走錯 join；沒有這層契約，self-service 只會把資料誤解自動化。

本機計算與雲端治理之間的張力

把計算推到本機可以降低資料搬移和互動延遲，但企業仍需要中央權限、版本、備份與稽核。Dual execution 若沒有清楚政策，可能讓資料副本散落在筆電或瀏覽器。相反地，所有計算都強制雲端又會失去 DuckDB 的嵌入式優勢。

合理治理應定義哪些資料可下載、cache 保留多久、離線副本如何加密、查詢記錄送回哪裡，以及退出帳號後如何撤銷。架構價值來自可選擇計算位置，但選擇必須由身份與資料分類約束。

小資料論述不能被誤讀成容量上限

「Big Data is Dead」是一個用來挑戰預設的論點，不是永遠固定的產品邊界。企業可能保存 petabyte 資料，卻讓大多數互動查詢只碰小型 working set；也可能有少數批次確實需要分散式掃描。平台應同時標示熱資料、冷資料與任務型態，而不是用總容量替所有查詢分類。

這也意味 MotherDuck 不能只靠口號評估。團隊要用自己的 Parquet、join、concurrency 與資料更新模式測試，觀察本機、雲端與 dual execution 的實際計畫。當 workload 超出適合範圍，應允許與 lake、warehouse 或其他引擎共存。

從 BigQuery 到 MotherDuck 的真正連續性

表面上，BigQuery 代表極端 scale-out，MotherDuck 代表 scale-up。兩者更深的共同點是把資料引擎包裝成低操作負擔的服務。使用者不想管理 shard、worker 與容量；他們想送出查詢、共享結果並理解成本。Tigani 的方向改變，是根據硬體與工作負載重新選擇實作，不是放棄 serverless 體驗。

AI 平台也應遵循這種連續性。模型和資料引擎可以變，使用者仍需要簡單、可預測與可追責的介面。基礎設施的創新不應把複雜度轉嫁給每個應用團隊，而要把它吸收到控制平面、預設值與觀測工具中。

採用 AI analytics 架構前的實務檢查

第一，量測每次 agent 任務實際碰觸的資料量，而非只看 warehouse 總量。第二，區分本機、雲端與共享資料。第三，為每個 agent 設定唯讀角色、資源預算與 timeout。第四，保存生成 SQL、執行計畫、結果摘要與引用。第五，用固定問題集測試商業指標是否一致。

若資料主要是小型互動分析且需要嵌入應用，DuckDB／MotherDuck 路線可能大幅簡化；若工作負載是長時間全量 ETL 或高度共享的大型掃描，其他架構可能更合適。Tigani 的貢獻不是給出單一答案，而是迫使團隊先量測真正問題。

為何 Jordan Tigani 值得進入 AI／LLM 名人堂

Tigani 先參與建立 BigQuery，把分散式分析帶入 serverless 時代；之後又用相同實務經驗挑戰過度 scale-out，推動 DuckDB、本機計算、雲端共享與 hypertenancy 的組合。他的工作把資料倉儲從「能掃多大」重新拉回「多快讓使用者得到可信答案」。

在 agent 成為資料消費者後，這個轉向更具影響力。大量短查詢、自然語言介面、每使用者隔離與低延遲工具調用，要求分析引擎改變預設。Jordan Tigani 值得被記住的，是用兩代雲端資料系統經驗重畫 AI 分析層的成本與互動邊界。

官方與第一方資料

• MotherDuck：Jordan Tigani 官方作者頁
• MotherDuck：公司起源與 DuckDB 合作
• Jordan Tigani：Big Data is Dead
• Jordan Tigani：The Simple Joys of Scaling Up
• MotherDuck：Dual execution 架構
• MotherDuck：AI applications 與 hypertenancy
• Jordan Tigani：Building an answering machine