Apache Beam/Google Cloud Dataflow BigQuery二次运行清空数据集而非更新分区问题

核心诱因 #

现有贴出的代码仅包含BigQuery数据读取、TableRow转实体类的逻辑，缺失最关键的BigQuery写入端配置，这也是导致线上Dataflow Runner和本地Direct Runner行为不一致的核心原因——两者对BigQueryIO写入的默认行为存在差异，尤其在分区表写入、分区替换的语义逻辑上。

常见遗漏的配置问题 #

• 整表写入disposition配置错误
  期望的行为是仅替换目标分区数据、保留其他所有分区的历史内容，但如果没有在写入端显式声明写入逻辑，Dataflow Runner会默认触发整表覆盖语义：
  最常见的踩坑点是直接给BigQueryIO的写入设置了WRITE_TRUNCATE模式。这种模式下作业启动时会先清空整个目标表，再写入当前批次的计算结果，完全匹配当前现象：第一次运行时目标表是空的，清空操作没有影响，生成的分区表符合预期；第二次运行时会先把整个表的所有历史分区全部清空，只写入当前批次的对应分区数据，表现为“清空数据集中的现有结果，没有完成单分区替换”。
  对应修正的写入配置参考：

  BigQueryIO.<Model>write()
    .to(dynamicTableSpec -> String.format("%s.%s.%s", project, dataset, targetTable))
    .useAvroLogicalTypes()
    .withCreateDisposition(CreateDisposition.CREATE_IF_NEEDED)
    // 基础写入模式选追加，不要用整表覆盖
    .withWriteDisposition(BigQueryIO.Write.WriteDisposition.WRITE_APPEND)
    // 实现单分区替换需要搭配动态分区路由，不要整表截断
    .withTimePartitioning(...)
    .withMethod(Method.FILE_LOADS)
    .withAutoSharding()
  

  本地Direct Runner调试时，往往因为指向独立的测试表、或者本地模拟BigQuery服务的逻辑差异，不会触发整表截断的行为，所以表现正常。
• 动态分区路由配置缺失
  如果要实现“仅替换单分区”的效果，必须在写入时显式为每一条数据匹配对应的目标分区值。如果缺失这个配置，Dataflow Runner会把所有写入的数据归属为整表的内容，一旦搭配了整表截断逻辑，就会出现历史数据被全部清空的问题。
• 临时路径配置异常
  Dataflow Runner执行BigQuery批量加载时，会通过GCS路径中转临时加载文件。如果没有显式配置合法的GCS临时路径、或临时BigQuery数据集权限不对，会触发错误的表清理逻辑，连带影响正式表的数据。本地Direct Runner运行时临时路径默认指向本地磁盘，不会触发这类权限校验问题，所以运行正常。

快速排查方法 #

• 查看对应Dataflow作业的写入步骤日志，搜索是否存在Truncating table before load类的关键字，如果存在即可确认是整表截断配置错误。
• 全局检查Pipeline构建的参数配置，确认没有在全局选项中默认设置BigQuery写入disposition为WRITE_TRUNCATE，未对分区写入场景做单独覆盖。

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