在 Regr_slope for snowflake 为什么不支持窗口框架

Question

我有一个查询，我试图将其保存到一个表中，供拥有 2.4 亿行的用户使用，并希望在数据上包含一个滚动的三年测试版。 自连接的原始查询将是：

SELECT
    ibm.trading_item_id,
    ibm.primary_exchange_ticker,
    ibm.date,
    REGR_SLOPE(
        ibm_lagging.USD_PRICE_CLOSE_1D_RT,
        ibm_lagging.SPX_1D_RT
    ) AS spx_beta_3y
FROM
    ibm
    LEFT JOIN ibm ibm_lagging ON ibm.trading_item_id = ibm_lagging.trading_item_id
    AND ibm.date >= ibm_lagging.date
    AND dateadd(year, -3, ibm.date) <= ibm_lagging.date
GROUP BY
    ibm.trading_item_id,
    ibm.primary_exchange_ticker,
    ibm.date
HAVING
    count(*) >= 3 * 250 -- sufficient # of trading days in a year to make this reasonable
ORDER BY

问题是因为这是带有自连接的基本查询中的 2.4 亿行，我正在查看大约 750*2.4 亿行，这些行无法运行。因此，我想使用 Windows 框架，但出于某种原因，在使用分区依据时，regr_slope 函数无法满足这一要求。我想我有一个手动解决方法，但我的问题是为什么这不会得到满足。我担心通过手动操作我的假设有误。

Answer 1

要注意的第一点是，即使它确实支持窗口框架，Snowflake 的窗口框架也只允许行数，这是一个硬编码的滚动窗口，与动态窗口（X 范围内的日期）一样问题。除非您知道每天只有一行，否则您可以使用固定行逻辑。

因此，您允许使用您似乎想要的基于动态时间的方法，您需要使用 UDTF，以便您可以“任意”进位，但始终不会超载 JavaScript 堆栈的内存限制。

如果我们假设您有固定数据，那么固定行解决方案是有效的，来回答为什么？ REGR_SLOPE定义为COVAR_POP(x,y) / VAR_POP(x)，VAR_POP支持windows框架，COVAR_POP不支持。所以这可以解释这一点，但是 COVAR_POP 是由 SUM 和 COUNT 组成的，它们确实支持窗口框架，所以你可以手动滚动它的固定行版本，但正如你所说，这听起来很冒险......正如你所注意到的。