Google bigquery totalBytesBilled与totalBytesProcessed不同

Google bigquery totalBytesBilled与totalBytesProcessed不同,google-bigquery,Google Bigquery,我正在使用streak BigQuery开发工具,并注意到“查询成本”中的一些wierd行为。在深入研究细节时,我发现totalBytesBilled和totalBytesProcessed属性中存在一种奇怪的行为。 但我在理解上有点困难 从BigQuery资源: statistics.query.totalBytesBilled:为作业计费的总字节数 statistics.query.totalBytesProcessed:为 工作 这两个属性的描述非常模糊 根据我过去的经验,我希望在我消

我正在使用streak BigQuery开发工具,并注意到“查询成本”中的一些wierd行为。在深入研究细节时,我发现totalBytesBilled和totalBytesProcessed属性中存在一种奇怪的行为。 但我在理解上有点困难

从BigQuery资源:

  • statistics.query.totalBytesBilled:为作业计费的总字节数
  • statistics.query.totalBytesProcessed:为 工作
这两个属性的描述非常模糊

根据我过去的经验,我希望在我消费完配额中的免费部分后,这两项将是相同的

对样本数据集的样本查询

SELECT word,    word_count 
FROM [publicdata:samples.shakespeare] S
LIMIT 1000
返回:

   "totalBytesProcessed": "2650191",
   "totalBytesBilled": "10485760",
  • 有人能更好地解释一下这些属性是什么,它们之间有什么区别吗
  • 为什么对于一些(相当小的)查询,我得到的totalBytesBilled要比totalBytesProcessed高得多
  • 它们是如何计算的
  • 优化我的查询以最小化“totalBytesBilled”的任何提示
  • 其中说:“高计算层适用于使用 相对于 已扫描字节。例如,包含非常大的 联接或交叉联接子句的数目,或复杂用户定义的数目 处理要求高的功能(UDF)。” 你能说得更具体些吗?有多少是“非常多的连接子句”?什么使UDF“复杂”

  • 谢谢

    此处完整记录了查询定价:

    要具体回答您的问题,请执行以下操作:

  • totalBytesProcessed
    字段告诉您查询处理(读取)了多少数据。
    totalBytesBilled
    字段告诉您实际计费的字节数。它们通常是相同的,但在某些情况下(见下文)或运行“高计算”查询时(见上文链接)可能有所不同

  • 每个查询至少有10 MB的内存,每个引用的表至少有10 MB的内存,以考虑开销。这些最小值(如上所述)是导致您注意到的差异的原因。这些费用以前在生成账单时应用,但以前未通过此API报告。通过添加
    totalBytesBilled
    字段,我们现在可以向您显示这些额外的账单详细信息。(请注意,此处涉及的实际美元金额非常小:每TB 5美元,10 MB为0.000005美元。如果您以10 MB的最低限额运行每日100000次查询,您只需支付5美元。)

  • 数据大小计算记录在案,上面的链接解释了如何将数据大小计算转换为每个查询的价格

  • 一般来说,只参考你关心的数据。考虑使用或限制查询查询的数据范围。请注意,
    LIMIT
    操作符限制结果的大小,但不限制扫描/计费的数据量

  • 我们不能给出具体的数字,因为有很多变量会影响查询的计算强度。连接(特别是交叉连接)可能会很昂贵,因为它们会使查询处理的数据量成倍增加,这会消耗比我们为查询预算更多的资源。UDF可能很昂贵,因为它们可以为每一行执行大型计算(嵌套循环、复杂的控制流)。但是,少数输出与输入大小成比例的联接,或执行与输入数据大小成比例的适度计算的UDF,仍应属于第1层

    考虑这一变化的一种方法是,我们有一个预算,用于根据
    totalBytesProcessed
    对给定查询投入的计算资源量。像UDF这样的新特性使查询更容易超出预算,我们希望为用户提供一种支付高计算查询费用的方式,而不仅仅是导致他们的查询失败

    如果您想计划此更改,可以观察
    totalBytesBilled
    billingTier
    字段,查看哪些查询需要在更高的层上运行。如果选择在更高级别上运行查询,请参阅,以获取有关如何按查询或按项目选择加入的详细信息


  • 根据我的理解,公式是

    SELECT MAX(cost) as totalBytesBilled FROM 
    (SELECT 10485760 as cost) as min_billed_10MB_bytes, 
    (SELECT INTEGER(1024*1024*CEIL(totalBytesProcessed/1024/1024)) as cost) as processed_rounded_up_to_MB_bytes 
    

    所以在我的例子中,差异是由最小尺寸引起的。请参阅对我的原始问题的编辑,要求对查询层进行详细说明。有没有一种方法可以基于干运行来估计“totalBytesBilled”?没有——至少对于高计算来说不是这样,我假设您要的是高计算。高计算的全部意义在于,在实际运行查询之前,我们不可能预测查询的实际成本。totalBytesProcessed是我们的最佳估计值(给定一个固定的计算资源预算),但是如果查询超出了tier 1计算预算,totalBytesBilled可能会更大。在实际运行之前我们不会知道。我如何更改查询的maximumBillingTier?@没有名字,我很快会给你答案的。有一些微妙之处需要注意。首先,每个查询和每个表的最小容量为10 MB,因此,如果在查询中引用3个表,则最小容量为30 MB。其次,如果您的查询位于高计算层,totalBytesBilled可能是totalBytesProcessed的倍数。谢谢Jeremy。我错过了那几张桌子!关于计费层-这将从2016年1月1日起生效?这是否正确?正确,分层自2016年1月1日起生效。