[SPARK-21414] Refine SlidingWindowFunctionFrame to avoid OOM.

[jinxing64]

What changes were proposed in this pull request?

In SlidingWindowFunctionFrame, it is now adding all rows to the buffer for which the input row value is equal to or less than the output row upper bound, then drop all rows from the buffer for which the input row value is smaller than the output row lower bound.
This could result in the buffer is very big though the window is small.
For example:

select a, b, sum(a) 
over (partition by b order by a range between 1000000 following and 1000001 following) 
from table

We can refine the logic and just add the qualified rows into buffer.

How was this patch tested?

Manual test:
Run sql
select shop, shopInfo, district, sum(revenue) over(partition by district order by revenue range between 100 following and 200 following) from revenueList limit 10
against a table with 4 columns(shop: String, shopInfo: String, district: String, revenue: Int). The biggest partition is around 2G bytes, containing 200k lines.
Configure the executor with 2G bytes memory.
With the change in this pr, it works find. Without this change, below exception will be thrown.

MemoryError: Java heap space
	at org.apache.spark.sql.catalyst.expressions.UnsafeRow.copy(UnsafeRow.java:504)
	at org.apache.spark.sql.catalyst.expressions.UnsafeRow.copy(UnsafeRow.java:62)
	at org.apache.spark.sql.execution.window.SlidingWindowFunctionFrame.write(WindowFunctionFrame.scala:201)
	at org.apache.spark.sql.execution.window.WindowExec$$anonfun$14$$anon$1.next(WindowExec.scala:365)
	at org.apache.spark.sql.execution.window.WindowExec$$anonfun$14$$anon$1.next(WindowExec.scala:289)
	at org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIterator.processNext(Unknown Source)
	at org.apache.spark.sql.execution.BufferedRowIterator.hasNext(BufferedRowIterator.java:43)
	at org.apache.spark.sql.execution.WholeStageCodegenExec$$anonfun$8$$anon$1.hasNext(WholeStageCodegenExec.scala:395)
	at org.apache.spark.sql.execution.SparkPlan$$anonfun$2.apply(SparkPlan.scala:231)
	at org.apache.spark.sql.execution.SparkPlan$$anonfun$2.apply(SparkPlan.scala:225)
	at org.apache.spark.rdd.RDD$$anonfun$mapPartitionsInternal$1$$anonfun$apply$25.apply(RDD.scala:827)
	at org.apache.spark.rdd.RDD$$anonfun$mapPartitionsInternal$1$$anonfun$apply$25.apply(RDD.scala:827)
	at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
	at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:323)
	at org.apache.spark.rdd.RDD.iterator(RDD.scala:287)
	at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:87)
	at org.apache.spark.scheduler.Task.run(Task.scala:108)
	at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:341)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

[SparkQA]

Test build #79605 has finished for PR 18634 at commit 5103ae8.

• This patch fails due to an unknown error code, -9.
• This patch merges cleanly.
• This patch adds no public classes.

[jinxing64]

retest please

[jinxing64]

Jenkins, retest this please.

[SparkQA]

Test build #79608 has finished for PR 18634 at commit 5103ae8.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[jinxing64]

cc @cloud-fan @jiangxb1987

[jiangxb1987]

I think this improvement is valid, although this only take effect on relative corner case(when CurrentRow is not in the window frame). One concern is the test case don't reflect the improvement of this change.

[jiangxb1987]

How about:

     while (nextRow != null && ubound.compare(nextRow, inputHighIndex, current, index) <= 0) {
       if (lbound.compare(nextRow, inputLowIndex, current, index) < 0) {
         inputLowIndex += 1
       } else {
         buffer.add(nextRow.copy())
         bufferUpdated = true
       }
       nextRow = WindowFunctionFrame.getNextOrNull(inputIterator)
       inputHighIndex += 1
     }

?

[jinxing64]

@jiangxb1987 Thanks a lot for quick reply !

One concern is the test case don't reflect the improvement of this change.

Yes, there is no unit test for WindowFunctionFrame now. The test case I added is just to check the correctness.

[SparkQA]

Test build #79671 has finished for PR 18634 at commit 1ebb211.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[cloud-fan]

wrap your test with withTempView, which can drop the view automatically.

[cloud-fan]

BTW this test is not very related to this PR, just improves test coverage for range window frame.

[jiangxb1987]

And this test case doesn't cover when CurrentRow is not in the window frame. We'd better add that senario.

[jinxing64]

Sure, I will add it later today.

[cloud-fan]

@jinxing64 I think this patch is straightforward, can you do a manual test, which OOM before and works after this PR? We can put the test in PR description so that other people can try it out.

[jinxing64]

@cloud-fan @jiangxb1987
Thanks for help! I will refine and post the result of manual test late today :)

[jinxing64]

@cloud-fan
This is null and do you think 0 is better?

[cloud-fan]

null is better, which matches the behavior in Aggregate.

[cloud-fan]

LGTM

[cloud-fan]

BTW, please make sure there is no behavior change, i.e. the result should be same with or without this PR.

[jinxing64]

expected is calculated manually. This test is to verify there is no behavior change.

[SparkQA]

Test build #79753 has finished for PR 18634 at commit b33c4cf.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[cloud-fan]

thanks, merging to master/2.2!