最近几个月，用 BigQuery 的朋友值得多留意一下谷歌的动作——这个数据仓库正在悄悄"变身"。
8 月 7 日，Google Cloud 在发布说明里加入了一项新能力：BigQuery 到 AlloyDB 的数据同步预览。往前倒，6 月中旬，谷歌开源的时间序列基础模型 TimesFM 2.5 发布，并接入了 BigQuery ML，号称 3 行 SQL 就能对百万级序列做零样本预测。知乎专栏7 月中旬，谷歌研究院又发布了表格基础模型 TabFM，后续计划原生集成进 BigQuery，用一条 AI.PREDICT 指令在数仓里直接做零样本表格预测。
三件事放在一起，指向同一个变化：BigQuery 正在从"跑 SQL 的数据仓库"，变成"基础模型的调用入口"。这对使用者意味着两头：能干的事变多了，但账单的计算方式也在跟着变。今天就把这件事掰开说清楚：哪些现在就能用，哪些可以等，以及钱包要注意什么。
一、现在就能用的：3 行 SQL 调 TimesFM 做时序预测
这是目前最值得动手试的一项。TimesFM 是 Google Research 出品的时间序列基础模型，用 4000 亿个时间点预训练，200M 参数，开源协议是 Apache 2.0。6 月发布的 2.5 版本把上下文扩到了 16k，还加上了协变量支持——节假日、促销这种以前容易被模型当噪声的脉冲，现在可以作为外部变量喂进去。
关键是它进 BigQuery 的方式非常"数仓原生"：不用搭 Python 环境，不用 ML 基础设施，直接写 SQL：
```sql
CREATE OR REPLACE MODEL `my_dataset.forecast`
OPTIONS(model_type=‘TIMESFM’, model_version=‘2.5’, horizon=30)
AS SELECT date, revenue FROM `my_dataset.sales`;
SELECT * FROM ML.FORECAST(MODEL `my_dataset.forecast`, STRUCT(30 AS horizon));
```
第一段建模，第二段预测，就这么简单。据社区整理的信息，这个集成目前已经是 GA（正式可用）状态。知乎专栏
它适合谁？典型场景是零售销量、库存、运营指标这类有成百上千条序列、每条单独训练 Prophet 成本爆炸的预测需求。对"DBA 会写 SQL 但不会 Python"的团队尤其友好——谷歌给的说法是，无需任何 ML 基础设施，DBA 团队用 SQL 就能预测百万级时间序列。知乎专栏
但丑话说在前面：零样本不等于免验证。连推荐它的社区文章都明确提醒，TimesFM 给了的是"不用训练就能用"的起点，不是免调优的银弹，务必在自己的数据上和历史方法（ARIMA、Prophet 之类）对比过再下结论。拿它做快速基线和原型很香，直接上生产决策，先跑回测。知乎专栏
二、值得盯着的：TabFM 和 AI.PREDICT，还没进门
7 月中旬发布的 TabFM 走的是另一条路：表格预测。传统做法里，每份数据集都要从零训练、调参、维护重训练流水线；TabFM 把预测变成了上下文学习——把历史样本和要预测的新数据拼成提示，一次前向传播直接出结果，不更新任何权重。谷歌在 TabArena（51 套数据集）上的测试显示，零样本效果可以打平甚至超过精调过的传统监督模型。知乎专栏
它的定位很诚实：核心价值是提速落地——中小团队不用专职数据科学家，也能快速拿到高质量基线。但谷歌自己也承认，它替代不了极致优化的生产级定制模型；而且每次预测要加载全部历史上下文，推理开销大，毫秒级低延迟的线上接口和百万行以上的大表都不适合。知乎专栏
对 BigQuery 用户来说，最值得注意的是它的落地计划：后续原生集成进 BigQuery，通过 AI.PREDICT 指令，把表格机器学习简化成一条普通 SQL 查询。知乎专栏不过目前是"规划中"，还没进门。所以这项的正确姿势是关注、试用开源版评估效果，而不是等它上线。
三、工程师该留意的：数仓数据"回流"数据库
8 月 7 日进入预览的 BigQuery → AlloyDB 同步，解决的其实是个老痛点：画像、分群、指标每天在 BigQuery 里算好，但业务系统要低延迟地读，以前只能靠 ETL 再搬一次。现在可以直接把 BigQuery 表同步进 AlloyDB，一次性同步得到可写副本，周期同步得到只读本地表（可选 1 小时、6 小时或更长刷新间隔），应用像查 PostgreSQL 本地表一样读。知乎专栏
不过预览阶段的边界很具体，想试的团队先看清楚：目前只支持 PostgreSQL 18；周期同步的表是只读的；同步本身消耗 AlloyDB 的 CPU 和内存；如果用 replace 模式，旧表会先删后建，读的人可能短暂看到空表；而且 BigQuery Storage Read API 和 AlloyDB 存储是两边分别计费的。知乎专栏适合的场景很明确——“仓库算好、在线快读”，其他场景不必急着上车。
顺带一提，同一批更新里还有个不起眼的信号：Looker 的 AI 问数（Conversational Analytics）开始提供 token 用量看板，能看到每个数据 Agent 消耗的输入输出 token。知乎专栏这事的象征意义大于功能本身——连谷歌自己都开始给"AI 问数"补账单了，说明 AI 功能的成本可见性，正在成为官方承认的刚需。
四、用之前，先把账单逻辑搞明白
这部分是老生常谈，但在新功能上车前必须重提，因为 BigQuery 的计费逻辑有两个特点。
第一，按扫描量计费，不是按返回行数。 按需模式下，查一次收一次的钱，价格取决于扫了多少数据（美区多区域挂牌价约 $6.25/TB）。经典的坑有几个。一个是 `SELECT *`，会把整张表的列全扫一遍。一个是 `LIMIT`：`LIMIT 1` 和 `LIMIT 100` 收费一模一样，因为表还是全扫了。知乎专栏再一个是 JOIN 大表不做分区裁剪，扫描量直接翻倍。早年就有研究生在 B 站记录过自己操作不当被扣 1000 美元的惨痛经历。哔哩哔哩
第二，免费额度是真的，而且不小。 BigQuery 的免费层每月有 1TB 查询处理量和 10GB 存储，对个人学习、原型验证、小规模业务完全够用。知乎专栏很多人不知道这个额度，要么不敢用，要么一上来就绑了卡忘了设护栏。
新的变化是：账单开始有"第二本账"了。 以前 BigQuery 的账基本就是"扫描字节数"这一本；现在叠加了模型调用——TimesFM 预测、未来 TabFM 的 AI.PREDICT、AI 问数的 token 消耗，各有各的成本来源。功能还在预览和铺开阶段，具体计费细则建议用之前翻一遍最新的官方定价文档，别拿 2024 年的经验套。
给三个马上能做的动作：跑查询前看一眼预估扫描字节数（控制台会显示）；给大表做分区、只选需要的列；把"最大字节数"限制打开，给单条查询设个消费上限。
五、三类人的行动清单
如果你是 GA4 导出用户或出海业务分析师：最值得试的是 TimesFM。GA4 的原始事件数据本来就免费导出到 BigQuery，拿流量、转化或销售序列跑一次 3 行 SQL 的预测，和自己现有的判断对比一下，成本几乎为零（记得在免费额度内操作）。谷歌在 BigQuery 上开放过一个 GA4 混淆样例数据集 `ga4_obfuscated_sample_ecommerce`，可以直接拿来练手。知乎专栏
如果你是数据工程师，负责仓库到应用的链路：重点盯 AlloyDB 回流同步。如果你们正好有"仓库算好、在线系统要低延迟读"的场景，可以在预览期用一张非核心表做小范围验证，重点验证 replace 的空窗期和两边计费。
如果你是学习者或纯观望：不用急着上任何新功能。先用免费额度把 BigQuery 的公共数据集查熟，理解按扫描计费这套逻辑——这是所有新功能的地基。TabFM 这种还没进门的，先收藏开源仓库看评测就好。
写在最后
BigQuery 这波变化的本质，是数据仓库和基础模型的边界在变模糊：以前"做预测"是 ML 团队的事，现在一条 SQL 就能发起。门槛降了是好事，但账单逻辑变复杂也是真的。值得持续跟踪的三个信号：TabFM 集成进 BigQuery 的具体时间表、AlloyDB 同步从预览到 GA 的进度，以及 AI 类功能的计费细则何时明确。
你在 BigQuery 上踩过最贵的坑是什么？或者这几个新功能里你最想试哪个？评论区聊聊。
