Cloudflare 披露了内部统一数据平台 Town Lake，以及面向自然语言分析的 AI 代理 Skipper。最值得注意的数字不是“有了 AI”，而是计费工作负载的真实占比：约 9.1 万次计费查询，占平台查询量的 53%。这说明统一数据平台的核心价值，往往不是炫技，而是把运营、计费、安全、业务数据放到同一套可治理的分析路径里。
计费为什么会成为最大用户
计费数据通常最难被“单系统”解释清楚。一次账单异常，可能要同时追踪产品用量、账户状态、合同规则、风控事件、退款记录和内部运营动作。如果这些数据分散在多个系统里，分析人员就会在导出 CSV、拼接脚本和反复问数之间消耗大量时间。
Town Lake 的意义在于把这些跨系统数据放进统一 lakehouse 架构中，让计费分析不再依赖某个单点数据库。来源摘要中提到的平台组件包括 Trino、Iceberg、R2 和 DataHub：
- Trino 负责跨数据源 SQL 查询，适合把多个域的数据连起来分析。
- Iceberg 提供表格式和元数据能力，支持更可控的大规模数据湖表。
- R2 作为对象存储层，承载数据文件。
- DataHub 承担数据目录、血缘和治理入口。
这类组合的关键不是“把所有数据倒进一个桶”，而是让数据可以被发现、被授权、被解释、被复用。
Lakehouse 架构解决的是协作问题
很多公司早期的数据平台会分成几条线：安全团队有自己的日志分析，财务团队有自己的账单库，业务团队有自己的 BI 表，运营团队还有一套工单和事件记录。短期看各自跑得很快，长期看问题会出现在边界处。
例如，一个客户的账单增长突然异常，财务只看到金额，运营只看到套餐变更，安全团队可能看到流量峰值，产品团队看到 API 调用量变化。统一平台的目标，是让这些信号能在受控权限下被组合查询。
可以把 Town Lake 这类平台理解成三层：
- 存储层：对象存储保存原始和加工后的数据文件。
- 表格式层：Iceberg 这类格式管理 schema、分区、快照和演进。
- 查询与治理层：Trino 查询数据，DataHub 帮助用户找到数据并理解可信边界。
Skipper 则把自然语言入口放在这套治理体系之上。它的价值不应是绕过 SQL，而是降低找到正确数据、写出正确查询、理解口径的门槛。
可以这样实践：用 Trino 查询账单与安全事件
下面是一个可以改造的最小示例，模拟“计费数据 + 安全事件”的跨域分析。假设你已经有 Trino CLI，并且 catalog 中暴露了 lakehouse schema。表名和字段需要按你自己的环境调整。
trino --server http://localhost:8080 --catalog lakehouse --schema analytics
进入 Trino 后执行：
WITH billing_spikes AS (
SELECT
account_id,
date_trunc('day', usage_time) AS usage_day,
sum(billable_requests) AS billable_requests,
sum(amount_usd) AS amount_usd
FROM billing_usage
WHERE usage_time >= current_date - INTERVAL '7' DAY
GROUP BY 1, 2
HAVING sum(amount_usd) > 1000
),
security_events AS (
SELECT
account_id,
date_trunc('day', event_time) AS event_day,
count(*) AS blocked_events
FROM waf_events
WHERE action = 'block'
AND event_time >= current_date - INTERVAL '7' DAY
GROUP BY 1, 2
)
SELECT
b.account_id,
b.usage_day,
b.billable_requests,
b.amount_usd,
coalesce(s.blocked_events, 0) AS blocked_events
FROM billing_spikes b
LEFT JOIN security_events s
ON b.account_id = s.account_id
AND b.usage_day = s.event_day
ORDER BY b.amount_usd DESC
LIMIT 50;
这段查询背后的思路很直接：先找出最近 7 天费用显著上升的账户，再关联同一天的安全拦截事件。它不能直接证明账单上涨由攻击导致，但可以把财务异常和安全信号放到同一张分析表里，帮助团队更快定位下一步。
如果要把这类查询交给自然语言代理，建议不要让代理直接访问所有表。更稳妥的做法是先暴露受治理的视图：
CREATE OR REPLACE VIEW governed_billing_security_daily AS
SELECT
b.account_id,
date_trunc('day', b.usage_time) AS activity_day,
sum(b.billable_requests) AS billable_requests,
sum(b.amount_usd) AS amount_usd,
count_if(w.action = 'block') AS blocked_events
FROM billing_usage b
LEFT JOIN waf_events w
ON b.account_id = w.account_id
AND date_trunc('day', b.usage_time) = date_trunc('day', w.event_time)
GROUP BY 1, 2;
然后把代理的可用范围限制在 governed_billing_security_daily 这样的视图上，而不是原始明细表。这样可以减少隐私暴露、口径漂移和错误 join 的风险。
自然语言分析的边界
Skipper 这类 AI analytics agent 的方向很自然：业务用户不一定想学习复杂 SQL，他们更想问“过去一周哪些客户账单异常，并且是否伴随安全事件”。但在企业数据平台里，自然语言访问必须和治理能力绑定。
需要特别注意几类边界：
- 权限边界：代理不能因为“会写 SQL”就绕过用户本身没有权限访问的数据。
- 语义边界：账单金额、请求数、活跃账户等指标必须有统一口径。
- 审计边界：代理生成了什么查询、访问了哪些表、返回了哪些数据，都应该可追踪。
- 成本边界：自然语言问题可能生成昂贵查询，需要限流、预估和超时控制。
换句话说，AI 入口应该站在数据目录、权限模型和指标定义之后，而不是取代它们。
采用建议：先统一高价值工作负载
Cloudflare 披露的数字给了一个很实用的启发：不要从“建设一个全公司统一数据平台”这种大口号开始，而应该先找查询密度高、跨系统依赖强、业务价值明确的工作负载。计费就是典型场景。
落地时可以用这份检查清单：
- 先选一个高频域，例如计费、风控、客户运营或安全分析。
- 为核心实体建立统一键，例如
account_id、customer_id、zone_id。 - 用 Iceberg 这类表格式管理可演进的数据湖表，而不是只堆文件。
- 用 Trino 提供跨域 SQL 查询能力，但通过视图控制可访问口径。
- 用 DataHub 这类目录工具沉淀血缘、负责人、指标解释和敏感级别。
- 引入 AI 代理前，先准备好权限、审计、查询成本和语义层。
Town Lake 的重点不是某个单独组件，而是一条完整链路：数据能进来，表能治理，查询能跨域，口径能解释，普通用户还能通过自然语言接近数据。对于复杂组织来说，这比单纯多建几个 dashboard 更接近数据平台的长期价值。