这是关于Spark中的窗口函数的问题。
假设我有这个DF
DATE_S | ID | STR | VALUE
-------------------------
1 | 1 | A | 0.5
1 | 1 | A | 1.23
1 | 1 | A | -0.4
2 | 1 | A | 2.0
3 | 1 | A | -1.2
3 | 1 | A | 0.523
1 | 2 | A | 1.0
2 | 2 | A | 2.5
3 | 2 | A | 1.32
3 | 2 | A | -3.34
1 | 1 | B | 1.5
1 | 1 | B | 0.23
1 | 1 | B | -0.3
2 | 1 | B | -2.0
3 | 1 | B | 1.32
3 | 1 | B | 523.0
1 | 2 | B | 1.3
2 | 2 | B | -0.5
3 | 2 | B | 4.3243
3 | 2 | B | 3.332
这只是一个例子！假设存在许多更多DATE_S为每个（ID，STR） ，有更多的ID和个STR，和全（DATE_S，ID，STR）有更多的条目。显然，每个组合有多个值（DATE_S，ID，STR）
现在，我这样做：
val w = Window.partitionBy("ID", "STR").orderBy("DATE_S").rangeBetween(-N, -1)
df.withColumn("RESULT", function("VALUE").over(w))
其中Ñ可能导致包含大范围的行的，从100到100000和更多，这取决于（“ID”，“STR”）
结果将是这样的
DATE_S | ID | STR | VALUE | RESULT
----------------------------------
1 | 1 | A | 0.5 | R1
1 | 1 | A | 1.23 | R1
1 | 1 | A | -0.4 | R1
2 | 1 | A | 2.0 | R2
3 | 1 | A | -1.2 | R3
3 | 1 | A | 0.523 | R3
1 | 2 | A | 1.0 | R4
2 | 2 | A | 2.5 | R5
3 | 2 | A | 1.32 | R6
3 | 2 | A | -3.34 | R7
1 | 1 | B | 1.5 | R8
1 | 1 | B | 0.23 | R8
1 | 1 | B | -0.3 | R9
2 | 1 | B | -2.0 | R10
3 | 1 | B | 1.32 | R11
3 | 1 | B | 523.0 | R11
1 | 2 | B | 1.3 | R12
2 | 2 | B | -0.5 | R13
3 | 2 | B | 4.3243| R14
3 | 2 | B | 3.332 | R14
存在相同的“结果”，因为对于具有相同（DATE_S，ID，ST）的每一行，用于“函数”计算的值都是相同的。
我的问题是这样的：
spark是为每个ROW调用“函数”（多次重新计算相同的值）还是针对每个值范围（帧？）计算一次，然后将其粘贴到该范围内的所有行上？
谢谢阅读 ：）
根据您的数据，如果运行两次（根据我的观察），结果可能会有所不同，因为没有明显的排序可能性。但是，我们把它放在一边。
尽管存在代码生成优化，但找不到它以您声明的方式检查下一次调用是否与下一行要处理的数据集相同。我从未读过这种优化。由于懒惰的评估方法而导致融合，但这是另一回事。因此，每行都会重新计算一次。
来源广泛：https：//jaceklaskowski.gitbooks.io/mastering-spark-sql/spark-sql-functions-windows.html
...窗口函数的核心是基于一组称为框架的行为表的每个输入行计算一个返回值。每个输入行都可以具有唯一的框架。...
...换句话说，当执行时，窗口函数为窗口中的每一行（每个窗口指定）计算一个值。...
最大的问题是要有适当数量的分区用于并行处理，这很昂贵，但这是大数据。partitionBy("ID", "STR")是这里的线索，那是一件好事。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句