資料工程面試：如何設計可治理的 Arrow Flight SQL 服務？
題幹與適用場景
多個分析客戶端需要存取不同 SQL 引擎。現有 JDBC/ODBC 鏈路在大型結果集上產生列欄轉換和連線池壓力，團隊考慮用 Arrow Flight SQL 提供欄式傳輸。請設計從 SQL 請求到 Flight 資料流的服務，說明中繼資料、結果端點、驗證、背壓、取消、稽核和資源隔離。
面試官考察點
- 是否理解 Flight SQL 在 Flight RPC 和 Arrow 記憶體格式之上的職責邊界。
- 是否能區分 GetFlightInfo、GetSchema、DoGet、DoPut 和 DoAction 的用途。
- 是否設計查詢句柄、結果分片、流控、取消和失敗重試。
- 是否處理 SQL 權限、多租戶資源、敏感欄位和稽核。
- 是否說明 JDBC/ODBC 相容層、版本協商和可觀測性。
回答前需要釐清的問題
- 客戶端主要是互動查詢、批次匯出還是串流寫入？
- 單次結果大小、並行查詢數、允許的首位元組延遲和租戶配額是多少？
- 後端資料庫是否都支援 Arrow 原生執行，還是需要閘道轉換？
- 是否需要 OAuth、mTLS、行列級權限和跨區域存取？
- 取消查詢時要回收哪些資料庫、記憶體和物件儲存資源？
30 秒回答框架
「我會把服務分成驗證與租戶策略、SQL 規劃器、Flight SQL 協定適配和結果串流閘道。客戶端先用 GetFlightInfo 取得查詢句柄與資料端點，再透過 DoGet 拉取 Arrow RecordBatch；中繼資料走 GetSchema，寫入或參數化操作按協定使用 DoPut 或 Action。閘道限制掃描、並行和結果保留時間，把下游流控傳回資料庫執行器，並支援取消。每個句柄綁定身分、策略、查詢版本和稽核記錄，敏感欄位在計畫階段裁剪，跨引擎差異透過能力協商暴露。」
分步驟深入解答
1. 劃分協定與執行邊界
Flight SQL 定義 SQL 中繼資料、查詢和預處理語句的 Protobuf 命令，重用 Flight 的 GetFlightInfo、GetSchema、DoGet 等 RPC。閘道負責身分、策略、生命週期和流控，資料庫適配器負責把邏輯計畫翻譯成具體 SQL 與 Arrow 批次。
2. 設計查詢生命週期
收到查詢後先驗證、解析租戶和能力，再產生不可猜測的 query handle。GetFlightInfo 回傳 schema、端點和過期時間；DoGet 按端點讀取 RecordBatch。句柄狀態至少包括 planned、running、draining、cancelled、failed 和 expired，避免客戶端重試產生重複執行。
{
"queryHandle": "q_7f2a",
"schemaVersion": 3,
"endpoints": [{"ticket": "t_01", "location": "grpc://flight-2"}],
"expiresAt": "2026-08-01T13:00:00Z",
"cancelToken": "c_7f2a"
}3. 處理欄式結果與背壓
執行器按目標批次大小產生 RecordBatch，閘道依 DoGet 消費速度控制預取和記憶體水位。不要把整個結果物化在閘道；慢客戶端進入暫停或落盤策略。跨節點傳輸時，端點可指向擁有分片的 worker，閘道仍驗證 ticket、租戶和過期時間。
4. 設計取消、失敗與重試
取消令牌同時映射到資料庫 cancel、worker 串流和物件儲存暫存檔。網路中斷時，只有帶冪等句柄的讀請求允許從未確認批次重試；寫操作必須使用明確交易或 Action 語義，不能靠客戶端重複 DoPut 猜測是否成功。失敗回應包含可分類狀態和追蹤 ID，不洩露 SQL 或敏感資料。
5. 做權限與多租戶治理
驗證可採用 mTLS、OAuth 或 Flight 的授權標頭，但憑證只在 TLS 通道中傳遞。策略層將使用者、角色和租戶映射到資料庫身分、允許的 catalog/schema/table、行列過濾和最大資源。查詢計畫階段做欄位裁剪與參數綁定，禁止把使用者 SQL 直接拼進管理員連線。
6. 建立可觀測性與相容層
記錄 query handle、租戶、資料庫、計畫版本、批次數、位元組數、首批延遲、取消原因和資源峰值。指標按租戶與引擎分層，日誌不寫入原始資料。對 JDBC/ODBC 客戶端提供驅動適配，但明確 Flight SQL 與這些 API 的語義差異；透過 GetSqlInfo、GetCatalogs 等能力查詢支援範圍。
高品質示範回答
「Flight SQL 服務的核心是把 SQL 語義和 Arrow 欄式資料流結合起來。客戶端先透過 GetFlightInfo 得到 schema、ticket、端點和過期時間，再用 DoGet 拉取 RecordBatch；閘道在規劃階段完成身分、租戶、行列策略和資源預算。結果不整批物化，按批串流並把下游背壓傳回執行器，慢客戶端可暫停或落盤。取消令牌要同時終止資料庫、worker 和暫存檔；讀請求可憑冪等句柄重試，寫請求必須明確交易語義。所有查詢有稽核和追蹤 ID，並透過能力協商處理不同資料庫與 JDBC/ODBC 客戶端。」
常見錯誤
- 把 Flight SQL 當成普通 HTTP JSON API → 遺失欄式批次和端點語義 → 按 Flight SQL RPC 生命週期設計。
- 閘道快取完整結果 → 大型查詢耗盡記憶體 → 批次串流並傳播背壓。
- 只在連線層驗證 → 行列權限和租戶隔離缺失 → 在查詢計畫階段執行策略。
- 所有斷線都從頭重跑 → 資料庫壓力和重複寫入增加 → 讀用句柄重試，寫用交易或 Action 語義。
- 忽略能力差異 → 客戶端以為所有 SQL 特性都可用 → 透過 GetSqlInfo 等中繼資料協商。
追問及應對
為什麼 GetFlightInfo 和 DoGet 要分開？
GetFlightInfo 回傳 schema、ticket、端點和執行資訊，DoGet 負責實際資料流。分開後可以把結果分片放到不同 worker，並讓客戶端按端點並行或延遲讀取。
如何限制一個租戶的慢查詢？
在規劃階段設定掃描位元組、並行、記憶體和 wall-clock 配額；執行中持續採樣並在超限時取消或降級。配額計費按租戶和資料庫引擎分別統計，避免大租戶擠占共享 worker。
DoPut 的重試會不會重複寫入？
會有風險。寫入必須帶交易 ID、批次序號和冪等約束，伺服器明確提交點與重試結果；無法確認提交狀態時回傳待核對狀態，而不是盲目重放。
為什麼不直接讓客戶端連線資料庫？
直連難以統一權限、稽核、限流和跨引擎能力，也會暴露資料庫網路邊界。Flight SQL 閘道集中這些控制，同時保留 Arrow 原生資料通道的效率。