題幹與適用場景
你負責一條本地分析任務，DuckDB 讀取 Parquet 後執行多表 JOIN、GROUP BY 和視窗函式。資料量增長後，任務要麼報 Out of Memory，要麼在暫存目錄產生大量檔案並逾時。請說明排查順序、參數調整、SQL 改寫和驗證方法。
適用場景包括資料工程、分析工程和嵌入式 OLAP 面試。回答應圍繞可觀測證據展開，不能只說「加記憶體」或「換更大的機器」。
面試官考察點
- 能否區分串流執行與需要保留大量狀態的阻塞算子。
- 能否用執行計畫、執行時剖析和記憶體指標定位峰值，而不是憑感覺改參數。
- 是否理解執行緒數、記憶體上限、溢寫目錄和插入順序設定的關係。
- 是否會同時檢查暫存磁碟、權限、資料型別、索引和 JOIN 結果膨脹。
- 是否把正確性、可重現性和回歸效能納入調校閉環。
回答前需要釐清的問題
- OOM 發生在掃描、JOIN、聚合、排序還是視窗階段？是 DuckDB 主動報錯，還是作業系統終止程序？
- DuckDB 版本、執行緒數、
memory_limit、暫存目錄位置和可用磁碟空間是多少？ - 輸入是否來自 Parquet/CSV，欄位型別和分割配置如何？篩選條件能否下推？
- 查詢是否有高基數 GROUP BY、精確 DISTINCT、寬 JOIN、ORDER BY、視窗、
list/string_agg或 PIVOT？ - 結果是否允許分批、預聚合、近似聚合或改變輸出順序？
30 秒回答框架
我先確認是哪個算子和哪一種資源耗盡，再用 EXPLAIN ANALYZE、記憶體快照和暫存目錄指標建立基線。若是高基數聚合、JOIN、排序或視窗造成的阻塞狀態，我先減少掃描列和資料列、修正篩選與連接條件，再降低並行度、設定合理記憶體上限並確認可用溢寫目錄。最後用固定樣本和全量校驗比較筆數、鍵唯一性、聚合結果與延遲，確保調校沒有改變語意。
分步驟深入解答
1. 先區分記憶體錯誤與暫存磁碟故障
記錄錯誤文字、程序退出原因、峰值 RSS、DuckDB 版本、執行緒數和查詢指紋。DuckDB 預設把一部分可用記憶體作為上限，但作業系統 OOM、容器限制、暫存目錄不可寫或磁碟已滿，都會呈現相似症狀。先驗證 cgroup/容器限制、磁碟容量與權限，再決定是否調 SQL。
2. 從執行計畫找到阻塞算子
用 EXPLAIN 查看連接順序、篩選是否下推，用 EXPLAIN ANALYZE 查看實際資料列、耗時和每個算子的執行狀態。掃描通常按區塊串流處理；GROUP BY、JOIN、ORDER BY、視窗和精確 DISTINCT 需要保留雜湊表、排序緩衝或視窗框架，基數上升時會形成峰值。若出現連接鍵錯誤導致資料列乘法，先修復語意再談記憶體。
3. 先縮小工作集，再調資源
只讀取必要欄位，盡早加入分割區和時間篩選，避免在子查詢中先建立全量寬表。把可重用的高成本事實做分割區預聚合；將明顯的多對多 JOIN 拆成帶唯一性檢查的步驟。高基數精確統計不能任意換成近似演算法，必須先確認業務誤差邊界。
4. 設定並驗證執行緒、記憶體和溢寫
執行緒越多，多個算子可能同時持有狀態；在受限主機上可以先降低 threads。memory_limit 要低於容器可用記憶體，保留系統餘量；只提高上限會把問題推遲到系統 OOM。需要溢寫時，確認暫存目錄在本地高速磁碟、可寫且有足夠額度。可用以下設定做一次受控實驗：
SET threads = 4;
SET memory_limit = '4GB';
SET temp_directory = '/var/tmp/duckdb_swap';
SET preserve_insertion_order = false;
EXPLAIN ANALYZE
SELECT customer_id, date_trunc('day', event_time) AS day, sum(amount) AS total
FROM read_parquet('events/*.parquet')
WHERE event_time >= DATE '2026-01-01'
GROUP BY customer_id, day;只有在業務不依賴輸入順序時，才能關閉 preserve_insertion_order。索引和某些中間狀態不一定由緩衝管理器統一管理，不能把 memory_limit 當作所有記憶體的硬護欄。
5. 識別溢寫和算子限制
溢寫能處理很多大型 GROUP BY、JOIN、排序和視窗情境，但會增加 I/O。多個阻塞算子串聯、超大的列表聚合、string_agg、某些 holistic aggregate 和 PIVOT 可能仍需要大量不可分割狀態。若暫存目錄增長異常，檢查 temp_directory、max_temp_directory_size、磁碟吞吐和清理策略；溢寫不可用時應回到分批讀取或 SQL 重寫。
6. 用結果與效能雙重回歸收口
固定輸入快照，比較調校前後的總筆數、主鍵集合、NULL 分布、分組計數、金額校驗和以及抽樣明細。記錄峰值記憶體、暫存位元組數、掃描位元組數、耗時和失敗率。對邊界日期、空分割區、重複鍵和極端高基數樣本單獨驗證，避免只在平均資料上看到成功。
高品質示範回答
我會先把問題歸類為算子狀態、配置資源或外部環境三類。第一步保存版本、查詢、輸入快照、容器記憶體和暫存盤證據，用 EXPLAIN ANALYZE 定位實際峰值。若是高基數 GROUP BY、錯誤的多對多 JOIN、排序或視窗，我先檢查基數和篩選下推，減少欄位和資料列，必要時分割區預聚合；不會用增大 memory_limit 掩蓋連接膨脹。
接著在受控環境把執行緒數降到可承受範圍，給 memory_limit 留出系統餘量，並把 temp_directory 放到容量和權限都明確的磁碟。只有輸入順序不屬於業務語意時才關閉 preserve_insertion_order。我會記錄記憶體峰值、溢寫量和耗時，確認暫存檔沒有超過額度。對於無法有效拆分的列表聚合、超大字串聚合或 PIVOT，我會改成分階段結果或重新評估查詢形狀。
最後用固定樣本和全量資料比較筆數、鍵唯一性、聚合校驗和、邊界分割區及 NULL 行為，再決定是否上線。這樣既能證明 OOM 消失，也能證明結果語意沒有被「調校」改變。
常見錯誤
只增加 memory_limit
沒有先確認容器限制、系統餘量和非緩衝管理記憶體，可能從 DuckDB OOM 變成作業系統 OOM。
把所有算子都當成可溢寫
應確認具體算子和版本支援；某些列表、字串、holistic 聚合與 PIVOT 仍可能需要不可分割的記憶體狀態。
忽略 JOIN 基數和篩選下推
連接鍵不唯一或篩選太晚會製造數量級更大的中間結果，參數調整無法修復錯誤的查詢形狀。
只看查詢成功，不做結果回歸
關閉順序保持、拆分聚合或改用近似演算法都可能改變語意，必須用固定樣本和業務校驗比較。
追問及應對
追問一：為什麼降低執行緒數可能有效？
並行執行的算子會同時保留狀態和緩衝，降低執行緒數可降低峰值，但通常會犧牲吞吐。應以峰值記憶體和完成時間的實測曲線確定值，而非固定套用。
追問二：暫存目錄有空間，為什麼仍然 OOM？
不是所有狀態都能拆分溢寫；不可分割的聚合、過大的連接狀態或暫存目錄權限/額度問題仍會失敗。要結合計畫、算子限制和錯誤日誌判斷。
追問三：什麼時候可以關閉插入順序保持？
只有結果不依賴輸入順序、下游也不把順序當作契約時。關閉後應在回歸中驗證重複鍵、排序和 LIMIT 相關行為。
追問四：怎樣證明調校沒有改變結果？
使用同一輸入快照，比對筆數、主鍵集合、分組計數、數值校驗和、NULL 分布及邊界分割區；對近似聚合則明確誤差預算並取得業務認可。