摘要： Cloudflare 在 2026 年 10 月 12 日宣布 Transformers 正式可用，並把 Logpush 開放給所有自助方案。這項功能讓團隊在日誌匯出前，直接用 SQL 過濾、遮蔽與重塑資料，不必再部署一個獨立的處理服務。對每天把大量日誌推進 SIEM 或分析平台的團隊來說，這同時影響成本結構和資料治理的作法。
問題：日誌在離開邊緣之前沒有被處理的機會
Logpush 的用途是把 Cloudflare 日誌批次匯出到 SIEM、分析平台或物件儲存。過去想在匯出前做點事——刪掉健康檢查流量、遮蔽敏感欄位、為不同下游重塑 schema——你得自己跑一個處理服務，負責部署、擴展、監控和維護。
Cloudflare 在文章裡點出兩個實際痛點：一是多 CDN 團隊需要為不同來源的日誌補上統一的 provider 欄位才能進分析平台；二是被丟棄的紀錄仍然產生匯出、寫入和儲存的費用。換句話說，你為了遵守規則或省空間而丟掉的資料，一路都在花錢。
Transformers 怎麼運作
一個 Transformer 就是針對特定 Logpush dataset 寫的 SQL 查詢。WHERE 子句決定哪些紀錄被匯出，SELECT 的輸出就是匯出的紀錄本身——可以改名、嵌套、刪除欄位，也可以遮蔽 client IP 的一部分。輸出維持 NDJSON 格式。
操作上，團隊在 dashboard 的 Transformer Studio 或透過 API 建立、預覽和管理查詢，然後掛到使用同一 dataset 的 Logpush job 上。每次更新都產生新版本，可以回溯查詢的變更歷史。Free、Pro、Business、Enterprise 四種方案都能用。
工程上的取捨：留在進程內，而不是加一跳
這段對 builder 最有參考價值。Cloudflare 最初的原型是在 Cloudflare Workers 裡跑 WebAssembly 版本的轉換，但每次呼叫等於在匯熱路徑上插了一個網路呼叫，可能帶來逾時和重試。他們最後選擇把執行留在交付服務 Bufstream 的進程內，用 Apache DataFusion（Rust 寫的查詢引擎，基於 Arrow 的向量化欄式執行）直接跑 SQL。
跨 Go/Rust 邊界的資料交換用 Arrow IPC 經 cgo 完成，所有權規則很明確：Go 只在呼叫期間傳入緩衝區指標，Rust 的輸出由 Go 複製後釋放。根據 Cloudflare 的基準測試，對 5,000 列的合成 http_requests 批次執行一次 prepared query 約 3 毫秒，相當於每秒約 160 萬列。
另一個值得學的設計是 fail closed：如果轉換失敗，Bufstream 不會直接送出未轉換的原始資料，而是重試。原因很實際——送出原始資料可能違反下游對 schema、過濾和遮蔽的假設。持續失敗的 job 會被逐步延遲並最終自動停用，避免拖垮健康的 job。
為什麼這對你的架構有意義
這個功能把「資料在離開源頭前先處理」變成平台內建能力，而不是你的另一個微服務。對隱私和合規場景尤其如此：在匯出邊界就完成 redaction，代表敏感欄位從一開始就不會落地到下游系統。這和治理的第一步——先看見資料流去哪裡、誰在碰——是同一件事的兩面，相關的思路我在企業如何先看見 AI 的使用足跡一文中也討論過。
當然有邊界要記住：Transformer 只在 Cloudflare 的 Logpush dataset 上運作，SQL 能力範圍以該 dataset 的 schema 為準，也不做序列格式轉換。如果你的下游需要更複雜的邏輯，獨立處理層仍然省不掉。實際的下一步很簡單：打開 dashboard 的 Logpush 頁面，選一個 dataset、寫一句 SQL、對樣本紀錄預覽，再掛到現有 job 上——先從過濾健康檢查流量這類低風險的查詢開始，順便量一下轉換前後的資料量差異。
參考來源
在 X 上查看原貼文