🔧 数据平台 · 架构深研
计费查询占 53%、AI 智能体秒转自然语言——Cloudflare 统一数据平台 Town Lake 全解析
Cloudflare 近日详细披露了其内部统一数据平台 Town Lake 与 AI 智能体 Skipper 的架构细节:计费工作负载占平台查询的 53%,324 名员工累计发起 91760 条计费相关查询。平台基于 lakehouse 架构,通过统一 SQL 接口连接此前分散在 Postgres、ClickHouse、Kafka、BigQuery 等系统中的数据,辅以默认封闭的治理模型与自然语言查询能力。
综合公开信息整理•
2026-02-14•
全文约 4 分钟读完
#Cloudflare
#Town Lake
#AI Agent
#统一数据平台
#Lakehouse
10亿+ events/s
全球网络每秒处理事件数
53%
查询来自计费工作负载
91760
计费类查询 · 324 名员工
⚡ 30 秒速览
- 核心数据:计费工作负载占 Town Lake 平台查询的 53%,324 名员工累计发起 91760 条计费相关查询,涵盖计费分析、支持调查与运营报告。
- 架构底座:基于 Apache Trino + Apache Iceberg + Cloudflare R2 + DataHub 构建 lakehouse,单条查询可跨 Postgres、ClickHouse 与 Iceberg 表,无需移动数据。
- AI 智能体:Skipper 利用元数据、模式定义、转换谱系与运行时检查,将自然语言转为可审计的 SQL 查询,秒级交付洞察。
- 治理先行:默认封闭模型——新数据集自动扫描 + AI 分类 + 人工复核,Skimmer 服务负责敏感数据检测与分级。
- 未来方向:计划与内部聊天、工单和开发工作流深度整合,并逐步将更多工作负载迁移至 R2 SQL。
01数据底座规模 覆盖 120 个国家,每秒处理 10 亿+ 事件
Cloudflare 全球网络分布在 120 个国家的 330 多个城市,每秒处理超过 10 亿条事件。如此庞大的数据流,历史上分散在 Postgres、ClickHouse、Kafka、BigQuery 与对象存储中——数据发现与分析变得异常复杂。
Town Lake 的使命:提供一个统一的 SQL 接口,跨所有系统执行查询,同时保留治理与访问控制。
120国家覆盖
330+城市节点
10亿+事件/秒
324平台员工用户
注:以上为 Cloudflare 全球网络基础设施数据,事件处理量为峰值吞吐能力。
但数据规模只是起点。真正的挑战在于:这些查询到底在干什么?
计费工作负载占平台查询53%
在测量期间,324 名员工发起了 91760 条与计费相关的查询,涵盖计费分析、客户支持调查与运营报告。计费是 Town Lake 当前最核心的应用场景。
注:数据条占比以 53% 为基准绘制,剩余 47% 包含安全、业务智能等工作负载。
02架构解析:从分散到统一 Lakehouse + 封闭治理
Town Lake 基于 lakehouse 架构构建,核心组件包括 Apache Trino、Apache Iceberg、Cloudflare R2 对象存储与 DataHub 元数据管理。单条查询可在不移动数据的前提下连接 Postgres、ClickHouse 与 Iceberg 表。
传统分散架构
数据散落在 Postgres、ClickHouse、Kafka、BigQuery、对象存储中,跨系统查询需手动迁移或 ETL,治理与发现成本极高。
Town Lake 统一平台
Trino 提供统一 SQL 接口,Iceberg 管理表格式,R2 作为对象存储底座,DataHub 负责元数据发现与谱系追踪。
Apache Trino
Apache Iceberg
Cloudflare R2
DataHub
Skimmer
注:技术栈标签按组件在架构中的角色排列,Trino 为查询引擎,Iceberg 为表格式,R2 为存储层,DataHub 为元数据管理,Skimmer 为敏感数据检测服务。
一个关键的设计选择:默认封闭的治理模型。
新加入的数据集在自动扫描与人工审查完成之前,默认不可访问。内部服务 Skimmer 将自动分类与基于 AI 的分析相结合,检测敏感数据与 PII,随后由人工复核者验证或调整分类并授予访问权限。这套机制在开放性与安全性之间找到了一个务实的平衡点。
03实际场景:从计费到安全,AI 智能体如何落地 Skipper 的三种工作模式
在 Town Lake 之上,Skipper 提供对企业数据的自然语言访问。它使用元数据、模式定义、转换谱系、文档与运行时检查,将用户请求翻译为经过验证的查询。以下是三个典型场景:
💰 计费分析 · 占查询总量 53% 核心场景
- 324 名员工累计发起 91760 条计费相关查询,涵盖账单分析、客户计费调查与运营报告。
- 过去需要复杂 SQL 或人工调查才能完成的任务,现在通过自然语言在几秒内获得结果。
- 简化 AI 智能体的提示词提高了准确度,合并重叠工具减少了错误选择。
效果:计费团队查询效率显著提升,重复性人工分析大幅减少。
🛡️ 安全工作流 · 跨系统威胁溯源 高价值场景
- 安全团队通过 Skipper 在 Town Lake 上发起自然语言查询,关联来自不同数据源的事件日志。
- 将 SQL 转换逻辑与数据谱系纳入智能体上下文,提升了智能体对业务语义的理解,超越了仅靠模式元数据的能力。
- 可审计的查询链路确保安全调查过程可追溯、可复现。
效果:将数小时的手动日志关联压缩到分钟级响应。
📊 业务智能 · 自助式运营分析 广泛使用
- 业务团队不需掌握 SQL,直接用自然语言提问:「上周各区域流量分布与计费对账」。
- Skipper 自动理解意图、拆解为多步查询,并返回结构化结果。
- 统一的 SQL 接口让 BI 报表可以跨数据源实时生成,无需预先 ETL。
效果:数据民主化程度大幅提升,非技术团队自助分析能力增强。
注:以上场景基于 Cloudflare 公开披露的案例整理,具体数据来自官方博客与工程团队分享。
04为什么是 Cloudflare 做出来了?
答案藏在两个关键词里:数据密度与工程务实。
Cloudflare 全球网络每秒处理 10 亿+ 事件,天然拥有极高的数据密度与多样性。当数据分散在 Postgres、ClickHouse、Kafka、BigQuery 等系统中时,内部的「数据孤岛」问题比任何公司都更早、更痛。Town Lake 不是一次自上而下的平台工程运动,而是被业务逼出来的解决方案。
一个诚实的注脚:统一平台最容易摔跤的地方,是治理。
Cloudflare 选择了默认封闭的治理模型——新数据不可见,直到 AI 扫描与人工复核完成。这虽然增加了数据上线的摩擦,但避免了「数据湖变数据沼泽」的常见陷阱。Skimmer 服务的 AI 分类 + 人工复核双轨机制,在效率与安全之间做了务实取舍。
「在统一分析平台之上放置内部的 AI 智能体,正是基础设施团队开始感到控制问题的地方。如果智能体可以跨运维数据进行推理,则执行过程中的强制执行必须靠近执行点。分布式确定性检查能让智能体在不将数据平台变为不受控的动作时安全地开展行动。」
— Patrick Joubert,Rippletide CEO
这段外部评论点出了 Skipper 架构设计的关键洞察:AI 智能体的执行权限必须靠近数据层,且需要分布式的确定性检查机制——这正是 Town Lake + Skipper 组合在设计上的隐性门槛。
编辑核心判断
统一数据平台与 AI 智能体的组合正在成为企业数据基础设施的「标配底座」,但治理与安全是最大的隐性成本。Cloudflare 的默认封闭模型和 AI+人工双轨审核机制,为行业提供了一个可参考的务实范本——当智能体能够跨系统推理时,执行控制必须下沉到数据层,而非停留在应用层空谈权限。
05下一站:更深度的嵌入 聊天、工单与开发工作流
Cloudflare 计划将 Skipper 与内部聊天、工单和开发工作流做更深度的整合。同时,团队正在扩展其 Transformer 流水线,使团队能够使用 SQL 与元数据文件定义策划数据集,这些数据集将被自动部署、监控、编目,并通过 DataHub 与 Skipper 展示。
值得关注的趋势:随着系统不断成熟,Cloudflare 预计会将更多 Town Lake 的工作负载迁移到 R2 SQL 上运行。这意味着对象存储原生查询的能力正在逐步替代传统的数据仓库 ETL 链路——如果这条路走通,它可能会改变整个数据平台的成本结构。
注:以上信息综合自 Cloudflare 公开技术博客与工程团队分享,不构成任何投资建议或产品承诺。