在时间分区的 bigquery 表中，数据何时写入_UNPARTITIONED_？有啥影响？

Posted 2023-03-24

【中文标题】在时间分区的 bigquery 表中，数据何时写入_UNPARTITIONED_？有啥影响？

【英文标题】：In time-partitioned bigquery tables, when is data written to __UNPARTITIONED__? what are the effects?在时间分区的 bigquery 表中，数据何时写入_UNPARTITIONED_？有什么影响？

【发布时间】：2016-06-13 14:44:18

【问题描述】：

我遇到了时间分区 bigquery 表的一些奇怪的未记录行为：

我在 BigQuery 中创建了一个时间分区表并插入了数据。 我能够正常插入 - 数据已写入今天的分区（我也能够显式指定一个分区并写入它）

经过一些新数据的测试，我删除了今天的分区，以便有干净的数据：（CLI）

bq --project_id=my-project rm v1.mytable$20160613

然后我检查它是否为空：

select count(*) from [v1.mytable]

结果 270 而不是 0

我尝试再次删除并重新运行查询 - 结果相同。 于是我查询了

select count(*) from [v1.mytable$20160613]

结果 0

所以我之前可能插入了数据的几个日期，但都是 0。 最后我跑了

SELECT partition_id from [v1.mytable$__PARTITIONS_SUMMARY__];

结果是

未分区 20160609 20160613

所有的数据实际上都在UNPARTITIONED

我的问题：

数据何时写入此特殊分区而不是日常分区，如何避免这种情况？ 除了失去处理特定日期的能力（在查询中，或在删除数据时等）之外，是否还有其他影响？我应该处理这个案子吗？

【问题讨论】：

cloud.google.com/bigquery/… 文档说明：当有足够的未分区数据时，将数据分区到相应的分区

【参考方案1】：

当数据在流缓冲区中时，它仍保留在 UNPARTITIONED 分区中。要在查询中处理此分区，您可以为 _PARTITIONTIME 伪列使用值 NULL。

SELECT ... FROM mydataset.mypartitioned_table WHERE _PARTITIONTIME IS NULL

要删除给定分区的数据，我们建议使用返回空结果的查询对其进行写入截断。例如：

bq query --destination_table=mydataset.mypartitionedtable\$20160121 --replace 'SELECT 1 as field1, "one" as field2 FROM (SELECT 1 as field1, "one" as field2) WHERE FALSE'

请注意，分区仍然存在（如果您从 table$__PARTITIONS__SUMMARY 执行 SELECT *），但它将有 0 行。

$ bq query 'SELECT COUNT(*) from [mydataset.mypartitionedtable$20160121]'

+-----+
| f0_ |
+-----+
|   0 |
+-----+

【参考方案2】：

这是一个临时状态——一个小时后查询所有属于今天分区的记录。

因此效果类似于数据写入的延迟：插入后立即查询可能没有正确分区中的最新数据，但最终这会没问题