当我尝试在大型数据集上使用 PERCENT_RANK() 时,它会给我一个错误。
SELECT
a2_lngram,
a2_decade,
a2_totalfreq,
a2_totalbooks,
a2_freq, a2_bfreq,
a2_arf,
c_avgarf,
d_arf,
oi,
PERCENT_RANK() OVER (ORDER BY d_arf DESC) plarf
FROM [trigram.trigrams8]
使用目标表和AllowLargeResults返回:
“查询执行期间超出资源。”
当我将结果限制为几百个时,它运行良好。
作业ID:oticyproject1:job_PpTpmMXYETUMiM_2scGgc997JVg 数据集是公开的。
这是预期的:分析/窗口函数的输入需要适合一个节点才能成功运行。
PERCENT_RANK() OVER (ORDER BY d_arf DESC) plarf
仅当所有行都适合一个节点时才会运行。如果不这样做,您将看到“查询执行期间超出资源”错误。
有一种方法可以扩展分析函数:对数据进行分区。
PERCENT_RANK() OVER (PARTITION BY country ORDER BY d_arf DESC) plarf
...那么该函数可以在多个节点上运行,只要每个“国家/地区”行适合一个虚拟机。
但不是你的情况 - 我在这里要做的修复是计算单独的子查询、连接和除法的总数。
总之,分析函数很酷,但它们在每个分区的大小上存在可扩展性问题 - 幸运的是,还有其他方法可以获得相同的结果。
如果您有 BQ 内存问题:
PERCENT_RANK() OVER (ORDER BY your_col DESC)
将其替换为:
(RANK() OVER (ORDER BY your_col DESC) - 1) / (COUNT(your_col) OVER () - 1)
从功能上来说两者是相等的,请参阅此处的定义:
https://cloud.google.com/bigquery/docs/reference/standard-sql/numbering_functions#percent_rank
但是,如果我使用第二个,我不会遇到内存问题,因此 RANK() OVER (ORDER BY ) 算法必须以某种方式提高内存效率。