我使用新的 V2 格式通过控制台打开了审计日志,并创建了一个接收器以将它们导出回 BigQuery 进行分析:
即使我选择了 V2 格式,导出到 BigQuery 的表的列名中也都有“ v1 ”:
然后,当我尝试查询表时,由于列名超过 128 个字符,它会引发错误:
为什么使用 v1 命名架构导出审计日志,以及如何绕过超过 128 个字符限制的列名?
我使用新的 V2 格式通过控制台打开了审计日志,并创建了一个接收器以将它们导出回 BigQuery 进行分析:
即使我选择了 V2 格式,导出到 BigQuery 的表的列名中也都有“ v1 ”:
然后,当我尝试查询表时,由于列名超过 128 个字符,它会引发错误:
为什么使用 v1 命名架构导出审计日志,以及如何绕过超过 128 个字符限制的列名?
如何绕过超过 128 个字符限制的列名?
我认为问题不在于引用长命名列路径,而在于输出列的名称
因此,要解决旧 SQL 中的问题 - 您应该提供符合名称 cnvention 的别名。
或者只使用标准 SQL - 在这种情况下,别名默认是叶字段的名称(在这种情况下totalBilledBytes
)
#legacySQL
SELECT
protopayload_google_cloud_audit_auditlog.
servicedata_google_cloud_bigquery_logging_v1_auditdata.
jobCompletedEvent.
job.
jobStatistics.
totalBilledBytes AS totalBilledBytes
FROM [yourTable]
或者
#standardSQL
SELECT
protopayload_google_cloud_audit_auditlog.
servicedata_google_cloud_bigquery_logging_v1_auditdata.
jobCompletedEvent.
job.
jobStatistics.
totalBilledBytes
FROM `yourTable`
为什么使用 v1 命名架构导出审计日志?
v2 格式的导出是指包含审计日志有效负载的LogEntry 。
列名中的“v1”是 BigQuery AuditData 消息(特别是google.cloud.bigquery.logging.v1.AuditData
协议缓冲区)的版本,存储在日志条目的 proto 有效负载字段中。以 REST 风格描述的公共文档没有公开版本。