UDF 内存泄漏的解决方法答案

【问题标题】：Workaround for UDF memory leakUDF 内存泄漏的解决方法
【发布时间】：2016-03-22 00:01:12
【问题描述】：

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。这些东西加起来很快）
有什么想法吗？

【问题讨论】：

我正在挖掘 JS OOM 的根本原因，敬请期待！只是出于好奇，您为什么认为 BigQuery 对 ORDER BY 有 65,000 行的限制？这是一个订购近 1900 万行的查询：SELECT [by] FROM [bigquery-public-data:hacker_news.full_201510] order by 1。
您是否有 BigQuery 作业 ID 可以共享以用于失败的查询？我会将它添加到我的复制列表中。
我们找到了一个（可能是临时的）修复，因此它不再失败。这是一个失败的例子，但请注意，我们已将 UDF 替换为有效的 UDF，并且输入表不再存在（计算成功后不需要）： Academic-diode-113417:bquijob_193cc0f5_1539c3a2c91
关于 ORDER BY：我们有一个失败的大型查询，其中包含多个表的多个子查询，一个子查询具有 ORDER BY，而几个子查询具有 GROUP BY。我们首先在每次加入、分组和排序时使用“EACH”。我现在找不到参考资料，但在我研究它失败的原因时，我在某处读到订购可能会导致工作由单个工人处理，因此在 65k 记录时失败。果然，当我们删除 order by 子句时，查询工作正常。在您建议不应该使用“EACH”之前，我们在一个简单而小的查询上尝试过，但它失败了
嗯，ORDER BY 适用于任意数量的行，只要查询可以低于“大结果”阈值。一旦选中“使用大结果”框，我们就不能应用 ORDER BY。

标签： google-bigquery

【解决方案1】：

此问题与我们对 UDF 代码大小的限制有关。看起来 V8 的 UDF 代码的优化+重新编译过程生成的数据段大于我们的限制，但这仅在 UDF 运行“足够”行数时发生。本周我将与 V8 团队会面，以进一步深入了解细节。

与此同时，我们推出了更新最大数据段大小的修复程序。我已经验证这可以修复由于相同原因而失败的其他几个查询。

您能否重试您的查询？恐怕我在 GCS 中无法轻松获取您的代码资源。

【讨论】：

仅供参考，由于stackoverflow.com/a/36275462/5265394 上正在讨论的问题，您可能会遇到“内部错误”。应该由 EOW 部署该修复程序。
谢谢托马斯。由于我们已经重构了代码并且我们已经解决了这个问题（现在我们被其他东西淹没了），所以还没有重新审视这个问题，但下周会。不过，我相信我们将来会想要运行更多的 UDF，所以继续修复 V8 引擎很重要！
听起来不错，谢谢！郑重声明，这在 V8 本身中不是问题，问题只是在 BigQuery 对 V8 的使用中——特别是我们对其应用的一些配置限制。
更新：我们在更大的输入（大约 100 倍）上运行我们的 js 代码，它仍然有效。显然，无论您更改什么，都可以解决它！现在看来，V8 发动机在所有气缸上运行，速度要快得多。谢谢！
超级！感谢您的跟进，很高兴听到它现在的表现也好多了:)