Google Cloud在2026年9月28日为BigQuery连续查询增加了新的输出路径：实时处理产生的行可以通过INSERT DML直接写入Apache Iceberg托管表。数据团队因此可以把持续到达的数据加工后落到开放表格式存储，减少为单纯落表而维护额外中转链路的需求。
这项能力扩展的是连续查询的目标端，而不是取消其运行与资源限制。Iceberg托管表可以作为写入目标，但不能作为连续查询的数据源；设计实时管道时仍需从受支持的BigQuery源读取数据。
连续查询新增了Iceberg直接落表路径
BigQuery连续查询会持续处理新进入的数据，此前可把结果发送到BigQuery表、Pub/Sub、Bigtable或Spanner等目标。新增能力允许INSERT语句把输出行直接写入Apache Iceberg托管表，使实时过滤、转换与开放表格式存储可以在同一条SQL管道中衔接。
适合的场景包括实时反向ETL、事件富化、字段筛选和持续的数据分发。对于已有Iceberg消费生态的团队，这能缩短数据从云端分析入口到共享湖仓表之间的路径，但并不会自动替代所有消息缓冲与复杂编排需求。
目标表、连接和存储权限必须预先就绪
连续查询不会替用户即时创建目标表。Iceberg托管表需要预先存在，执行身份还要同时具备目标表、Google Cloud资源连接以及底层Cloud Storage存储桶所需的权限。任一层授权缺失都可能让持续写入失败。
生产环境应优先使用专用服务账号并遵循最小权限原则，避免把个人账号作为长期运行身份。资源连接与存储桶策略也要纳入权限审计，不能只检查BigQuery数据集角色。
读取与写入能力存在明确的不对称
当前能力支持把结果INSERT到Iceberg托管表，但Iceberg表不能成为连续查询的源。需要持续处理的数据仍要来自受支持的BigQuery表或相应输入方式，不能把这项更新理解为可对任意Iceberg数据流执行持续SQL。
同时，面向目标表的是追加式INSERT路径，而不是任意UPDATE、DELETE或MERGE操作。业务若要求更新既有记录、去重合并或处理迟到事件，需要在下游设计额外批处理或幂等整合步骤。
计算预留和运行时长仍是上线门槛
连续查询需要Enterprise或Enterprise Plus版本的容量预留，并配置CONTINUOUS作业分配；按需计算模式不受支持。每个正在运行的连续查询还涉及槽位准入要求，容量规划不能沿用普通交互式查询的峰值思路。
由用户账号运行的连续查询最长为两天，由服务账号运行的最长为150天。长期管道必须设计自动重启、状态监控和凭据生命周期管理，而不是假设一条作业能够无限运行。
重复数据和水位延迟需要下游兜底
官方限制说明，连续查询可能因临时性问题重新处理数据，从而产生重复行；如果水位延迟超过48小时，查询也会失败。直接写入Iceberg后，这些边界仍然存在，目标表不会自动把重复事件消除。
建议在记录中保留稳定事件标识与处理时间，下游按照业务键实现幂等或周期性去重，并监控作业状态、水位延迟、写入吞吐和失败重启。先用可回放的测试流验证重复与中断场景，再把直接写入路径用于关键实时数据。
