Google Data Cloud 最近一轮更新并不是零散地增加几个控制台按钮，而是在打通一条更完整的数据链路：Kafka 负责产生实时事件，BigQuery 连续查询直接执行有状态计算，Dataflow 以更低风险更新运行中的管道，Lakehouse 托管表让多个引擎共享 Iceberg 数据，最终再由 Gemini、Looker 和 MCP 把经过治理的数据交给用户或 AI 代理。
其中需要特别区分发布阶段：BigQuery 连续查询的有状态处理和 Lakehouse 托管表仍处于预览阶段；Kafka 合成数据生成器以及 Dataflow 新的管道更新能力已经正式可用。生产系统应据此设置不同的试用边界。
连续查询开始承担真正的流式计算
过去，连续查询更适合逐条转换、过滤和路由事件。加入有状态处理后，查询可以使用 JOIN、聚合和窗口函数，在流持续到达时维护跨事件状态。这使 BigQuery 能够计算最近 30 分钟平均值、滑动计数、实时异常比例，以及事件与维表关联后的业务指标。
这项变化对实时应用和 AI 代理尤其重要。代理通常不需要几千条原始设备事件，而需要“过去 30 分钟温度比基线高 18%”这类已经聚合并带有业务上下文的信号。把窗口计算放进连续查询，可以减少代理侧临时拼接数据和重复实现指标逻辑的问题。
下面的 BigQuery Standard SQL 可以直接运行，用一组内联事件验证“30 分钟滑动平均”的业务语义。它是批量测试版本；接入预览版连续查询时，可保留窗口表达式，再按照项目中的连续查询输入与输出方式替换数据源和目标表。
-- BigQuery Standard SQL: 可直接在查询编辑器中运行
WITH sensor_events AS (
SELECT * FROM UNNEST([
STRUCT('sensor-01' AS sensor_id, TIMESTAMP '2026-08-31 10:00:00+00' AS event_ts, 20.0 AS reading),
STRUCT('sensor-01', TIMESTAMP '2026-08-31 10:10:00+00', 22.0),
STRUCT('sensor-01', TIMESTAMP '2026-08-31 10:25:00+00', 26.0),
STRUCT('sensor-01', TIMESTAMP '2026-08-31 10:40:00+00', 30.0),
STRUCT('sensor-02', TIMESTAMP '2026-08-31 10:05:00+00', 11.0),
STRUCT('sensor-02', TIMESTAMP '2026-08-31 10:20:00+00', 13.0)
])
)
SELECT
sensor_id,
event_ts,
reading,
ROUND(
AVG(reading) OVER (
PARTITION BY sensor_id
ORDER BY UNIX_SECONDS(event_ts)
RANGE BETWEEN 1800 PRECEDING AND CURRENT ROW
),
2
) AS avg_reading_last_30m
FROM sensor_events
ORDER BY sensor_id, event_ts;
将它改造成实际工作负载时，需要额外确认事件时间与处理时间的选择、迟到事件策略、状态增长上限、输出幂等性以及 JOIN 维表的更新行为。预览功能也不适合在没有回退路径的情况下直接接管关键告警或交易决策。
Kafka 和 Dataflow 补上了测试与发布环节
Managed Service for Apache Kafka 的合成数据生成器已经正式可用。新集群创建后，无须先修改客户端应用或临时启动虚拟机，就能在控制台中快速发送模拟数据；官方描述的目标体验是在三次点击、两分钟以内形成数据流。
这个工具最适合连通性验证、权限检查、吞吐基线测试和新功能演示，但不能代替真实压测。合成事件通常无法还原生产数据的键分布、突发流量、超大消息、乱序比例和坏数据特征。团队仍应保存一套脱敏后的代表性测试样本。
Dataflow 的更新流程也更灵活。除原有的原地更新外，现在可以采用 stop-and-replace，并通过并行管道选项加快旧版本到新版本的迁移。Drain 还可以设置超时，避免管道因卡住而无限排空并持续产生费用。这些能力已经正式可用。
可以这样为团队定义一份发布策略。下面的 YAML 是团队自有配置示例，不是 Google Cloud 产品 API；CI/CD 脚本应把这些字段映射到实际的 Dataflow 部署参数：
# dataflow-release-policy.yaml
pipeline: orders-streaming
update_strategy: stop-and-replace
parallel_migration: true
drain_timeout_minutes: 30
validation:
compare_output_for_minutes: 15
max_error_rate: 0.001
rollback:
keep_previous_artifact: true
require_manual_approval: true
并行运行会降低切换中断，但也可能造成短时间资源翻倍，并引入重复输出风险。上线前要验证 sink 是否支持幂等写入，或者是否能根据事件 ID 去重；同时监控旧、新管道的水位、积压、错误率和单位事件成本。
Iceberg 托管表让湖仓不再依赖双份数据
进入预览的 Lakehouse 托管表以 Apache Iceberg 为统一表格式，目标是让 BigQuery 与开源引擎在同一共享存储层上读写数据，并支持跨分析工具执行并发 DML 和 DDL。平台还会承担 compaction、分区调优等后台维护工作。
它解决的是常见但代价高昂的问题：一份数据为了 BigQuery 查询而维护一条同步链路，又为了 Spark 或其他开放引擎维护另一份副本。副本不仅增加存储费用，还会产生延迟、模式漂移和权限不一致。
不过，“多引擎可读写”并不意味着可以忽略协调。试用时至少要验证：
- 各引擎支持的 Iceberg 特性和版本是否一致。
- 并发 DDL、模式演进与分区变更如何处理冲突。
- 数据权限是否覆盖对象存储、目录和查询引擎三个层面。
- 自动 compaction 对查询延迟、快照保留和成本的影响。
- 出现不兼容写入后，如何回滚到已知快照。
数据产品正在成为 AI 代理的可信边界
其他更新显示出同一条产品方向。BigQuery Studio 中的 Gemini 助手正在从代码补全转向理解上下文的分析伙伴；BigQuery Conversational Analytics API 可以让代理理解自然语言、查询数据，并返回文本、表格或图表；Looker Embedded 可以把自然语言分析嵌入业务应用；BigQuery Graph 则为大规模关系建模和分析提供新的入口。
数据库侧也在靠近代理工作流。AlloyDB、Spanner、Cloud SQL、Bigtable 和 Firestore 获得托管或远程 MCP 支持，Managed Service for Apache Airflow 还加入了托管 MCP Server、声明式 YAML 管道和 AI 辅助故障排查。Cloud Composer 中的 Gemini Cloud Assist 能分析失败任务的日志与元数据，识别资源不足、超时等模式并给出处理建议。
关键边界是：代理获得数据库工具，并不等于代理应拥有不受限制的数据库权限。更稳妥的做法是把语义层、受控视图、参数化工具和审计日志放在模型与底层数据之间；写操作使用独立身份、最小权限和人工审批。
采用时按成熟度分层
这批更新可以按风险拆成三条推进线：
- 立即用于开发环境：用 Kafka 合成数据生成器验证新集群，把 Dataflow drain 超时纳入发布规范，并评估 Google 自研 JDBC、ODBC 驱动的兼容性。
- 在隔离工作负载中试点：验证 BigQuery 连续查询的窗口、JOIN 和聚合语义，测量状态规模、迟到数据和恢复行为。
- 用非关键数据评估架构变化：测试 Iceberg 托管表的多引擎互操作，以及 MCP、Conversational Analytics 和 Looker 语义层组成的代理访问路径。
验收指标不应只看查询是否成功。还要比较端到端延迟、重复事件比例、恢复时间、每百万事件成本、跨引擎一致性，以及代理回答能否追溯到受治理的数据和业务定义。只有这些指标稳定，新的实时与 AI 能力才适合从演示环境进入生产系统。