在不改变窗口逻辑的情况下并行化窗口函数或在火花中加速窗口函数
在不改变窗口逻辑的情况下并行化窗口函数或在火花中加速窗口函数
提问于 2021-07-02 15:19:02
我在星火查询中有一组窗口函数，其中包括user_num上的分区。其中一个user_nums比其他的行多得多。这一行是计算在一个单一的任务，其中有一个更高的洗牌读取，洗牌远程读取，最终需要大量的时间。
Select LAG(e) OVER (PARTITION BY user_num, a, date ORDER BY time) as aa,
FIRST_VALUE(e) OVER (PARTITION BY a, date ORDER BY time ROWS
BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING) as bbb
FROM table是否有任何设置或方法可以在不同的任务上运行此操作，或者以其他方式以不需要或最小更改窗口函数逻辑的方式缩短此时间？
例如，我可以在某个点缓存，增加分区数量，增加exec等。
回答 2
Stack Overflow用户
回答已采纳
发布于 2021-07-14 08:46:20
我做的两件事在这里起了作用：
- 将窗口函数更改为模仿该窗口函数的联接。这允许在parallel
- Ultimately中运行计算，我使用的解决方案是将First_Value更改为Last_Value，并按列切换顺序的方向。不知道这有什么用，但速度更快了。可能是First_Value udf.
中的一个bug。
FIRST_VALUE(e)以bbb的形式(按时间进行分区，按时间顺序在无界前行行和当前行之间的行)
Stack Overflow用户
发布于 2021-07-06 12:03:36
建议通过牺牲一些数据损失来扩大规模，即增加分区窗口上的粒度。
示例：
- 从time提取"HOUR“值到一个新列。
- 现在按user_num、a、date、HOUR
进行分区。
现在，您的单个任务将被划分为24个任务。
但是这将为您的滞后带来更多的。例如，如果计算滞后值的偏移量为4，那么对于每小时的数据，将有3个NULL值。
因此，这就像在速度与精确数据之间的权衡。
您可以以更多的NULLS为代价，进一步将粒度提高到分钟，以获得更多的并行性。
进一步改善损失期间：
如果您选择使用较低的粒度，这可能会影响其他"user_nums“。最好将其划分为2个dfs：
将fixed.)
- One_with_Skewed_Data
- One_with_normal_Data
- result_from_Skew
- 分离为2个dfs (按计数使用组，并有一个user_num要考虑的线程保持，或者您可以硬编码，如果您认为是user_num= One_with_Skewed_Data ..with更低粒度的窗口query
- result_from_normal = One_with_normal_Data )。使用常规查询
结果= result_from_Skew.union(result_from_normal)
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/68232108
复制相关文章
相似问题
腾讯云开发者
