Python 资源超出限制大查询

查询每次运行大约处理20GB的数据

我的表ZZZ有396567431（3.96亿）行，大小为53GB。如果我在没有LIMIT子句的情况下执行上述查询，则会出现一个错误，显示“资源已超出”

如果我使用LIMIT子句执行它，那么对于更大的限制，它会给出相同的错误

我正在使用运行上述查询的API编写一个python脚本，然后计算一些指标，然后将输出写入另一个表。它写入了大约170万个输出行，因此基本上是基于A列聚合第一个表，即原始表有多个A列行

现在我知道我们可以将Allow large results设置为on，并选择一个输出表来绕过此错误，但就我的脚本而言，它并不满足此目的

另外，我读到order by是造成这种情况的主要原因，但下面是我的算法，我看不到解决order by的方法

此外，我的脚本一次分页查询结果100000行

SELECT A,B, C, D, E, F ,EXTRACT(MONTH FROM PARSE_DATE('%b',Month)) 
as MonthNumber,PARSE_DATETIME(' %Y%b%d ', CONCAT(CAST(Year AS STRING),Month,'1'))  
as G FROM `XXX.YYY.ZZZ` 
where A !='null' and B = 'MYSTRING' order by A,Year

我有两个问题：

A栏| B栏。。。。。。 123 | NDG

123 | KOE

123 | TR

345 |流行音乐

345 |科普

345 |波尔

我保持逻辑的方式是：我遍历行并检查列A是否与最后一行列A相同。如果相同，则将该行添加到数组中。当我遇到不同的列a即345时，我发送第一组列a进行处理、计算并将数据添加到数组中。基于这种方法，我有一些问题：

1） 我只问了一次。所以，我应该只为一个查询收费。大查询是否按总行数/noOf页数收费？i、 e上述代码中的各个页面是否会单独查询并单独收费

2） 假设上面示例中的页面大小为5，那么会发生的情况是345个条目将分布在各个页面上，在这种情况下，我是否会丢失关于第6个345-POL条目的信息，因为它将位于不同的页面中？这有什么办法吗

3） 如果连续行的值不同，是否有一种直接的方法来绕过整个检查？像直接分组和获取组作为数组机制？如果我加上100万的限制，上述方法需要几个小时（估计）才能运行

---

4） 如何通过指定超过100万的上限来避免资源超出的错误？

您要求BigQuery生成一个巨大的排序结果，而BigQuery目前无法有效地并行化，因此出现了“资源超出”错误

执行此类查询的有效方法是允许在BigQuery内部的SQL中进行计算，而不是从中提取巨大的结果，然后用Python进行后处理。如果Compute（）函数可以用SQL表示，那么分析函数是实现您描述的功能的常用方法

例如，要查找A更改前最后一行中B的值，可以使用last_value函数查找此行，如

log=[]
    while True:
        rows, total_rows, page_token = query_job.results.fetch_data(max_results=100000, page_token=page_token)
        for row in rows:
            try:
                lastAValue=log[-1][0]
            except IndexError:
                lastAValue=None

            if(lastAValue==None or row[0]==lastAValue):
                log.append(row)
            else:
                res=Compute(lastAValue,EntityType,lastAValue)
                allresults.append(res)
                log=[]
                log.append(row)
        if not page_token:
            break

---

如果您可以描述Compute（）的功能，我们可以尝试填写详细信息。

为什么不直接分组，让bigquery进行聚合？我遇到了一个错误：选择列表表达式引用既不分组也不聚合的列（B、C、D）您介意在原始帖子中共享该查询吗？

select LAST_VALUE(B) OVER(PARTITION BY A ORDER BY Yeah) from ...