显然BigQuery的UDF存在内存泄漏。我们在一个小表（3000行，5MB）上运行一个简单的UDF，它失败了。如果我们在与表的后半部分连接的表的前半部分（在同一查询中）运行相同的UDF，那么它可以工作！即：
SELECT blah myUDF（SELECT id，data FROM table）
失败。
SELECT blah myUDF（SELECT id，data FROM table ORDER BY id LIMIT 1500），myUDF（SELECT id，data FROM table ORDER BY id DESC LIMIT 1500）
成功。
问题是：我们如何解决这个问题？有没有办法动态拆分多个部分的表，每个部分的大小和预定义的行数相等？一次说1000行？ （示例表有3000行，但我们希望在较大的表中成功，如果我们将6000行表分成两半，则UDF将在每一半上再次失败）。
在任何解决方案中，重要的是（a）不要使用ORDER BY，因为它有65000行限制; （b）使用单个组合查询（否则解决方案可能太慢，加上每个组合表的收费至少为10MB，因此如果我们必须将1,000,000行表分成1,000行，我们将自动收取费用10 GB。时间1,000表= 10TB。这个东西加起来很快）
有什么想法吗？
答案 0 :(得分：1)
此问题与我们对UDF代码大小的限制有关。看起来V8的UDF代码的优化+重新编译通道会生成一个比我们的限制更大的数据段，但这只发生在UDF运行“足够”行数时。本周我将与V8团队会面，进一步深入了解细节。
与此同时，我们推出了一个修复程序来更新最大数据段大小。我已经验证这可以修复其他几个因同样原因失败的查询。
您能否请您重试？我担心我无法轻易获得GCS中的代码资源。