對於許多快速成長的工程團隊來說，最頭痛的往往不是沒有數據，而是數據散落在太多地方。當你的公司同時使用 Postgres 做交易紀錄、ClickHouse 處理日誌、Kafka 跑實時流、BigQuery 做大數據分析，且還有大量文件存在物件儲存（Object Storage）時，想要回答一個簡單的業務問題（例如：某客戶的帳單異常是否與其安全設定變更有關），工程師可能得在四五個系統之間切換，手動匯出 CSV 再用 Excel 彙整。
Cloudflare 面臨的正是這種數據碎片化（Data Fragmentation）問題。他們在全球 120 個國家、330 多個城市處理每秒超過 10 億次的事件，產生了極其龐大的數據量。為了打破數據孤島，Cloudflare 開發了名為 Town Lake 的統一數據平台，以及一個名為 Skipper 的 AI 數據代理。
Town Lake 的核心目標是建立一個統一的 SQL 介面，讓使用者不需要將數據在不同系統間搬來搬去（Data Movement），就能直接進行跨庫查詢。在技術實作上，他們採用了 Lakehouse（湖倉一體）架構。這種架構結合了數據湖（Data Lake）的低成本儲存能力與數據倉庫（Data Warehouse）的高效查詢與管理能力。
Town Lake 的技術棧主要由以下組件構成：Apache Trino 作為分散式 SQL 查詢引擎，負責接收請求並將其分發到不同數據源；Apache Iceberg 作為表格式（Table Format），讓儲存在物件儲存中的大數據能像資料庫表格一樣被管理與查詢；Cloudflare R2 則提供底層的物件儲存；最後使用 DataHub 進行元數據管理（Metadata Management），讓使用者知道哪些數據存在於何處。
透過這套設計，工程師可以用單一條 SQL 語句，同時 Join（關聯）來自 Postgres、ClickHouse 和 Iceberg 的表格。這不僅大幅提升了分析效率，更降低了維護多套 ETL（提取、轉換、載入）管道的成本。
然而，當所有數據都被統一後，權限管理與隱私保護（Data Governance）變得至關重要。Cloudflare 採取了預設關閉（Default Closed）的治理模型。任何新上線的數據集在經過自動化掃描與人工審核之前，預設都是不可訪問的。
為了自動化這個過程，他們開發了 Skimmer 服務。Skimmer 結合了自動化分類與 AI 分析，專門偵測 PII（Personally Identifiable Information，個人可識別資訊，如電子郵件或電話），確保敏感數據不會在未經授權的情況下被查詢。
在 Town Lake 這一層基礎設施之上，Cloudflare 進一步開發了 Skipper。這是一個 AI 數據代理（AI Agent），其作用是將自然語言（如英文問題）轉譯為精確的 SQL 查詢。
Skipper 並非簡單地將問題丟給 LLM，而是利用 Town Lake 的元數據、Schema 定義、數據轉換血緣（Data Lineage，追蹤數據從哪來、經過什麼轉換）以及運行時檢查來優化結果。這解決了 AI 常見的幻覺問題，讓生成的 SQL 更符合業務邏輯而非僅僅是語法正確。
從實務應用來看，Town Lake 的最大需求竟然來自於帳單（Billing）相關工作。在統計期間，超過 53% 的查詢與帳單分析、客戶支援調查及營運報表有關。這證明了統一數據平台在解決複雜跨部門查詢（如：將技術指標與財務數據對齊）時具有極高的商業價值。
總結來說，Cloudflare 的做法給工程團隊的啟示在於：不要試圖將所有數據強行遷移到單一資料庫，而應該建立一個強大的統一訪問層（Unified Access Layer）。透過 Lakehouse 架構解決儲存與查詢的矛盾，利用 AI Agent 降低數據獲取的門檻，並在執行層緊貼權限控制，才能在數據規模爆炸的同時，依然保持對數據的安全掌控。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。