Google BigQuery/Cloud Storage 无效的源 uri 前缀错误答案

【问题标题】：Google BigQuery/Cloud Storage Invalid source uri prefix errorGoogle BigQuery/Cloud Storage 无效的源 uri 前缀错误
【发布时间】：2021-07-16 13:36:16
【问题描述】：

我们目前正在观察一个错误（至少我们希望这对我们没有任何影响），它会阻止 BigQuery 使用 Hive 分区 URI 前缀访问存储在 Google Cloud Storage（外部表）中的数据。

我们的设置工作了几个月，没有任何变化，从昨天开始，我们只是遇到了一个错误

错误代码 3：无效值：无效的源 uri 前缀：...

当我们的计划查询尝试运行时。

我们可以在不分区的情况下访问数据，但在 Hive Partitioning URI Prefix 的错误中运行。

还有其他人看到这种行为吗？

干杯

【问题讨论】：

没有观察到这一点，但可能是最近添加到 GCS 存储桶中的文件/对象违反了 Hive 分区方案的定义模式？
您是否能够创建一个新的外部表来访问该存储桶并指定分区？
您似乎需要在存储桶中创建第一个文件夹，然后使用您的配置单元分区字段创建路径（例如：gs://bucket-name/table-name/{partition_field1:STRING}/{partition_field2:STRING}）
是的，我们正在经历这个......它影响了我们约 10% 的批量交易 atm 并且 AFAIK 不是来自我们对项目或源数据的更改

标签： google-bigquery google-cloud-storage

【解决方案1】：

AFAIK 此问题始终在且仅在具有以下字段/值定义 (bigquery.v2.table) objectsPrefix: /* 的分区 EXTERNAL TABLEs 上发生。

对于我们的组织，当没有对象前缀并且 partitionsPrefix 在存储桶的根目录中可用时，就会发生此定义。由于历史原因，这会影响约 100 个外部表定义中的 10 个。因此，手动修复相当容易。

我们的临时解决方案是将源数据移动到存储桶中的子目录（前缀）并相应地更新表定义。

到目前为止，这已经奏效。但我们显然正在向 Google 提出支持请求，并希望找出真正的解决方案或真正的问题，因为这感觉不像正确的行动方案。

同样，我想把它添加到这个聊天中，以防它暂时帮助其他人。并跟踪此聊天，以防找到更长期的解决方案。

【讨论】：

这可能是一个真正的痛苦......问题：您为什么决定为 90 个“其他”存储桶添加前缀？不在文档中的 AFAIK（似乎在 16 日更新）
其他存储桶只是简单地加上前缀，因为发出原始数据的作业刚刚被配置为这样做。这只是运气。

【解决方案2】：

截至 2021 年 7 月 20 日星期二 08:20 美国/太平洋地区，所有受影响项目的 Google BigQuery 问题均已解决。

【讨论】：