我们发现当我们在大型输入上使用UDF运行查询时，它们往往会因“内部错误”而失败。使情况不那么频繁的一种想法是在运行查询之前拆分表。但是，结果仍然是间歇性的 - 有时查询会成功，有时会失败（对完全相同的输入完全相同的查询）。
所以问题是，运行此查询通常更可靠和/或更快：
SELECT field1, field2
FROM (SELECT field1, field2 FROM some_udf(
SELECT field1, field2 FROM table_with_300_MM_rows
WHERE hash(some_unique_key) % {n} = {table_id_1})
),
....
(
SELECT field1, field2 FROM some_udf(
SELECT field1, field2 FROM table_with_300_MM_rows
WHERE hash(some_unique_key) % {n} = {table_id_n})
),
而不是这个？
SELECT field1, field2 FROM some_udf(
SELECT field1, field2 FROM table_with_300_MM_rows)
如果是这样，n的价值是多少？ （为了获得最佳性能，我们需要拆分多少个子表）？我们的理解是，不应该发生，因为它可能与UDF错误有关，并且如果UDF成功（单独）所有被分割的输入，则没有理由它不应该成功整个输入。
假设查询是这样的，以上两种方法都会产生相同的输出。
答案 0 :(得分：1)
你当然不应该得到内部错误。任何时候发生，这是我们的错 - 至少，我们应该通过正确的错误信息。
此外，随着表的大小增加，期望任何适用于少量数据的查询能够继续工作，这是公平的。我们负责扩展和分区，因此您不必担心它。
我们最近看到了一些类似的UDF扩展问题，很快就会对它们进行调查。希望我们能够解决这个问题，你不必再担心这个问题。
也就是说，如果拆分表有助于让查询暂时通过，那就去吧。缺点是，对于表的两次扫描，您将收取两次费用，因此如果这是一项常见操作，您可能希望将表拆分为两个永久表，然后在这些较小的表上运行单独的查询（或子查询）