我们如何构建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任务中易产生幻觉。解决方案是多层语境：模式和使用元数据、人类标注、已知查询模板、以及运行时反馈。未来计划包括跨表上下文窗口、主动数据发现、增强事实检验等。