我們如何構建Cloudflare的資料平臺及其之上的AI智慧體

Cloudflare每秒處理超過十億事件，網路覆蓋120多個國家的330多個城市。每一次HTTP請求、Worker呼叫、R2讀取操作都會產生大量資料。然而，這些資料長期難以訪問——它們分散在數十個生產資料庫、ClickHouse叢集、Kafka流、Google Cloud儲存桶、BigQuery資料集以及大量管道中。要回答一個簡單問題，例如“今天註冊的域名中有多少在流量排名前100？”，分析師必須知道詢問哪個系統、使用什麼憑證、編寫什麼查詢語言，以及資料是否有采樣、是否即時或已滯後七天。結果，很難從資料中獲取有意義的洞察。

為解決這一問題，Cloudflare構建了兩個內部工具：Town Lake（統一資料分析平臺）和Skipper（執行在其上的AI資料智慧體）。Town Lake是一個單一SQL介面，可訪問Cloudflare所知的一切；Skipper使得公司內任何人都能用自然語言提問，並在幾秒內獲得正確且可審計的答案。

**問題的形態** 資料蔓延具有幾個典型症狀：系統過多、資料取樣（對儀表板沒問題，但計費等場景不適用）、內部資料依賴外部供應商、以及資料發現困難。此外，資料基礎設施過去被視為後臺職能，而非關鍵基礎設施。

**目標** 打造一個地方，讓公司內任何有許可權且需要知情的人都能獲得關於Cloudflare問題的答案。要求資料新鮮、準確、無取樣（如計費和安全調查），同時支援快速取樣資料（如儀表板）。內建安全和治理：自動檢測PII，預設鎖定敏感表，所有訪問可審計，許可權有時間限制。平臺基於Cloudflare自身產品：R2、Workers、Access、Workflows。最終，希望提供不需要SQL知識的介面。

**Town Lake平臺** 核心架構是資料湖倉：查詢引擎從物件儲存讀取，後設資料層使儲存像資料庫一樣工作。主要元件包括：

• 查詢引擎：選用Apache Trino，可跨Postgres、ClickHouse、Iceberg表聯合查詢。
• R2資料目錄：基於Apache Iceberg的託管服務，支援模式演化、時間旅行、分割槽演化及資料壓縮。
• DataHub：後設資料目錄，記錄表、列、所有者、血緣等。
• Lifeguard：訪問控制服務，從D1讀取規則，動態拉取使用者和組成員身份，生成Trino讀取的組合JSON策略。
• Skimmer：PII檢測掃描器，透過Workers AI分類列，兩遍掃描（快速分類+智慧驗證）。
• Transformer：基於Workflows的ELT引擎，使用者定義SQL轉換DAG。
• Ingestion：從運營系統到資料湖的橋樑。

**預設關閉：治理由設計保證** 傳統做法是預設開放，限制為例外。Town Lake則相反：表在被稽核之前無法查詢。新表接入時，Skimmer自動掃描並註冊為“待稽核”。稽核者快速批准或拒絕。此外，分離模式發現與資料訪問：使用者可看到表名，但未稽核列隱藏。PII預設會話級紅化，只有主動啟用才暴露。

**Skipper AI資料智慧體** 僅查詢引擎不夠，SQL仍是障礙。Skipper是對話式AI智慧體，從自然語言問題到驗證答案，基於公司實際資料和程式碼。介面為聊天框，使用者提問後，Skipper查詢表、編寫SQL、提交查詢並返回結果。支援後續追問、上下文保持、自動修正。Skipper還能打包圖表為儀表板，內部分享。所有工具透過Workers AI提供，也支援MCP伺服器。

**語境層** LLM在SQL任務中易產生幻覺。解決方案是多層語境：模式和使用後設資料、人類標註、已知查詢模板、以及執行時反饋。未來計劃包括跨表上下文視窗、主動資料發現、增強事實檢驗等。