一、为什么11月中旬到12月初的数据没进对应分区？ #

结合你用Timestamp列分区、每日流式写入百万级数据的场景，大概率是这几个原因之一：

• 分区列数据出问题了：那段时间写入的Timestamp字段可能踩了坑——比如出现了NULL值、格式错误，或者时区配置跑偏了。举个例子：如果你的表是按UTC日分区，但写入程序那段时间误把时间戳按本地时区生成，导致时间落在了预期分区范围之外，BigQuery就会把这些“无效”数据丢进UNPARTITIONED。
• 流式写入的临时故障：那段时间BigQuery的流式写入服务可能有短暂的波动，或者你的写入程序重试逻辑出了问题，导致数据没有被正确路由到对应分区。这种情况虽然不多见，但高频写入下偶尔会碰到。
• 表元数据同步延迟：极端情况下，百万级的高频写入可能暂时压垮了分区表的元数据同步，导致那段时间的分区没能及时创建，数据只能暂存到UNPARTITIONED。不过这种情况通常会自动修复，但如果当时写入量特别大，就可能遗留这个问题。

二、怎么把UNPARTITIONED的数据“挪”到对应分区？ #

BigQuery没有直接的“刷新分区”命令，但可以通过安全的分步操作来迁移数据，还不会影响实时流式写入：

1. 先把历史UNPARTITIONED数据导到临时表：
   流式缓冲区里的实时数据（就是你说的今早小峰值）还没固化，不能碰。我们先把11-12月的历史数据导出来，过滤掉最近1小时的流式数据：

   CREATE OR REPLACE TABLE `your_project.your_dataset.temp_historical_data`
   AS SELECT * FROM `your_project.your_dataset.your_partitioned_table`
   WHERE _PARTITIONTIME IS NULL AND _STREAMING_TIMESTAMP < TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR);
   

2. 从原表删除已导出的历史数据：
   确保只删我们已经备份好的部分，别碰实时数据：

   DELETE FROM `your_project.your_dataset.your_partitioned_table`
   WHERE _PARTITIONTIME IS NULL AND _STREAMING_TIMESTAMP < TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR);
   

3. 把临时表数据插回原表：
   这时候BigQuery会自动根据每条数据的Timestamp列值，把它们分配到对应的日分区里：

   INSERT INTO `your_project.your_dataset.your_partitioned_table`
   SELECT * FROM `your_project.your_dataset.temp_historical_data`;
   

4. 清理临时表：
   数据迁移完成后就可以删掉临时表了：

   DROP TABLE `your_project.your_dataset.temp_historical_data`;
   

注意事项： #

• 操作前一定要先备份数据！可以先把UNPARTITIONED数据全量导出到GCS或者另一个表，避免误操作丢数据。
• 如果UNPARTITIONED数据量特别大，建议分批次处理，比如按日期范围拆分，避免单次操作占用过多资源导致超时。
• 流式缓冲区里的实时数据不用管，BigQuery会在几分钟到几小时内自动固化，然后把它们分配到对应分区。

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