我們如何構建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任務中易產生幻覺。解決方案是多層語境：模式和使用元數據、人類標註、已知查詢模板、以及運行時反饋。未來計劃包括跨表上下文窗口、主動數據發現、增強事實檢驗等。