排查配额和限制错误
BigQuery 设有各种配额和限制，用于限制不同请求和操作的速率和数量。它们都用于保护基础架构并防止意外的客户使用。本文档介绍了如何诊断和缓解由配额和限制导致的特定错误。
有些错误消息会指明您可以增加的配额或限制，而另一些错误消息会指明您无法增加的配额或限制。达到硬性限制意味着您需要为工作负载实施临时或永久性解决方法或最佳实践。即使是可增加的配额或限制，也最好这样做。
本文档会根据这些类别整理错误消息及其解决方案，而本文档后面的“概览”部分会介绍如何解读错误消息并应用正确的解决方案来解决问题。
如果本文档中未列出您的错误消息，请参阅错误消息列表，其中提供了更通用的错误信息。
概览
如果 BigQuery 操作因超出配额而失败，API 会返回 HTTP 403 Forbidden 状态代码。响应正文会详细说明已达到的配额。响应正文类似于以下内容：
{
"code" : 403,
"errors" : [ {
"domain" : "global",
"message" : "Quota exceeded: ...",
"reason" : "quotaExceeded"
} ],
"message" : "Quota exceeded: ..."
}
载荷中的 message 字段会说明超出了哪个限制。例如，message 字段可能会显示 Exceeded rate limits: too many table
update operations for this table。
一般来说，配额限制分为两类，由响应载荷中的 reason 字段指示。
rateLimitExceeded。该值表示短期限制。如需解决这些限制问题，请在几秒后重试执行此操作。在两次重试尝试之间使用指数退避算法。也就是说，以指数方式增加每次重试之间的延迟时间。quotaExceeded。该值表示长期限制。如果您达到了长期配额上限，则应等待 10 分钟或更长时间，然后再重试操作。如果您持续达到其中一个长期配额限制，则应分析您的工作负载以寻求缓解问题的方法。缓解措施可能包括优化工作负载或申请增加配额。
对于 quotaExceeded 错误，请检查错误消息以了解超出了哪个配额限制。然后分析您的工作负载，查看能否避免达到配额。
在某些情况下，您可以通过与 BigQuery 支持团队联系或与 Cloud de Confiance by S3NS 销售人员联系来增加配额，但我们建议您先尝试本文档中列出的建议。
诊断
如需诊断问题，请执行以下操作：
使用
INFORMATION_SCHEMA视图以及区域限定符来分析底层问题。这些视图包含有关 BigQuery 资源（包括作业、预留和流式插入）的元数据。例如，以下查询使用
INFORMATION_SCHEMA.JOBS视图列出过去一天中与配额相关的所有错误：SELECT job_id, creation_time, error_result FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) AND error_result.reason IN ('rateLimitExceeded', 'quotaExceeded')
将
REGION_NAME替换为项目的区域。它必须以region-开头。例如，对于US多区域位置，请使用region-us。在 Cloud Audit Logs 中查看错误。
例如，使用 Logs Explorer，以下查询会返回消息字符串中包含
Quota exceeded或limit的错误：resource.type = ("bigquery_project" OR "bigquery_dataset") protoPayload.status.code ="7" protoPayload.status.message: ("Quota exceeded" OR "limit")在此示例中，状态代码
7表示PERMISSION_DENIED，它对应于 HTTP403状态代码。如需查看其他 Cloud Audit Logs 查询示例，请参阅 BigQuery 查询。
排查可增加的配额或限制
您可以提高以下配额和限额；不过，最好先尝试任何建议的解决方法或最佳实践。
您的项目已超出扫描的查询字节数免费配额
如果免费用量层级中运行查询时，并且账号达到每月可查询的数据大小限制，BigQuery 会返回此错误。如需详细了解查询价格，请参阅免费层级。
错误消息
Your project exceeded quota for free query bytes scanned
解决方法
如需继续使用 BigQuery，您需要将账号升级到付费 Cloud Billing 账号。
流式插入配额错误
本部分提供了一些有关排查与将数据流式插入 BigQuery 相关的配额错误的提示。
在某些区域中，如果您不为每一行填写 insertId 字段，则流式插入将具有更高的配额。如需详细了解流式插入的配额，请参阅流式插入。BigQuery 流式传输的配额相关错误取决于是否存在 insertId。
错误消息
如果 insertId 字段为空，则可能会出现以下配额错误：
| 配额限制 | 错误消息 |
|---|---|
| 每个项目每秒字节数 | REGION 区域内项目 PROJECT_ID 中 gaia_id 为 GAIA_ID 的实体已超出每秒插入字节数的配额。 |
如果填写了 insertId 字段，则可能会出现以下配额错误：
| 配额限制 | 错误消息 |
|---|---|
| 每个项目每秒的行数 | REGION 中的项目 PROJECT_ID 已超出每秒流式插入行数的配额。 |
| 每个表每秒的行数 | 表 TABLE_ID 已超出每秒流式插入行数的配额。 |
| 每个表每秒字节数 | 表 TABLE_ID 已超出每秒流式插入字节数的配额。 |
insertId 字段的用途是删除重复的插入行。如果具有相同 insertId 的多个插入内容均在几分钟之内发送至 BigQuery，则 BigQuery 将写入单个版本的记录。但是，我们无法保证系统会自动删除重复的数据。为了最大限度的提高流式数据处理效率，我们建议您不要添加 insertId，而是使用手动去重。如需了解详情，请参阅确保数据一致性。
诊断
使用 STREAMING_TIMELINE_BY_* 视图分析流式流量。这些视图会每隔一分钟汇总流式统计信息（按错误代码分组）。配额错误显示在结果中，其 error_code 等于 RATE_LIMIT_EXCEEDED 或 QUOTA_EXCEEDED。
根据达到的特定配额限制，请查看 total_rows 或 total_input_bytes。如果错误是表级配额，请按 table_id 进行过滤。
例如，以下查询显示每分钟注入的总字节数，以及配额错误总数：
SELECT start_timestamp, error_code, SUM(total_input_bytes) as sum_input_bytes, SUM(IF(error_code IN ('QUOTA_EXCEEDED', 'RATE_LIMIT_EXCEEDED'), total_requests, 0)) AS quota_error FROM `region-REGION_NAME`.INFORMATION_SCHEMA.STREAMING_TIMELINE_BY_PROJECT WHERE start_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) GROUP BY start_timestamp, error_code ORDER BY 1 DESC
解决方法
要解决此配额错误，请执行以下操作：
如果您使用
insertId字段进行重复信息删除，并且您的项目位于支持较高流式配额的区域中，我们建议您移除insertId字段。此解决方案可能需要执行一些额外的步骤来手动移除重复数据。如需了解详情，请参阅手动移除重复数据。如果您未使用
insertId，或者不能将其移除，请监控 24 小时时间段的流式流量并分析配额错误：如果您看到的大多数是
RATE_LIMIT_EXCEEDED错误而不是QUOTA_EXCEEDED错误，而您的总体流量低于配额的 80%，则这些错误可能指示暂时达到峰值。您可以通过在两次重试之间使用指数退避算法来重试操作，以消除这些错误。如果您使用 Dataflow 作业插入数据，请考虑使用加载作业，而非流式插入。如需了解详情，请参阅设置插入方法。如果您将 Dataflow 与自定义 I/O 连接器搭配使用，请考虑改为使用内置 I/O 连接器。如需了解详情，请参阅自定义 I/O 模式。
如果您看到
QUOTA_EXCEEDED错误或总体流量持续超过配额的 80%，请提交增加配额的申请。如需了解详情，请参阅申请配额调整。您可能还希望考虑将流式插入替换为新的 Storage Write API，该 API 具有更高的吞吐量、更低的价格和许多实用功能。
包含远程函数的并发查询数上限
如果包含远程函数的并发查询数量超过限制，BigQuery 会返回此错误。不过，此限制可以提高。请先尝试解决方法和最佳实践。
如需详细了解远程函数限制，请参阅远程函数。
错误消息
Exceeded rate limits: too many concurrent queries with remote functions for this project
诊断
如需查看有关包含远程函数的并发查询的限制，请参阅远程函数限制。
解决方法
CREATE MODEL 语句数上限
此错误表示您已超出 CREATE MODEL 语句的配额。
错误消息
Quota exceeded: Your project exceeded quota for CREATE MODEL queries per project.
解决方法
如果您超出 CREATE MODEL 语句的配额，请发送电子邮件至 bqml-feedback@google.com 并申请增加配额。
与每个项目每天的复制作业数上限有关的配额错误
如果项目中运行的复制作业数超过每日上限，BigQuery 将返回此错误。如需详细了解每天的复制作业数限制，请参阅复制作业。
错误消息
Your project exceeded quota for copies per project
诊断
如果您想收集有关复制作业来源的更多数据，您可以尝试以下操作：
如果您的复制作业位于单个或少数几个区域，您可以尝试查询特定区域的
INFORMATION_SCHEMA.JOBS表。例如：SELECT creation_time, job_id, user_email, destination_table.project_id, destination_table.dataset_id, destination_table.table_id FROM `PROJECT_ID`.`region-REGION_NAME`.INFORMATION_SCHEMA.JOBS WHERE creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 2 DAY) AND CURRENT_TIMESTAMP() AND job_type = "COPY" order by creation_time DESC
您还可以根据相关时间范围调整时间间隔。
如需查看所有区域中的全部复制作业，您可以在 Cloud Logging 中使用以下过滤条件：
resource.type="bigquery_resource" protoPayload.methodName="jobservice.insert" protoPayload.serviceData.jobInsertRequest.resource.jobConfiguration.tableCopy:*
解决方法
- 如果频繁复制操作的目标是创建数据快照，请考虑改用表快照。与复制完整表相比，表快照更具成本效益、速度上也更快。
- 您可以联系支持团队或销售人员以申请增加配额。审核和处理请求可能需要几天时间。我们建议您在请求中注明优先级、用例和项目 ID。
超出每日提取字节数配额错误
如果提取超出项目中的默认 50 TiB 每日限制，BigQuery 会返回此错误。如需详细了解提取作业限制，请参阅提取作业。
错误消息
Your usage exceeded quota for ExtractBytesPerDay
诊断
如果您要导出的表大于 50 TiB，则导出会失败，因为它超出提取限制。如需解决此问题，请参阅解决方法。如果您想对特定表分区导出表数据，可以使用分区修饰器来标识要导出的分区。
如果您想收集最近几天导出数据的用量，可以尝试以下操作：
查看项目的配额，并使用过滤条件（例如
Name: Extract bytes per day或Metric: bigquery.googleapis.com/quota/extract/bytes）以及“显示用量”图表，以了解几天内的用量趋势。或者，您也可以查询
INFORMATION_SCHEMA.JOBS_BY_PROJECT，以了解几天内的总提取字节数。例如，以下查询会返回过去 7 天内EXTRACT作业每天处理的总字节数。SELECT TIMESTAMP_TRUNC(creation_time, DAY) AS day, SUM ( total_bytes_processed ) / POW(1024, 3) AS total_gigabytes_processed FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP() AND job_type = "EXTRACT" GROUP BY 1 ORDER BY 2 DESC
然后，您可以确定消耗的字节数超出预期的特定作业，从而进一步优化结果。以下示例会返回过去 7 天内消耗的处理量超过 100 GB 的前 100 个
EXTRACT作业。SELECT creation_time, job_id, total_bytes_processed/POW(1024, 3) AS total_gigabytes_processed FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP() AND job_type="EXTRACT" AND total_bytes_processed > (POW(1024, 3) * 100) ORDER BY total_bytes_processed DESC LIMIT 100
或者，您也可以使用 Jobs Explorer 以及 Bytes processed more than 等过滤条件来过滤指定时间段内的高处理量作业。
解决方法
解决此配额错误的一种方法是创建一个槽预留，并将您的项目分配到具有 PIPELINE 作业类型的预留中。此方法可以绕过限制检查，因为它会使用您的专用预留，而不是免费共享槽池。如果您以后想使用共享槽池，可以根据需要删除预留。
如需了解允许导出超过 50 TiB 的替代方法，请参阅提取作业中的“备注”部分。
与每个项目每秒的 tabledata.list 字节数上限有关的配额错误
如果错误消息中提及的项目编号所对应的项目达到每个项目每秒可通过 tabledata.list API 调用读取的数据大小上限，BigQuery 将返回此错误。如需了解详情，请参阅每分钟 tabledata.list 字节上限。
错误消息
Your project:[project number] exceeded quota for tabledata.list bytes per second per project
解决方法
要解决此错误，请执行以下操作：
- 一般来说，我们建议不要超出此限制；例如，通过延长各请求之间的间隔时间。如果该错误没有频繁发生，则使用指数退避算法实现重试可以解决此问题。
- 如果您的用例需要快速、频繁地从表中读取大量数据，我们建议使用 BigQuery Storage Read API，而不是
tabledata.listAPI。 如果上述建议不起作用，您可以执行以下操作，以从Cloud de Confiance 控制台 API 信息中心申请增加配额：
- 前往Cloud de Confiance 控制台 API 信息中心。
- 在该信息中心内，过滤配额：
Tabledata list bytes per minute (default quota)。 - 选择配额，然后按照申请配额调整中的说明操作。
审核和处理请求可能需要几天时间。
API 请求的最大数量限制错误
如果针对每种方法，您的每个用户对 BigQuery API 发出的 API 请求数量达到速率限制，BigQuery 将返回此错误，例如，来自服务账号的 tables.get 方法调用，或来自不同用户电子邮件的 jobs.insert 方法调用。如需了解详情，请参阅 BigQuery API 中的每种方法每个用户每秒的 API 请求数上限速率限制。
错误消息
Quota exceeded: Your user_method exceeded quota for concurrent api requests per user per method.
诊断
如果您尚未确定达到此速率限制的方法，请执行以下操作：
对于服务账号
在 Cloud de Confiance 控制台中，前往 API 信息中心。
如需获得有关如何查看 API 详细使用情况信息的说明，请参阅使用 API 信息中心。
在 API 信息中心内，选择 BigQuery API。
如需查看更详细的使用情况信息，请选择指标，然后执行以下操作：
对于选择图表，选择流量（按 API 方法）。
按服务账号的凭据过滤图表。您可能会在发现错误的时间范围内看到某个方法的相关数据激增。
对于 API 调用
某些 API 调用会在 Cloud Logging 的 BigQuery 审核日志中记录错误。如需确定达到限制的方法，请执行以下操作：
在 Cloud de Confiance 控制台中，前往 Cloud de Confiance 导航菜单 ，然后为您的项目选择 Logging > Logs Explorer：
运行以下查询来过滤日志：
resource.type="bigquery_resource" protoPayload.authenticationInfo.principalEmail="<user email or service account>" "Too many API requests per user per method for this user_method" In the log entry, you can find the method name under the property protoPayload.method_name.
如需了解详情，请参阅 BigQuery 审核日志概览。
解决方法
要解决此配额错误，请执行以下操作：
减少 API 请求数，或增加多次 API 请求之间的延迟时间，以使请求数保持在此限制内。
如果只是偶尔超出该限制，您可以使用指数退避算法，在遇到此特定错误时重试。
如果您经常插入数据，请考虑使用流式插入，因为流式插入不受 BigQuery API 配额的影响。但是，流式插入 API 需要收取相关费用，并且具有自己的一组限制和配额。
如需了解流式插入的费用，请参阅 BigQuery 价格。
使用 Dataflow 和 BigQuery I/O 连接器将数据加载到 BigQuery 时，您可能会遇到
tables.get方法的此错误。如需解决此问题，请执行以下操作：将目标表的创建处置方式设置为
CREATE_NEVER。如需了解详情，请参阅创建处置方式。使用 Apache Beam SDK 2.24.0 或更高版本。在旧版 SDK 中，
CREATE_IF_NEEDED处置会调用tables.get方法以检查表是否存在。
您可以联系支持团队或销售人员以申请增加配额。如需额外的配额，请参阅申请增加配额。增加配额申请可能需要几天的时间才能处理完毕。为了在您的请求中提供更多信息，我们建议您的请求包含作业的优先级、运行查询的用户以及受影响的方法。
排查无法提高的配额或限制
您无法提高以下配额或限制，但可以应用建议的解决方法或最佳实践来缓解这些限制。
查询队列限制错误
如果项目尝试排入队列的交互式查询或批量查询数目超出了其队列限制，则可能会遇到此错误。
错误消息
Quota exceeded: Your project and region exceeded quota for max number of jobs that can be queued per project.
解决方法
此限制无法提高。要解决此配额错误，请执行以下操作：
暂停作业。如果您确定是某个进程或流水线导致查询数增加，则暂停该进程或流水线。
使用具有批量优先级的作业。与交互式查询相比，您可以将更多批量查询排入队列。
分发查询。根据查询的性质和业务需求，将负载组织和分发到不同的项目中。
分散运行时间。将负载分散到更长的时间范围内。如果您的报告解决方案需要运行许多查询，请尝试在查询开始时引入一些随机性。例如，不同时启动所有报告。
使用 BigQuery BI Engine。如果您在使用商业智能 (BI) 工具创建在 BigQuery 中查询数据的信息中心时遇到此错误，我们建议您使用 BigQuery BI Engine。在这种用例下，BigQuery BI Engine 是最佳选择。
优化查询和数据模型。通常，您可以重写查询，以便提高其运行效率。例如，如果您的查询包含通用表表达式 (CTE) -
WITH子句（在查询的多个位置引用），则此计算会完成多次。最好将 CTE 完成的计算保存到临时表中，后续在查询中引用它。多次联接也可能会造成低效。在这种情况下，您可能希望考虑使用嵌套和重复的列。这种方法通常可以提高数据的局部化程度，消除对于部分联接的需求，并且从整体上减少资源消耗量并缩短查询运行时长。
优化查询可以降低其费用，这样在您使用基于容量的定价时，就能通过自己的槽运行更多查询。如需了解详情，请参阅优化查询性能简介。
优化查询模型。BigQuery 不是关系型数据库，它并未针对无限数量的小型查询进行过优化。运行大量小型查询会造成您的配额快速耗尽。使用小型数据库产品运行这些查询的效率要更高。BigQuery 是一个大型数据仓库，这也是其主要用例。它最适合用于对大量数据执行分析查询。
保留数据（已保存的表）。预处理 BigQuery 中的数据，并将其存储在其他表中。例如，如果使用不同的
WHERE条件执行许多类似的计算密集型查询，则系统不会缓存其结果。每次运行此类查询时也会消耗资源。通过预计算数据并将其存储在表中，您就可以提高此类查询的性能并缩短其处理时间。表中的这种预先计算的数据可通过SELECT查询进行查询。这通常可以在 ETL 过程中的注入期间完成，或者使用计划查询或物化视图完成。使用试运行模式。在试运行模式下运行查询，此模式会估算读取的字节数，但不会实际处理查询。
预览表数据。 如需试验或探索数据而不是运行查询，请使用 BigQuery 中的表预览功能来预览表数据。
使用缓存的查询结果。 所有查询结果（包括交互式查询和批量查询）都会在临时表中缓存大约 24 小时，但有一些例外情况。 虽然运行缓存的查询仍会计入并发查询限制，但使用缓存结果的查询速度比不使用缓存结果的查询明显更快，因为 BigQuery 不需要计算结果集。
Shuffle 大小限制错误
如果您的项目超出了可用于 shuffle 操作的磁盘和内存大小上限，BigQuery 会返回此错误。
此配额按预留计算，并根据预留在项目间划分。Cloud Customer Care 无法修改配额。您可以通过查询 INFORMATION_SCHEMA.JOBS_TIMELINE 视图来详细了解您的用量。
错误消息
您会收到以下某条错误消息：
Quota exceeded: Your project exceeded quota for total shuffle size limit.
Resources exceeded: Your project or organization exceeded the maximum disk and memory limit available for shuffle operations. Consider provisioning more slots, reducing query concurrency, or using more efficient logic in this job.
解决方法
要解决此错误，请执行以下操作：
列分区表的分区修改数配额错误
如果您的列分区表达到每天允许的分区修改次数配额，BigQuery 会返回此错误。分区修改包括可附加或覆盖目标分区的所有加载作业、复制作业和查询作业的总数。
如需查看每个列分区表每天的分区修改数限制的值，请参阅分区表。
错误消息
Quota exceeded: Your table exceeded quota for Number of partition modifications to a column partitioned table
解决方法
此配额无法增加。要解决此配额错误，请执行以下操作：
- 请更改表的分区以在每个分区中添加更多数据，以减少分区总数。例如，从每天分区更改为每月分区，或更改对表进行分区的方式。
- 使用聚簇，而不是分区。
-
如果您经常从存储在 Cloud Storage 中的多个小文件中加载数据，此时每个文件会使用一个作业，请将多个加载作业合并到一个作业中。如需从多个 Cloud Storage URI 加载数据，您可以使用逗号分隔列表（例如
gs://my_path/file_1,gs://my_path/file_2），也可以使用通配符（例如gs://my_path/*）。如需了解详情，请参阅批量加载数据。
- 例如，如果您使用加载、选择或复制作业将单行数据附加到表，则应考虑将多个作业作为一个作业进行批量处理。用作关系型数据库时，BigQuery 的执行性能不佳。最佳实践是避免频繁运行单行附加操作。
- 如需高速率附加数据，请考虑使用 BigQuery Storage Write API。这是用于高性能数据注入的推荐解决方案。BigQuery Storage Write API 功能强大，包括“正好一次”传送语义。如需了解限制和配额，请参阅 Storage Write API，如需查看使用此 API 的费用，请参阅 BigQuery 数据注入价格。
-
如需监控表上的已修改分区数量，请使用
INFORMATION_SCHEMA视图。
表元数据更新操作的最大速率限制错误
当表达到标准表的每个表的表元数据更新操作速率上限时，BigQuery 会返回此错误。表操作包括附加或覆盖目标表的所有加载作业、复制作业和查询作业的合并总数，或者使用 DML DELETE、INSERT、MERGE、TRUNCATE TABLE 或 UPDATE 将数据写入表的合并总数。
如需查看每个表的表元数据更新操作的速率上限值，请参阅标准表。
错误消息
Exceeded rate limits: too many table update operations for this table
诊断
元数据表更新可以来自修改表元数据的 API 调用，或源自修改表内容的作业。如果您尚未确定表元数据的大多数更新操作的来源，请执行以下操作：
确定 API 调用
前往 Cloud de Confiance 导航菜单，然后选择 Logging > Logs Explorer：
通过运行以下查询来过滤日志，以查看表操作：
resource.type="bigquery_dataset" protoPayload.resourceName="projects/my-project-id/datasets/my_dataset/tables/my_table" (protoPayload.methodName="google.cloud.bigquery.v2.TableService.PatchTable" OR protoPayload.methodName="google.cloud.bigquery.v2.TableService.UpdateTable" OR protoPayload.methodName="google.cloud.bigquery.v2.TableService.InsertTable")
确定作业
以下查询返回过去一天内修改项目中受影响的表的作业列表。如果您希望组织中的多个项目写入表，请将 JOBS_BY_PROJECT 替换为 JOBS_BY_ORGANIZATION。
SELECT job_id, user_email, query FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) AND destination_table.project_id = "my-project-id" AND destination_table.dataset_id = "my_dataset" AND destination_table.table_id = "my_table"
如需了解详情，请参阅 BigQuery 审核日志概览。
解决方法
此配额无法增加。要解决此配额错误，请执行以下操作：
- 降低表元数据的更新速率。
- 在作业或表操作之间添加延迟，以确保将更新速率控制在限制范围内。
对于数据插入或修改，请考虑使用 DML 操作。DML 操作不会受到每个表的表元数据更新操作速率上限速率限制的影响。
DML 操作还有其他限制和配额。如需了解详情，请参阅使用数据操纵语言 (DML)。
-
如果您经常从存储在 Cloud Storage 中的多个小文件中加载数据，此时每个文件会使用一个作业，请将多个加载作业合并到一个作业中。如需从多个 Cloud Storage URI 加载数据，您可以使用逗号分隔列表（例如
gs://my_path/file_1,gs://my_path/file_2），也可以使用通配符（例如gs://my_path/*）。如需了解详情，请参阅批量加载数据。
- 例如，如果您使用加载、选择或复制作业将单行数据附加到表，则应考虑将多个作业作为一个作业进行批量处理。用作关系型数据库时，BigQuery 的执行性能不佳。最佳实践是避免频繁运行单行附加操作。
- 如需高速率附加数据，请考虑使用 BigQuery Storage Write API。这是用于高性能数据注入的推荐解决方案。BigQuery Storage Write API 功能强大，包括“正好一次”传送语义。如需了解限制和配额，请参阅 Storage Write API，如需查看使用此 API 的费用，请参阅 BigQuery 数据注入价格。
-
如需监控表上的已修改分区数量，请使用
INFORMATION_SCHEMA视图。
表导入或查询附加配额错误
在表达到标准表的每天表操作数限制时，BigQuery 将返回此错误消息。表操作包括附加或覆盖目标表的所有加载作业、复制作业和查询作业的总和。
如需查看每天的表操作数限制的值，请参阅标准表。
错误消息
Your table exceeded quota for imports or query appends per table
诊断
如果您尚未确定大多数表操作数来自何处，请执行以下操作：
记下失败的查询、加载或复制作业写入的项目、数据集和表。
使用
INFORMATION_SCHEMA.JOBS_BY_*表详细了解修改该表的作业。以下示例使用
JOBS_BY_PROJECT查找在过去 24 小时的时间段内，按照作业类型分组的作业的每小时计数。如果您希望多个项目写入表，请将JOBS_BY_PROJECT替换为JOBS_BY_ORGANIZATION。SELECT TIMESTAMP_TRUNC(creation_time, HOUR), job_type, count(1) FROM `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 1 DAY) AND destination_table.project_id = "my-project-id" AND destination_table.dataset_id = "my_dataset" AND destination_table.table_id = "my_table" GROUP BY 1, 2 ORDER BY 1 DESC
解决方法
此配额无法增加。要解决此配额错误，请执行以下操作：
-
如果您经常从存储在 Cloud Storage 中的多个小文件中加载数据，此时每个文件会使用一个作业，请将多个加载作业合并到一个作业中。如需从多个 Cloud Storage URI 加载数据，您可以使用逗号分隔列表（例如
gs://my_path/file_1,gs://my_path/file_2），也可以使用通配符（例如gs://my_path/*）。如需了解详情，请参阅批量加载数据。
- 例如，如果您使用加载、选择或复制作业将单行数据附加到表，则应考虑将多个作业作为一个作业进行批量处理。用作关系型数据库时，BigQuery 的执行性能不佳。最佳实践是避免频繁运行单行附加操作。
- 如需高速率附加数据，请考虑使用 BigQuery Storage Write API。这是用于高性能数据注入的推荐解决方案。BigQuery Storage Write API 功能强大，包括“正好一次”传送语义。如需了解限制和配额，请参阅 Storage Write API，如需查看使用此 API 的费用，请参阅 BigQuery 数据注入价格。
-
如需监控表上的已修改分区数量，请使用
INFORMATION_SCHEMA视图。
表的待处理 DML 语句过多
此错误表示针对同一表运行的并发变更 DML 语句（UPDATE、DELETE、MERGE）的数量已超过数据操纵语言 (DML) 配额限制。此配额限制按表计算，仅适用于变更 DML 语句，不包括 INSERT。
解决方法
遵循 DML 语句最佳实践，批量处理 DML 作业。
加载 CSV 文件配额错误
如果您使用带有 --allow_quoted_newlines 标志的 bq load 命令加载大型 CSV 文件，则可能会遇到此错误。
错误消息
Input CSV files are not splittable and at least one of the files is larger than
the maximum allowed size. Size is: ...
解决方法
要解决此配额错误，请执行以下操作：
- 将
--allow_quoted_newlines标志设置为false。 - 将 CSV 文件拆分为多个小于 4 GB 的较小区块。
如需详细了解在将数据加载到 BigQuery 时适用的限制，请参阅加载作业。
您的用户超出了并发 project.lists 请求的配额
当通过 Simba ODBC 驱动程序或 DataHub 与 BigQuery 通信的 Microsoft Power BI 作业因超出 project.list API 限制而失败时，会发生此错误。如需解决此问题，请使用本部分中介绍的短期或长期解决方法。
错误消息
Your user exceeded quota for concurrent project.lists requests
诊断
当 Power BI 报告刷新且 Simba 驱动程序与特定 BigQuery 项目建立连接时，Power BI 会在连接和发现阶段出现此错误。
短期解决方案
为了在短期内解决此问题，请使用以下解决方法（按效果从高到低排序）。根据您是使用 Simba 驱动程序还是使用 DataHub 连接到 BigQuery，实现三个或四个修复。
如需了解长期解决方案，请参阅长期解决方案。
错开报告刷新时间。如果您无法修改 DSN，请通过减少并发请求的数量来缓解配额问题。不要让所有报告同时刷新（例如，在上午 9:00），而是将它们的刷新时间安排错开几分钟（例如，在上午 9:01、9:03 和 9:05）。这种做法可将 API 调用分散到一段时间内，从而降低达到并发限制的可能性。
在 Power BI 中实现重试。这种被动策略有助于报告从临时故障中恢复。Power BI 针对数据刷新失败内置了重试逻辑。虽然这种做法无法防止配额错误，但它可以通过在 API 调用量初始峰值消退后，在后续尝试中成功生成报告，从而提高流水线的弹性。如需实现此修复，请执行以下操作：
- 在 Power BI 服务中，前往数据集的设置。
- 展开预定刷新部分。在重试下，将 Power BI 配置为自动重新运行失败的刷新。
对于早期版本的 Simba 驱动程序，请在 ODBC 连接中指定项目 ID。此操作可防止驱动程序执行
projects.list发现调用。而是直接连接到指定的项目，从而避免了不必要的 API 调用并解决了配额问题。如果未指定项目，较新的驱动程序会立即失败，并显示类似于
Unable to establish connection with data source. Missing settings: {[Catalog]}的消息。如需进行此修复，请执行以下操作：
- 在运行 Power BI 网关或 Power BI Desktop 的计算机上，打开 ODBC 数据源（64 位）应用。
- 在适用于 BigQuery 的 Simba ODBC 驱动程序的主设置界面上，在目录（项目）字段中填写您的特定 Cloud de Confiance 项目 ID，例如
my-gcp-project-id。
对于旧版 DataHub，请在 DataHub 提取配置中指定项目 ID。如果您使用的是 DataHub 而不是 Simba 驱动程序，请进行此修复。与 Simba 类似，较新版本的 DataHub 需要您指定项目 ID，否则将无法连接到 BigQuery。
为避免超出 DataHub 限制，请修改 DataHub 提取配置，以提供要扫描的项目 ID 的明确列表。这会阻止 DataHub 配置找到服务账号可以查看的所有项目。
在 BigQuery 源配方文件（通常为 YAML 文件）中，使用
project_ids配置来列出要注入的项目。然后，使用新配置重新部署 DataHub 提取配方。请参阅以下示例以及 DataHub 提供的这个更长的示例。以下是 DataHub 配置代码段的示例：
source: type: "bigquery" config: # Instead of relying on discovery, explicitly list the projects. # This avoids the problematic projects.list() API call. project_ids: - "YOUR_PRODUCTION_PROJECT_ID" - "YOUR_ANALYTICS_PROJECT_ID" - "ANOTHER_BQ_PROJECT"
长期解决方案
从长远来看，解决此错误消息的最佳方法是为每个函数创建单独的专用Cloud de Confiance 服务账号。例如，为所有 Power BI 报告创建一个服务账号，并为 DataHub 提取创建一个服务账号。
此最佳实践可将 API 使用情况隔离到单独的配额桶中，并防止 DataHub 中的高负载作业导致 Power BI 中的关键业务报告失败。
请按照以下部分中的行动方案来解决 Power BI 和 DataHub 中的长期配额错误。
第 1 阶段：准备
- 告知 Power BI 网关和 DataHub 配置的所有者，您将进行协调一致的更改，以解决持续发生的作业失败问题。
- 在 Cloud de Confiance 控制台中，创建两个新的服务账号，例如
sa-powerbi-gateway@...和sa-datahub-ingestion@...。 - 为 Power BI 和 DataHub 服务账号创建服务账号密钥。
- 通过分配以下 Identity and Access Management 角色，为每个新服务账号授予最低权限，使其能够在相关的 Identity and Access Management (IAM) 中执行任务。避免分配过于宽泛的角色，例如 ProjectEditor。
所需的角色
Power BI 的服务账号运行查询并从表中读取数据。在每个 Cloud de Confiance 包含 Power BI 必须访问的数据的项目中，向服务账号授予以下角色。如需详细了解这些角色，请参阅 BigQuery 角色。
- BigQuery Data Viewer：提供对数据集、表和视图的只读访问权限。
- BigQuery 作业用户：提供运行作业（包括查询）的权限，这对于 Power BI 执行其请求至关重要。
DataHub 提取的服务账号只需要读取元数据（例如表名称、架构和说明），而不需要读取表中的数据。为 DataHub 扫描的每个项目授予以下项目级角色。如需详细了解这些角色，请参阅 BigQuery 的 IAM 角色。
BigQuery Metadata Viewer：此角色专门用于读取元数据。它授予列出数据集和表以及查看其元数据的权限，但不授予对底层数据的访问权限。
第 2 阶段：协调发布
在低使用率期间，Power BI 管理员通过执行以下步骤来更新网关计算机上的 ODBC DSN 配置：
- 将身份验证方法更改为使用在上一步中创建的新
sa-powerbi-gateway@...服务账号密钥。 - 如果尚未作为短期修复措施执行，请在 ODBC 驱动程序的 Catalog (Project) 字段中输入 Cloud de Confiance项目 ID。
- 让 DataHub 所有者更新 BigQuery 源配置 YAML 文件。
- 指向在上一步中创建的新
sa-datahub-ingestion@...服务账号密钥。 - 如果尚未作为短期修复措施执行，请使用
project_ids参数明确列出要扫描的项目。 - 使用新配置重新部署 DataHub 提取配方。
第 3 阶段：验证和监控
为了验证和监控修复效果，Power BI 和 DataHub 管理员执行以下步骤：
- 手动触发几个关键 Power BI 报告的刷新和 DataHub 中的新提取运行。确认这些作业已成功完成，且未发生配额错误。
- 在 Cloud de Confiance 控制台中，前往 IAM 和管理 > 配额页面。
- 过滤出 BigQuery API 服务。
- 找到名为并发
project.lists请求数的配额，然后点击图表图标以查看一段时间内的用量。
管理员应看到此特定 API 调用的使用量大幅下降且保持在较低水平，这表明修复成功。