資料與儲存 2026 年 10 月 5 日

2026-10-05 — Cloudflare Basin GA,查詢補上 JOIN

primary=https://blog.cloudflare.com/cloudflare-basin/

Cloudflare Data Platform 正式 GA 並改名 Basin,查詢層補齊 JOIN 與視窗函式

Cloudflare Blog · 2026-10-01

Cloudflare 把去年 Birthday Week 發表的 Data Platform 推到 GA,並統一改名為 Basin,取代原本分散的 Pipelines、R2 Data Catalog、R2 SQL 三個品名。它在 R2 物件儲存與 Apache Iceberg 上提供一條「收資料、管表、下 SQL」的 serverless 流程,用來取代自己拼 S3、Athena 與 Spark 維護作業的做法。

這項公告由 Marc Selwan 與 Micah Wylde 在 2026 年 10 月 1 日發表,原文說明現有 Pipelines、R2 Data Catalog、R2 SQL 的設定會繼續運作。

原本的問題

湖倉(lakehouse)常見的痛點是資料與計算綁在同一家雲:資料放在 S3,換個區域或換個引擎讀取就要付出站流量費。另一個痛點是 Iceberg 表要自己維護,小檔案越積越多,需要另外排程一個 Spark 作業做壓縮與清理。

Cloudflare 的切入點是 R2 沒有 egress 費用。文中的邏輯是:既然能自由讀取,就能把資料留在 R2,用 PyIceberg、DuckDB、Snowflake、Apache Spark 等任何相容 Iceberg 的引擎去讀寫,不必被單一廠商鎖住。

改名對照與三個元件

舊名新名職責
Cloudflare PipelinesBasin Pipelines收事件、以 SQL 轉換、寫入 Iceberg 表或 R2 檔案
R2 Data CatalogBasin Catalog託管 Iceberg REST catalog 並自動維護表
R2 SQLBasin SQL在 Iceberg 表上做分散式查詢

建立 catalog 只要一行指令:

npx wrangler basin catalog create CATALOG_NAME

Pipelines:在寫入前先過濾與去識別

Pipelines 接受 HTTP 端點或 Workers binding 的事件,用 SQL 轉換後寫入 Iceberg 表,或寫成 JSON、Parquet 檔案。文中舉的常見用法是處理 Cloudflare HTTP 日誌,只留錯誤請求並把 IP 雜湊:

INSERT INTO http_logs_sink
SELECT EdgeResponseStatus,
       to_timestamp_micros(EdgeStartTimestamp) AS event_time,
       upper(ClientRequestMethod) AS method,
       sha256(ClientIP) AS hashed_ip
FROM http_logs_stream
WHERE EdgeResponseStatus >= 400;

GA 版的 Pipelines 單一 stream 可吃到 3GB/s。Workers binding 變成 schema-aware,wrangler types 會依 stream schema 產生 TypeScript 型別,欄位缺漏或型別不符可在部署前抓到。被丟棄的事件在 dashboard 與 GraphQL API 會依缺欄位、型別不符、解析失敗、null 值分類顯示,整條 ingestion 路徑也有 Terraform resource 可管理。

Catalog:把 Spark 維護作業內建

Basin Catalog 的重點是自動維護,文中列出四項:

  • 每表壓縮策略:依各表存取模式設定目標檔案大小。
  • 自動 snapshot 過期:依保留政策移除舊 snapshot,並保留最少數量的近期 snapshot。
  • 無引用資料檔清理:snapshot 過期後回收儲存空間,不需另跑 Spark 維護作業。
  • Manifest 最佳化:壓縮前先依分區合併零碎 manifest,減少查詢規劃的 metadata I/O。

SQL:從過濾掃描走向可做報表

beta 階段的 Basin SQL 擅長過濾與探索事件、時序表。GA 版涵蓋 GROUP BY、HAVING、CTE、各種 JOIN(inner、outer、semi、anti)、集合運算,以及視窗函式、QUALIFY、grouping sets、rollup、cube,並有超過 190 個純量與聚合函式。引擎利用 Catalog 產生的統計資訊把查詢拆成小任務,分散到 Workers 執行。

因此原本需要匯出到別的引擎才能做的「JOIN、聚合、排名後取前 N」現在可在單一查詢完成:

SELECT *, rank() OVER (PARTITION BY plan ORDER BY events DESC) AS activity_rank
FROM account_activity
QUALIFY rank() OVER (PARTITION BY plan ORDER BY events DESC) <= 10;

影響範圍

文中提到 Cloudflare 自己的帳務與基礎設施團隊在 beta 期間就已採用,用於長期儲存與報表計費指標,以及基礎設施遙測的使用率分析,並說明使用者已建立數萬條 Pipelines。

如果你現在用 S3 加 Athena 跑事件分析,或把 Cloudflare Logpush 日誌丟進外部倉儲,Basin 是可評估的替代,文中引用 Anomaly 共同創辦人說明已用它取代 AWS S3 與 Athena 的組合。評估時要檢查:自己的查詢是否用到 Basin SQL 尚未涵蓋的語法(文中列為進行中的完整 DDL 與 Iceberg V3 的 VARIANT、地理型別)。

已經在用舊名稱的人不必急著改設定,但 wrangler 指令、Terraform 與文件搜尋關鍵字會逐步轉向 Basin 命名。計費採用量計價,只在 ingest、處理或查詢時計費,沒有按小時或獨立基礎設施費用;具體價格與限制文章未列,需看 Basin 文件。

另外,Pipelines 的有狀態處理(串流聚合、join、增量更新的 materialized view)、自訂分區與 schema 遷移仍在規劃中,需要這些能力的串流場景目前還不能直接搬過來。

原始來源:Cloudflare Blog:Introducing Cloudflare Basin


End of article
0
Would love your thoughts, please comment.x
()
x