這是一個看似昂貴查詢;時間序列分析在類SQL環境中總是很難。您編寫的PARTITION BY
子句要求單個計算機上的單個extid的所有數據都存在於內存中,這會導致其超載並導致資源超出錯誤。
通過使用ROWS
子句來限制分區的範圍,可以減輕此RAM的要求。下面是一個例子:
SELECT extid, stamp, ds, amount, note, balance
FROM (
SELECT
extid, stamp, ds, amount, note, balance,
MAX(tenth_stamp) OVER(PARTITION BY extid) AS target_stamp
FROM (
SELECT extid, stamp, ds, amount, note, balance,
MIN(stamp) OVER (
PARTITION BY extid
ORDER BY stamp DESC
ROWS BETWEEN CURRENT ROW AND 9 FOLLOWING
) AS tenth_stamp
FROM
[monte.ledger2_trailing_21d]
WHERE ds >= '2015-02-09'
)
)
WHERE stamp >= target_stamp
ORDER BY extid, stamp
LIMIT 300
最內子選擇提取數據和場tenth_stamp
保持所述至少戳檢查的10行的。即使在任何給定extid
的行數少於10行的情況下,使用MIN()
也可以實現此功能。
中間的子選擇對於每個extid
找到最大的tenth_stamp
。這是extid
的第十個總郵票。然後,外部SELECT可以將結果限制爲stamp
中最近的stamp
中各自爲extid
的行,從而爲您提供期望的結果。
執行時,共需要4個階段。它不會運行得很快,但從不需要大量的數據在一個位置。希望有所幫助!
感謝您指出行條款。我仍然需要在外部查詢中執行row_number,以便分析用戶與事件交互的順序,但現在它運行時沒有問題。另外,您能否從您的答案中編輯出我的帳戶信息。我寧願沒有在公共論壇中列出完整的文件路徑。 – PData 2015-02-14 00:48:04
FYI Matthew是一名BigQuery工程師,可以訪問查詢日誌,以防萬一您想知道他是如何找到您的項目ID(並且無意中將其添加到響應中的)。 – 2015-02-18 16:14:27