摘要： Cloudflare 在 2026 年 10 月 12 日宣布 Transformers 正式可用，把 SQL 過濾、遮蔽和欄位重塑直接嵌進 Logpush 的匯出管線。過去這些工作要靠自架一個處理服務，現在在匯出前就完成。對 builder 來說，實際意義是下游儲存量、SIEM 費用和接手資料的形狀，都變成一句 SQL 可以控制的事。
為什麼日誌轉換值得往前移
用 Logpush 匯出日誌的團隊，通常會在資料抵達 SIEM、分析平台或物件儲存之後，才把健康檢查流量、敏感欄位或不需要的記錄清掉。問題是這些被丟棄的記錄，在匯出、攝入、儲存三個環節都已經付過錢了。資料量愈大，這筆浪費愈明顯。
Transformers 的做法是把處理點移到匯出之前。你為特定 Logpush 資料集寫一段 SQL：WHERE 子句過濾記錄，SELECT 決定輸出的欄位，可以重新命名、巢狀化、遮蔽客戶端 IP 的一部分，或加上像 provider 這種靜態欄位來統一多家 CDN 的日誌格式。每個目的地拿到的就是它需要的形狀，不用再接一層自建的處理服務。
執行細節：他們沒有選 Workers
這篇公告裡最值得工程師細讀的，是 Cloudflare 對執行位置的取捨。據 Cloudflare 部落格的說明，最早的原型跑在 Cloudflare Workers 裡，用 WebAssembly 執行客戶定義的轉換。但呼叫 Worker 等於在匯出的熱路徑上插入一次網路呼叫，短暫逾時和重試會拉低吞吐量。
最後的設計是把 SQL 執行留在交付服務 Bufstream 的行程內，選用 Apache DataFusion——一個建在 Apache Arrow 上的 Rust 查詢引擎。他們的基準測試顯示，對一批 5,000 列的合成 HTTP 請求日誌執行 prepared transformer 約花 3 毫秒，大約相當於每秒 160 萬列。考慮到 Bufstream 每秒要交付超過一億筆 Logpush 記錄，這種可預測性是硬需求，不是加分項。
跨 Go 和 Rust 的邊界用 Arrow IPC 走 FFI：Go 把輸入緩衝區的指標只在 cgo 呼叫期間交給 Rust，Rust 不保留指標，輸出由 Go 複製後明確釋放。所有權被寫死在介面上，避免跨執行環境的記憶體管理事故。這種「在邊界上把規則講清楚」的設計思路，和先前我們討論 Cloudflare 網路效能測量時看到的嚴謹程度是一致的（見 把測量點搬進 Challenge Pages：Cloudflare 的網路效能數字是怎麼來的）。
失敗時寧可不送，也不送原始資料
一個容易忽略但很關鍵的決定：Transformers 是 fail-closed 的。如果轉換執行失敗，Bufstream 不會推進交付位移，也不會把未轉換的原始批次送出去——因為原始資料可能違反下游管線對 schema、過濾或遮蔽的假設。失敗會用漸進式延遲重試，長期失敗的 job 會自動停用。
對做合規或資料外洩防護的團隊，這個行為比效能數字更重要：你依賴的遮蔽規則，不會在系統異常時靜默失效。
動手試的路徑很短
操作上只需要四步：在 Logpush 頁面打開 Transformer Studio，選資料集，寫 SQL 並對樣本記錄預覽，儲存後附加到相容的 NDJSON Logpush job。每次更新都會建立新版本，可以回溯查歷史。Transformers 開放給 Free、Pro、Business 和 Enterprise 所有方案，定價細節要另外查 Logpush pricing 文件。
一個務實的提醒：Transformers 不做序列化格式轉換，輸入輸出都是 NDJSON，而且只對相同資料集的 job 生效。如果你的下游需要的不只是過濾和重塑，那層自建處理仍然省不掉。
參考來源
在 X 上查看原貼文