AWS SageMaker Feature Store 推出新 API，破解高吞吐特徵輸入瓶頸
Amazon SageMaker Feature Store 是一套全代管、專為機器學習（ML）模型設計的特徵倉儲服務。它同時提供即時推論所需的低延遲線上服務（online serving）與供離線訓練使用的歷史資料儲存（offline store），支援串流（streaming）與批次（batch）兩種寫入模式。
然而，隨著 ML 平台日益成熟，使用者在營運上常碰到兩大痛點：
-
單筆寫入效能受限
現行的 PutRecord API 必須對每筆特徵資料呼叫一次 API，且每個特徵群組（feature group）都需要獨立呼叫。若一條詐欺偵測流水線每秒要寫入 10,000 筆資料，且跨五個特徵群組，系統必須同時處理 50,000 次 API 請求，導致連線開銷與尾端延遲急速上升，吞吐量難以滿足需求。
-
In‑Memory 層無法查詢
使用記憶體（In‑Memory）儲存層的使用者，無法列舉或搜尋已寫入的記錄。當記錄鍵值因程式錯誤或管線失敗遺失時，這些資料將永久不可復原，且缺少離線備援（offline store）或 Athena 查詢介面（Amazon Athena）來協助追蹤。
新增兩項 API：解決上述瓶頸
為回應上述需求，AWS 今日正式公布 兩項全新 API，其中 BatchWriteRecord 為本篇重點說明。
BatchWriteRecord：批次寫入、提升吞吐
- 一次可寫入最多 25 筆，且可同時針對多個特徵群組提交。
- 每筆記錄的成功與失敗互不影響，屬 partial‑success（部分成功）模式；即使部分記錄失敗，整體請求仍會回傳成功結果。
- 保留 PutRecord 的 EventTime 排序機制：只有當傳入的 EventTime（事件時間）較新時，該筆會被視為最新版本寫入線上儲存；若條件不符，仍會寫入離線儲存作為歷史版本。
- 回應僅列出 Errors（錯誤）陣列，讓開發者快速定位失敗的記錄，避免因單筆失敗而中斷整批作業。
此設計直接將「N×M」的呼叫模式（N 筆資料 × M 特徵群組）縮減為「⌈N/25⌉」次請求，大幅降低連線開銷與尾端延遲，讓每秒上萬筆的高吞吐需求變得可行。
另一項 API：支援 In‑Memory 記錄查詢
針對 In‑Memory 層無法瀏覽的問題，AWS 同時推出了 查詢/列舉類 API（具體名稱尚未公開），讓使用者能以程式方式取得已存放的記錄清單，並在鍵值遺失時進行補救。此功能為 In‑Memory 層提供了類似離線儲存的可觀測性，避免資料永久遺失的風險。
影響與未來展望
- 效能提升：BatchWriteRecord 的批次寫入機制，使得金融、電商、醫療等需要即時偵測的應用，可在不升級基礎建設的前提下，達到數十萬筆/秒的特徵更新速率。
- 資料可觀測性：新增的查詢 API 為 In‑Memory 層帶來「可見」的特性，減少因程式錯誤導致的資料遺失，提升平台的容錯與可恢復性。
- 開發者體驗：部分成功的回傳格式讓開發者只需關注失敗項目，簡化錯誤處理流程，進一步縮短模型部署與迭代的時間。
未來，隨著 AWS 持續擴充 Feature Store 的功能，預期會出現更多針對資料治理（data governance）與安全合規（security compliance）的原生支援，讓企業在建置大規模機器學習管線時，能同時兼顧效能、可靠性與治理需求。
讀者啟示：若您正面臨特徵管線的高吞吐挑戰，建議立即評估 BatchWriteRecord 的整合方式，並利用新推出的查詢 API 檢視 In‑Memory 層的記錄狀態，從而在不犧牲即時性與資料完整性的前提下，提升整體 ML 工作流的效率與韌性。