BigQuery表最后修改日期与AppendRows日志不一致的原因问询

针对你遇到的「Dataflow作业已停止，但仍有AppendRows日志，而BigQuery表Last modified未更新」的不一致情况，以下是几个可能的原因：

1. BigQuery Storage Write API的流写入逻辑差异 #

从日志看，写入是通过google.cloud.bigquery.storage.v1.BigQueryWrite.AppendRows接口完成的，这属于BigQuery的Storage Write API流写入模式：

• 流写入时，数据会先进入临时缓冲区，只有当流被**提交（Commit）**或BigQuery自动将缓冲区数据合并到主表存储时，才会更新表的Last modified时间。
• 若Dataflow作业停止后，残留的流连接完成了AppendRows调用，但这些数据属于作业停止前未完成的批次，最终合并到主表的时间依然是8月12日（作业停止前的最后一次合并时间），因此控制台显示的Last modified不会更新。

2. Dataflow作业的残留任务执行 #

Dataflow作业的停止操作（比如Cancel）不会立即终止所有正在运行的任务：

• 作业停止时，部分已经获取到数据、处于写入流程中的任务会继续执行，直到完成写入或资源被回收。这些任务会使用作业运行时创建的流进行写入，从而产生8月12日之后的AppendRows日志，但写入的数据本质是作业停止前就已在处理的内容，不会改变表的最终Last modified时间。

3. BigQuery控制台元数据缓存延迟 #

BigQuery控制台的表详情页面存在元数据缓存机制：

• 控制台不会实时刷新表的Last modified信息，而是定期同步。如果8月26日的写入是近期发生的，控制台可能还未完成元数据刷新，导致显示的仍是8月12日的时间。你可以通过BigQuery CLI命令bq show --format=prettyjson test-development:test_dataset.test_table查看lastModifiedTime字段，获取实时的修改时间。

4. 未清理的流资源导致的后续写入 #

Dataflow使用Storage Write API时会创建专用写入流，作业停止后流可能未被立即清理：

• 如果流的生命周期配置为长期有效，可能存在重试机制或残留进程继续使用该流写入数据。不过你的日志中insertedRowsCount显示为13，说明数据已成功插入，这种情况下大概率是BigQuery元数据更新的延迟。

5. 存在其他未察觉的写入源 #

即便你停止了目标Dataflow作业，可能还有其他进程在写入该表：

• 比如共享同一服务账号的其他Dataflow作业、Cloud Function、手动写入操作等，这些都可能触发AppendRows调用。你可以排查项目内的其他服务或作业，确认是否有额外的写入来源。

内容的提问来源于stack exchange，提问作者SRJ