Cloudflare 披露了内部统一数据平台 Town Lake，以及面向分析场景的 AI Agent Skipper。最值得注意的数字不是“用了哪些新技术”，而是计费工作负载贡献了约 9.1 万次查询，并占到了整体查询的多数：当 billing 成为数据平台最大用户，说明统一分析平台已经不只是 BI 报表工具，而是在支撑真实的经营、运营和安全决策。
Town Lake 解决的不是“存数据”，而是“跨系统可信查询”
从摘要看，Town Lake 的关键词是统一、治理、跨系统分析。它把 operational、billing、security、business 等不同域的数据放到一个可查询、可治理的湖仓体系里。
这类平台通常要解决三个硬问题：
- 数据分散：账单、用量、安全事件、客户信息可能来自不同服务和数据库。
- 口径不一：同一个 customer、account、product、usage 在不同系统里可能有不同字段和生命周期。
- 查询门槛高：业务团队想问“某类客户本月成本为什么上升”，但答案可能跨越计费、产品用量和安全日志。
Town Lake 的技术栈包括 Trino、Iceberg、R2 和 DataHub。可以理解为：
- Trino 负责跨数据源 SQL 查询。
- Iceberg 负责湖仓表格式、快照、Schema 演进等能力。
- R2 作为对象存储承载数据文件。
- DataHub 负责元数据、血缘、发现和治理。
这里的重点不是“把所有数据倒进一个桶”，而是让不同团队在统一入口里，用可审计、可治理的方式查到同一套事实。
为什么计费查询会成为主力负载
计费数据天然是公司内部最容易形成高频分析需求的数据之一。它连接了产品、客户、收入、成本、风控和支持团队。
比如一个计费平台可能经常被问到：
- 某个产品线的用量增长是否真实转化为收入？
- 哪些账号出现了异常费用波动？
- 某次价格策略调整影响了哪些客户分层？
- 客户支持收到的账单投诉是否集中在某个区域、产品或时间窗口？
如果这些问题每次都要工程师从多个系统手写 ETL，再导出 CSV，分析周期会非常慢。Cloudflare 披露 billing 形成多数使用量，恰好说明统一数据平台的价值往往先在“钱和用量”这类高敏感、高频率数据域里显现。
可以这样实践：用 Trino 查询 Iceberg 计费表
下面是一个可改造的最小示例，用 Trino 连接 Iceberg catalog，查询按客户聚合的计费数据。示例不是 Cloudflare 的内部配置，而是基于摘要中提到的技术栈，演示类似平台的落地方式。
你需要替换对象存储地址、访问密钥和 catalog 配置。若使用 S3 兼容存储，R2 也可通过类似 endpoint 的方式接入。
# docker-compose.yml
services:
trino:
image: trinodb/trino:latest
ports:
- "8080:8080"
volumes:
- ./catalog:/etc/trino/catalog
# catalog/iceberg.properties
connector.name=iceberg
iceberg.catalog.type=rest
iceberg.rest-catalog.uri=http://iceberg-rest:8181
fs.native-s3.enabled=true
s3.endpoint=https://<account-id>.r2.cloudflarestorage.com
s3.aws-access-key=<r2-access-key>
s3.aws-secret-key=<r2-secret-key>
s3.path-style-access=true
启动 Trino：
docker compose up -d
假设已经有一张 Iceberg 表 lake.billing.usage_events，可以用 Trino CLI 或 Web UI 执行：
SELECT
account_id,
date_trunc('month', usage_time) AS usage_month,
product,
sum(quantity) AS total_quantity,
sum(amount_usd) AS total_amount_usd
FROM lake.billing.usage_events
WHERE usage_time >= date '2025-01-01'
GROUP BY 1, 2, 3
ORDER BY total_amount_usd DESC
LIMIT 20;
这类查询看似普通，但一旦 billing、security、support、product usage 都有统一的 account_id 和时间口径，就可以继续做跨域分析：
SELECT
b.account_id,
b.total_amount_usd,
s.security_events,
b.product
FROM (
SELECT account_id, product, sum(amount_usd) AS total_amount_usd
FROM lake.billing.usage_events
WHERE usage_time >= current_date - interval '30' day
GROUP BY 1, 2
) b
LEFT JOIN (
SELECT account_id, count(*) AS security_events
FROM lake.security.events
WHERE event_time >= current_date - interval '30' day
GROUP BY 1
) s
ON b.account_id = s.account_id
ORDER BY b.total_amount_usd DESC
LIMIT 50;
这就是统一湖仓平台真正有用的地方：不是单表查得更快，而是把原本散落在多个系统里的事实放到同一个分析平面上。
Skipper：自然语言入口不能绕过治理
摘要提到 Skipper 是一个 AI analytics agent，用自然语言统一访问运营、计费、安全和业务数据。这类 Agent 的价值很直接：让更多人能问数据问题，而不必先学会复杂 SQL 或了解每张表的位置。
但在企业数据平台里，自然语言访问不能等于“无限制查库”。尤其是 billing 和 security 数据，涉及金额、客户、事件、权限边界。一个可用的分析 Agent 至少要处理这些边界：
- 用户是否有权限访问相关数据域。
- 生成的 SQL 是否只访问允许的 catalog、schema 和字段。
- 查询结果是否包含敏感字段，需要脱敏或聚合。
- Agent 的回答是否附带可审计的 SQL、表名和时间范围。
可以这样设计一个最小工作流：
用户问题
-> 权限检查：用户能访问哪些 DataHub 数据资产
-> 语义解析：把问题映射到候选表和指标
-> SQL 生成：限制 catalog/schema/table 白名单
-> 查询执行：通过 Trino 执行，只读账号
-> 结果解释：返回摘要、SQL、数据时间范围和置信边界
对业务用户来说，Skipper 这类工具像是“会写 SQL 的分析同事”；对平台团队来说，它更像是一个必须接入权限、元数据和审计系统的受控查询层。
落地建议：先选高价值数据域，再扩大统一入口
如果要借鉴 Cloudflare 的思路，不建议一开始就追求“全公司所有数据统一”。更稳妥的路径是从一个高价值、高频率、跨系统依赖明显的数据域开始，例如计费、用量、客户健康度或安全运营。
一份可执行的检查清单：
- 先定义核心实体：account、customer、product、invoice、usage event。
- 为关键表建立 owner、血缘、刷新频率和数据质量规则。
- 用 Iceberg 这类表格式承接增量写入、快照和 Schema 演进。
- 用 Trino 提供统一 SQL 查询入口，而不是让每个团队各建一套查询层。
- 用 DataHub 这类元数据系统暴露表说明、字段含义和权限边界。
- 引入 AI Agent 前，先把权限、审计和 SQL 白名单做好。
Town Lake 的启发在于：统一数据平台的成功指标不只是存储规模，而是谁在高频使用它、是否能回答跨系统问题、能否在治理边界内扩大数据访问。计费查询占多数这个细节，反而给了一个很务实的判断标准：当最敏感、最复杂、最贴近收入的数据域愿意迁入统一平台，平台才真正进入了核心业务链路。