摘要： Cloudflare 的 Data 團隊負責把全球網路資料送進中央資料中心，面對的是每年指數成長的流量對上線性成長的硬體。他們在過去五年做了一系列架構調整，累計效果相當於推遲了兩年半的硬體擴充。對任何在規模化資料管線的團隊來說，這是一份少見、把每一步的成本數字攤開來的實戰記錄。
問題的本質：指數對線性
超過兩成的網站在 Cloudflare 網路後面，這些資料支撐著 Cloudflare Logs、SQL API、observability 與內部分析。到了今年五月，資料傳輸量已達每秒約二十億個事件。硬體預算不會每年翻倍，所以唯一的出路是在管線本身找回效率。
拆掉單一 schema：省下 35-40% 骨幹頻寬
2022 年之前，所有產品的資料共用一個巨型 schema，每個消費者都得吞下全部欄位再自行過濾。Cloudflare 的假設很簡單：沒有團隊需要 100% 的欄位。改成按產品拆分小訊息後，即使某些欄位重複出現，骨幹頻寬仍下降了 35-40%，等於抵消掉約一年的壓縮流量成長。
從 LZ4 換到 zstd：同一條管線多撐 1.5 倍流量
2024 年，團隊面對每天的網路擁塞，決定把壓縮演算法從 LZ4 換成 zstd。早期實驗時 zstd 的 CPU 用量偏高，所以他們先在少數伺服器上線並盯緊指標，確認沒有明顯影響後才逐步推到全 fleet。結果是壓縮後流量吞吐減少近 40%——未壓縮位元組照樣成長，但同一條管線能承載超過 1.5 倍的流量，約等於把時間線拉回十個月之前。
延後複製：把雙寫從源頭搬到下游
為了災難備援，分析資料過去在源頭就雙寫到兩個中央區域，每個區域各自跑完整份流程。當幾乎所有分析串流都要備援時，廣域傳輸量直接翻倍。Cloudflare 的解法是把「管線傳輸」和「資料庫備援」脫鉤：每個事件只發送一次到共享接收池，抽樣之後才在下游複製到另一個資料中心。
這個順序帶來兩個紅利：複製發生在抽樣之後，而且資料集中後能切成更整齊的批次，壓縮率更高。已遷移的資料集削減了約 43 GB/s 的壓縮傳輸，只增加約 7 GB/s 的跨資料中心複製，淨省 36 GB/s。
在源頭抽樣、在每一步聚合
另外兩招是把處理往前推。抽樣原本只在中央接收器做，現在 Logfwdr 在源頭就先抽一次：按 key 分組、打亂消除偏差，取平方根大小的樣本，再按抽樣率還原估計值。對前三大的資料集，這讓傳輸量至少減半，合計 25 GB/s——超過每天 2 PB。「最少見」的 key 細節不變，「最常見」的 key 則被雙重抽樣有效壓制。
聚合也從管線尾端搬到每個環節：Logfwdr 先聚合、接收器再聚合、inserter 批次讀取時再聚合，最後由 ClickHouse 的 aggregating table engines 收尾。光 HTTP 資料集一個，壓縮流量就從 9+ GB/s 降到 2 GB/s 以下。
Builder 該帶走什麼
這篇文章最值得學的不是任何單一技術，而是那個心法：架構上的順序調整——先抽樣再複製、先聚合再傳輸——往往比換硬體省得多。這和 Cloudflare 在 Logpush Transformers 上把 SQL 過濾前置到匯出熱路徑的思路一脈相承，我在先前那篇也提過：能早一步處理的資料，就別拖到付費的下游。
限制也要說清楚：抽樣與聚合都是精確度與彈性的交換——抽樣換來近似答案，聚合則要求你事先固定維度與指標。Cloudflare 選擇針對不同資料集混用兩者。如果你的管線還小，這些優化可能還不急；但等流量曲線開始彎起來時，先問自己一句：哪些處理，我可以再往前推一步？