題目與適用場景
你負責 OLAP 執行引擎中的 GROUP BY。輸入規模與基數不穩定，聚合狀態可能超過記憶體。請說明如何避免查詢在臨界點突然失敗或出現效能斷崖，並給出驗證方法。
本文適合資料工程、查詢執行引擎與資料庫核心職位。假設聚合是阻塞運算子，必須讀完輸入才能輸出；不假設輸入已依分組鍵排序。
面試官考察什麼
- 能否解釋雜湊聚合通常是記憶體內首選，以及為何它不容易直接溢寫。
- 能否把記憶體管理、頁面配置、平行合併與 I/O 背壓放進同一個執行模型。
- 能否區分「估算後切換演算法」與「執行期自適應」的失敗邊界。
- 能否用可重現實驗證明吞吐量、峰值記憶體與尾端延遲，而非只背產品名詞。
回答前要釐清的問題
- 分組鍵基數與聚合狀態大小上限是多少？沒有上限就必須設計溢寫路徑。
- 儲存媒介與可接受查詢延遲為何？本地 NVMe、網路磁碟與物件儲存不能使用同一個 I/O 假設。
- 是否要求精確結果？近似聚合可用 sketch，但會改變題目約束。
- 是否允許結果重新排序？允許時可比較排序聚合；禁止時需維持雜湊路徑的輸出語意。
30 秒回答框架
「我先把 GROUP BY 視為阻塞運算子，依分組狀態與記憶體預算建立基線。記憶體足夠時使用平行雜湊聚合；接近預算時，不重啟查詢或突然切換成完全不同的磁碟演算法，而讓同一套頁面化狀態在記憶體與儲存裝置間漸進溢寫。緩衝管理器負責淘汰與載回，執行緒先 sink 再 combine，最後 finalize 與輸出。驗證時逐步增加基數，觀察峰值記憶體、溢寫量、吞吐量與失敗率，並保留排序聚合作為低基數或已排序輸入的替代方案。」
逐步深入解法
1. 先建立狀態預算
估算每個分組的鍵、計數器、雜湊中繼資料與對齊開銷，再乘上預期基數。預算必須包含頁面目錄、暫存緩衝與平行執行緒的區域狀態。只用輸入位元組估算會漏掉高基數造成的狀態膨脹。
2. 選擇統一的頁面化狀態
把聚合狀態放入可定址頁面。頁面在記憶體時使用適合 CPU 存取的配置，壓力升高時由統一緩衝管理器寫入儲存裝置；載回時恢復頁面位址或偏移。如此不需把整個運算子序列化成另一種格式，也不會因單一資料列超過預算而重啟查詢。
3. 處理平行階段與背壓
平行執行可分成 sink、combine、finalize、get-data：執行緒先累積區域狀態，再合併頁面參照，最後由一次 finalize 決定輸出。溢寫必須受緩衝管理器與 I/O 佇列背壓控制，否則更多執行緒只會製造隨機寫入放大。對熱門分組鍵要記錄偏斜，必要時拆分大頁或限制單一分組狀態。
4. 比較替代方案
若輸入已依分組鍵排序，可使用幾乎不需保存全部狀態的串流聚合；低基數且狀態穩定時，純記憶體雜湊最快。排序聚合適合可接受排序成本、需要有序輸出或雜湊狀態容易偏斜的場景。預估後在執行中突然切換磁碟演算法，會讓單一新增分組觸發不可預測的效能斷崖。
5. 設計可重現驗證
固定輸入寬度，逐步放大唯一分組數，使狀態從記憶體內跨過預算。記錄各階段吞吐量、峰值 RSS、讀寫位元組、溢寫頁數、載回次數與 p95 延遲。重複熱快取與冷快取實驗，並注入 I/O 限速；正確性以獨立排序聚合結果校驗，不能只比較執行時間。
高品質示範回答
我會先確認這是精確的阻塞聚合，且分組狀態可能超過記憶體。基線方案是平行雜湊表，但我會把狀態放進統一的頁面化緩衝管理器：記憶體緊張時淘汰冷頁到儲存裝置，載回後繼續使用同一個邏輯結構。執行緒依 sink、combine、finalize、get-data 協作，I/O 佇列設定背壓，避免並發把儲存裝置打滿。輸入已排序時改用串流聚合，低基數時保留純記憶體雜湊。最後用逐步增加基數的熱冷快取實驗，驗證精確結果、峰值記憶體、溢寫量與 p95 延遲，確認跨過預算時效能平滑退化而不是突然失敗。
常見失分點
- 錯誤表現：只說「記憶體不夠就落盤」。失敗原因：沒有說明頁面配置、載回、並發與背壓，無法判斷是否會產生隨機 I/O 放大。修正方法：給出統一緩衝管理與階段邊界。
- 錯誤表現：依賴基數估算，超限後重啟查詢。失敗原因：估算誤差會把臨界資料變成效能斷崖。修正方法：說明執行期漸進溢寫與不重啟的路徑。
- 錯誤表現：聲稱雜湊聚合永遠優於排序聚合。失敗原因：已排序輸入、低基數與嚴重偏斜會改變結論。修正方法：明確說明替代方案的適用條件。
- 錯誤表現：只報告平均吞吐量。失敗原因：溢寫通常先影響尾端延遲與失敗率。修正方法：同時報告峰值記憶體、I/O、p95 與正確性。
追問深入
儲存裝置延遲突然升高怎麼辦？
降低新執行緒進入 sink 的速率，擴大可觀測的 I/O 佇列水位並優先保留熱門頁面。若仍無法符合 SLO，應回報資源不足，而不是無限堆積記憶體。
單一分組鍵佔據大部分狀態怎麼辦？
將該鍵的聚合狀態拆成可合併的分片，限制單頁大小，並在 finalize 階段合併。若聚合函式不可分解，就必須明確降低平行度或拒絕該計畫。
什麼時候改用排序聚合？
輸入已有排序保證、需要有序輸出，或雜湊狀態的隨機存取成本超過排序與順序掃描成本時，排序聚合更合適。回答時要指出排序的暫存空間也可能溢寫。
如何證明沒有效能斷崖？
以同一資料集逐級提高基數，繪製資料規模與延遲曲線；在記憶體預算附近檢查是否只有平滑斜率變化，並對比直接切換磁碟演算法的曲線。報告硬體、快取狀態與 I/O 限制。
結果頁也放不進記憶體怎麼辦？
讓下游使用串流 get-data，或把最終結果依頁面輸出到暫存關係，再由消費者順序讀取。不要為了「回傳結果」重新建立一個不受預算控制的巨大陣列。