S4 Scan
Athena scan-cost reducer
何時收回成本？
範例：Athena 掃描費用每月 $5,000
如果 Athena 掃描費用為每月 $5,000，降低 30–70% 約等於 $1,500–$3,500/月的可避免總使用費 — 不含 S4 軟體費、EC2 和工作負載差異。
透過將 S3 data-lake Parquet 重新最佳化為查詢實際讀取的佈局，將 AWS Athena 和 Redshift Spectrum scan bill 降低 30–70% — partition 和 row-group pruning、dictionary encoding、zstd、小檔案 compaction — 透過安全的 shadow-then-swap 應用，絕不改變查詢結果。
S4 Scan 從 Athena query history 學習哪些欄位被讀取、哪些 predicates 過濾資料表，然後將底層 S3 Parquet 重寫為這些查詢需要的物理佈局：hot columns first；按過濾欄位排序，使 row-group statistics 可以 prune；對 low-cardinality columns 使用 dictionary encoding；將檔案 compact 到高效大小；並用 zstd 壓縮。Athena 和 Redshift Spectrum 按從 S3 掃描的 TB 計費，因此更小、更容易 prune 的佈局會帶來直接且持續的帳單降低。安全性是產品核心 — 絕不會覆寫你的 source。
面臨挑戰
Athena 和 Redshift Spectrum 根據實際從 S3 讀取的位元組數計費（預設 $5/TB，因區域而異）。如果您的 Parquet 實體佈局與查詢的存取模式不相符，則每次查詢掃描的 S3 資料量會遠超其傳回的資料量 — 而您每月都需要為此差距買單。由於帳單是掃描位元組數的函數，因此佈局本身決定了您的成本。
運作原理
- 1
從查詢歷史紀錄中學習
它讀取您的 Glue 目錄和 Athena 查詢歷史紀錄（工作群組指標、CloudTrail），以了解每個資料表實際讀取的欄位以及用於過濾它的述詞。
- 2
寫入影子並驗證
它將最佳化後的 Parquet 寫入獨立的影子位置，並驗證查詢結果是否完全一致，精確到值、NULL、decimal 精度和時間戳記時區。
- 3
透過 Glue 進行切換，支援回滾
只有在驗證通過後，它才會重新指向 Glue 資料表的位置 — 這是目錄指標的移動，而非資料移動 — 可透過單一回滾命令撤銷。
產品亮點
設計上安全：最佳化後的資料寫入 shadow 位置，驗證查詢結果完全一致（值、NULL、小數 scale、timestamp tz）後，再透過 Glue catalog swap。支援一條指令復原。來源資料從不 in-place 修改。
提交前先看到節省額：dry-run 會基於真實資料表預測每月美元降幅，並如實歸因到 pruning、dictionary + zstd 和小檔案合併。
無 lock-in，無需看管：輸出為標準 Athena 可讀 Parquet，AMI 按 EventBridge schedule 重新最佳化，讓節省自動累積。
包含內容
- 查詢歷史分析：從歷史查詢中分析出熱門欄位、高頻述詞以及分區/排序鍵候選，並產生最佳化計畫。
- 分區和列群組剪枝：根據述詞鍵重新分區以跳過整個檔案，並對過濾欄位進行排序，以便利用 min/max 統計資訊跳過不匹配的列群組。
- 字典/RLE 編碼 + zstd：對低基數欄位進行字典編碼，並使用 Athena 可讀的標準 zstd 進行重新壓縮，以減少投影讀取的位元組數。
- 小檔案合併：將許多微小物件合併為少數大小合適的檔案，以提高 I/O 效率並改善統計資訊。
- 影子 → 驗證 → 切換與單一命令回滾：來源資料絕不就地修改，切換僅是 Glue 指標的移動。
- Dry-run 費用預測：在不寫入任何資料的情況下，報告目前與最佳化後的掃描位元組數以及月度費用差額，真實地將節省歸因於分區剪枝 / 列群組剪枝 / 字典+zstd / 檔案合併。
- 透過 EventBridge 排程的再最佳化，輸出為標準的 Athena 可讀 Parquet — 無鎖定。
適用場景
希望在不重寫任何 SQL 的情況下降低高昂的 Athena / Redshift Spectrum 掃描費用。
寬資料表場景：查詢僅讀取少數欄位並根據少數述詞過濾，卻仍需掃描整個檔案。
資料湖被大量微小的 Parquet 物件碎片化，降低了 I/O 效率並損害了統計資訊。
不斷成長的資料集，可透過基於 EventBridge 排程的定期再最佳化受益。
常見問題
這會損壞我的資料或改變我的查詢結果嗎？
來源資料絕不會就地修改。最佳化後的資料將被寫入一個獨立的影子位置，並在驗證結果完全一致 — 包括值、NULL、decimal 精度、時間戳記時區和巢狀類型 — 之後，才移動 Glue 指標。如果驗證失敗，它不會進行切換，而是丟棄影子位置並保持來源資料不受影響。切換後，只需執行單一命令即可恢復原始位置。
我會被專有格式鎖定嗎？
不會。輸出僅為標準的 Athena 可讀 Parquet（標準 zstd、字典/RLE），不使用專有 codec。您可以隨時回滾，最佳化後的資料也可以使用普通的 Athena 工具正常讀取。
S4 Scan 如何知道要最佳化什麼？
它會從您的 Athena 查詢歷史中學習 — 統計哪些欄位被讀取以及哪些述詞過濾了您的資料表 — 並推導出推薦的欄位順序、分區鍵和排序鍵。這基於真實的存取模式，而非憑空猜測。
我能在實際執行前看到可以節省多少費用嗎？
是的。dry-run 會在不寫入任何資料的情況下報告目前與最佳化後的掃描位元組數以及月度費用差額，並將節省 of 費用真實地歸因於分區/列群組剪枝、字典+zstd 以及檔案合併。宣傳的 30–70% 是一個取決於您現有佈局偏差程度的範圍 — 並非保證值 — 因此請先在您自己的資料表上執行 dry-run。
它在哪裡執行？我的資料會離開我的帳戶嗎？
它作為 AMI 在您自己的 AWS 帳戶和 VPC 內執行，僅存取您的 S3、Glue 和 Athena — 您的資料絕不會離開。它在最小權限的 IAM 角色下，基於 EventBridge 排程實現無干預自動執行。
為什麼更便宜
假設在 us-east-1 每月 Athena 掃描 100 TB, S4 Scan 透過物理佈局最佳化將掃描量減少約 60%。
- Athena 掃描 (100 TB × $5/TB)
- $500 / 月
- 月度合計
- $500 / 月
- Athena 掃描 (40 TB × $5/TB)
- $200 / 月
- S4 Scan 實例 (m5.large + 軟體費)
- $100 / 月
- 月度合計
- $300 / 月
按掃描量選擇 S4 Scan 實例
| 掃描量 | 推薦執行個體 | S4 Scan 實例費用 | 月度合計對比單獨 Athena |
|---|---|---|---|
| ~10 TB / 月 | t3.medium | $45 / 月 | $65 / 月 (Athena $50, +30%) |
| ~100 TB / 月 | m5.large | $100 / 月 | $300 / 月 (Athena $500, −40%) |
| ~1 PB / 月 | m5.2xlarge | $310 / 月 | $2,310 / 月 (Athena $5,000, −54%) |
僅供參考。Athena 使用 us-east-1 公開價格 ($5/TB 掃描)。60% 的掃描減少取決於查詢特徵和資料分佈，典型範圍為 30–70%。小規模工作負載下，S4 Scan 執行個體成本可能超過 Athena 節省，因此此產品在每月 ~50 TB 以上才顯著有效。
計費模式
按小時計費的軟體費用 + EC2（t3 / m5 class），也提供按處理 GB 付費的 offer。提供年度選項。
