BigQuery连续查询可写入Iceberg托管表：实时入湖需同时设计重放与成本
2026年9月28日，Google Cloud宣布BigQuery连续查询可以把输出行直接写入Apache Iceberg托管表，使用INSERT语句将持续处理结果送入开放格式湖仓。对数据已经进入BigQuery、又希望把处理结果供其他分析链路使用的团队，这增加了一条连续输出路径。公告将其列为新增功能，没有单独给出此次集成的GA或Preview标签，因此不宜额外替它添加发布等级。
配图为AI生成的概念插图，表现连续数据进入开放格式存储，不是真实产品界面。
输出目的地扩大，输入范围仍需核对
连续查询持续处理进入BigQuery的数据，再将结果写入或导出到目标系统。此次更新增加的目的地是BigQuery中的Apache Iceberg托管表，不应泛化成任意外部Iceberg目录都可直接写入。配置前应核对表类型、位置、字段以及执行身份。
官方概览还明确，Iceberg托管表目前不被支持为连续查询的数据源，即它可以接收输出，但不能因此反推可以作为输入。同样，外部表、部分变更数据捕获数据等输入也有约束。把熟悉的离线SQL直接加上连续运行选项，并不保证它符合流式执行条件。
这对架构判断很重要。采用者应画出真实的数据方向：原始事件从哪里进入，在哪一步清洗或扩充，哪张托管表承担输出，哪些消费者在何时读取。如果一开始就把所有方向都标为双向，后续权限、重放和一致性设计会建立在错误假设上。
连续执行不意味着所有SQL都能持续运行
官方文档对可用的有状态操作与SQL能力作了具体限制，部分JOIN、聚合和窗口操作仍有预览范围，不能把普通查询的全部语法当成默认支持。运行中的连续查询也不能直接修改SQL，需要按文档规定的方式处理变更。
因此，首个试点宜选择逻辑边界清楚的转换，例如对新进入的记录做字段规范化，再写入一张独立目标表。试验应同时覆盖正常行、缺失字段和不符合业务格式的数据，明确哪些记录被输出、过滤或交由其他流程处理。只有输出样例可解释，才值得把链路接到更广泛的消费者。
如果还要调用AI函数，应该把模型调用失败、超时和用量作为额外依赖。此次目的地扩展没有自动解决这些问题，也没有给出端到端延迟保证；真实表现仍取决于查询、输入速度和资源条件。
运行时限与重复输出，决定恢复策略
当前文档说明，用户账号配置的连续查询最多运行两天，服务账号配置的最多运行150天；达到时限会失败并停止处理。处理进度落后超过规定阈值也可能失败。长期任务应有明确的续接与告警安排，不能因为名字叫“连续”就假定永不停止。
文档还提示临时问题可能触发自动重新处理，从而导致输出重复。对于写入Iceberg表的数据，这意味着下游需要识别重复的业务事件，而不能简单把新增行数等同于新增业务量。具体去重策略应依据事件标识与业务规则设计，本文不假定存储平台替用户完成了端到端的恰好一次语义。
一次有价值的验收应包括主动停止、重新启动以及核对恢复边界。比较停止前后的事件标识、输出计数和关键业务汇总，确认既没有漏掉尾部数据，也没有让重复记录悄悄改变报表。
费用模型也与普通按需查询不同
连续查询需要Enterprise或Enterprise Plus版本的reservation，并使用CONTINUOUS分配类型，不支持按需计算计费模式。官方还给出了专用分配、槽位规模与并发准入等限制。新增Iceberg目的地没有把这些前置条件移除，也没有承诺免费运行。
评估时，应把持续计算、目标存储和后续消费成本一起纳入。即使输入在夜间很少，运行策略仍需要与容量配置相符；如果业务只要求每小时更新一次，是否必须采用连续处理，应先由时效收益来回答。
此次更新为已采用BigQuery流式处理的团队提供了更直接的开放格式输出选择。它值得关注的不是少写了多少胶水代码，而是能否在清楚的输入限制、恢复语义和成本模型下，维持一条可靠、可核查的数据通路。
