数据工程面试：如何评估 BigQuery continuous queries？

题干与适用场景

业务希望数据写入 BigQuery 后尽快触发告警，并把结果写入表或导出到 Pub/Sub、Bigtable、Spanner。请说明是否采用 BigQuery continuous queries，如何处理输入、权限、运行时长、区域、成本和失败恢复。不要只描述 SQL 语法。

面试官考察点

是否理解 continuous query 是持续运行的 SQL，不是固定间隔的批量轮询。
是否能根据延迟、输出目标和数据语义判断它与 Dataflow、Pub/Sub 或普通查询的边界。
是否核对 Enterprise 版本、CONTINUOUS reservation、服务账号和区域限制。
是否能把重复输出、背压、监控、重启和成本控制说清楚。

回答前需要澄清的问题

输入是追加写入还是会更新、删除既有行？结果允许重复或需要精确一次语义吗？
目标是 BigQuery 表、Pub/Sub、Bigtable 还是 Spanner？下游是否能处理重试？
可接受延迟、运行时长和数据区域是什么？项目是否具备所需版本与 reservation？
失败重启后从哪里恢复，如何监控延迟、积压、错误和输出数量？

30 秒回答框架

我会先验证需求是否真的是持续流式处理：continuous query 适合在 BigQuery 中持续分析进入的数据并输出到指定目标，但它有版本、容量、授权和区域约束。先确定输入与结果的幂等键，再选输出目标和重试策略；为持续作业准备服务账号、CONTINUOUS reservation 和监控。上线前用小流量验证延迟、重复、成本和停止恢复，不能把它当成无限运行且零成本的 Cron 替代品。

分步骤深入解答

1. 先划定数据语义

Continuous query 会持续处理进入 BigQuery 表的数据。追加事件、迟到数据、更新和删除的处理方式不同；如果业务需要复杂状态、事件时间窗口或严格顺序，应先确认官方支持的 SQL 能力，并评估 Dataflow 等流处理引擎。

2. 选择输出路径

官方文档支持把结果插入 BigQuery 表，或用 EXPORT DATA 导出到 Pub/Sub、Bigtable、Spanner。选择时看下游的吞吐、顺序、幂等和区域约束。Pub/Sub 适合再接事件处理；直接写表则要设计去重键和保留策略。

3. 核对运行与授权条件

创建和运行 continuous query 可使用用户账号或服务账号；导出到 Pub/Sub 必须使用服务账号。用户账号作业最长可运行两天，服务账号最长可运行 150 天。持续查询需要 Enterprise 或 Enterprise Plus edition，以及类型为 CONTINUOUS 的 reservation assignment，不能假设默认项目即可运行。

4. 预算、监控与恢复

持续查询按 BigQuery capacity compute 计费，其他输出服务另计费。监控持续查询专属指标、输入到输出延迟、错误、重启次数和输出量；为作业定义停止、重建和告警流程。恢复时应依据幂等键或水位重新处理可接受范围，避免重启造成重复副作用。

高质量示范回答

我会先把 continuous query 当成数据产品的运行约束来评估。它适合持续分析写入 BigQuery 的数据，并把结果写回表或导出到 Pub/Sub、Bigtable、Spanner；但输入是追加还是变更、结果是否允许重复，会决定它能否满足语义。接着核对 Enterprise 版本、CONTINUOUS reservation、服务账号、作业最长运行时间和区域边界。输出端设计幂等键、重试与死信处理，监控输入延迟、积压、错误和成本。上线前用受控流量验证延迟和重启行为，明确暂停、恢复与重新补数方案。若需要复杂事件时间状态、严格顺序或更长生命周期，就把它与专用流处理方案比较，而不是强行把所有实时需求塞进 BigQuery。

常见错误

把 continuous query 当成每分钟执行一次的普通查询。
忽略 Enterprise/Enterprise Plus、CONTINUOUS reservation 或服务账号要求。
认为导出到所有目标都具有相同的顺序和重复语义。
没有为重启、重复输出和迟到数据定义水位或幂等键。
只看 SQL 延迟，不计算 BigQuery capacity 与下游服务成本。
把两天或 150 天的作业时限误解为永久运行保证。

追问及应对

什么时候选择 Dataflow？

当需求包含复杂事件时间窗口、状态管理、严格顺序、丰富连接器或需要长期运行的流处理拓扑时，应把 Dataflow 等专用引擎纳入比较。选择依据是语义和运维边界，不是只比较一条 SQL 的长度。

重启后如何避免重复告警？

让输出带事件或业务幂等键，下游用去重或事务写入；记录输入水位和处理批次，恢复时从安全边界重放，并把不可避免的重复当作协议约束公开给消费者。

如何判断成本是否可接受？

分别估算 continuous query 的 capacity slots、输入与存储、以及 Pub/Sub、Bigtable 或 Spanner 的费用；压测持续负载、空闲时段和峰值，再用监控中的延迟与 slot 消耗校准预算。