[FLINK-5653] Add processing time OVER ROWS BETWEEN x PRECEDING aggregation to SQL #3547

huawei-flink · 2017-03-15T13:09:21Z

Thanks for contributing to Apache Flink. Before you open your pull request, please take the following check list into consideration.
If your changes take all of the items into account, feel free to open your pull request. For more information and/or questions please refer to the How To Contribute guide.
In addition to going through the list, please provide a meaningful description of your changes.

[ x] General
- The pull request references the related JIRA issue ("[FLINK-XXX] Jira title text")
- The pull request addresses only one issue
- Each commit in the PR has a meaningful commit message (including the JIRA id)
[ x ] Documentation
- Documentation has been added for new functionality
- Old documentation affected by the pull request has been updated
- JavaDoc for public methods has been added
[ x] Tests & Build
- Functionality added by the pull request is covered by tests
- mvn clean verify has been executed successfully locally or a Travis build has passed

FLINK-5653b # Conflicts: # flink-libraries/flink-table/src/main/scala/org/apache/flink/table/plan/nodes/datastream/DataStreamOverAggregate.scala # flink-libraries/flink-table/src/main/scala/org/apache/flink/table/runtime/aggregate/AggregateUtil.scala

fhueske · 2017-03-15T13:50:03Z

Thanks for the new PR @huawei-flink. I'll have a look soon.

sunjincheng121

HI,@huawei-flink Thanks for the PR. I am very interested in this PR,And I only made a fast pass over the changes. Then I leave some comments. And there are some suggestions:

I recommend using processFunctions implementation this JIRA.
In the processFunction using state management data and incremental calculation result;
Using AggregateFunction # retract method to process the incremental calculation result and calculate the current window result.

The above suggestions are for reference only, What do you think? @huawei-flink @fhueske
Thanks,
SunJIncheng

sunjincheng121 · 2017-03-15T15:17:28Z

...nk-table/src/main/scala/org/apache/flink/table/plan/logical/rel/LogicalWindowAggregate.scala

@@ -37,8 +35,8 @@ class LogicalWindowAggregate(
    child: RelNode,
    indicator: Boolean,
    groupSet: ImmutableBitSet,
-    groupSets: util.List[ImmutableBitSet],
-    aggCalls: util.List[AggregateCall])
+    groupSets: java.util.List[ImmutableBitSet],


Can we keep the original way? util.List[ImmutableBitSet]

for some reason it does not build in eclipse in the original way, and honestly I struggle to understand "the half package name" usage in Scala. Is there any practical reason for that? and does it break some convention to use the complete package name? I am asking with honest curiosity, and no polemical intention. Thanks for clarifying.

sunjincheng121 · 2017-03-15T15:18:20Z

...nk-table/src/main/scala/org/apache/flink/table/plan/logical/rel/LogicalWindowAggregate.scala

@@ -18,8 +18,6 @@

 package org.apache.flink.table.plan.logical.rel

-import java.util


I think import package name is good way. How do you think?

In principle I agree, but I it caused some building problem. Is there a practical reason for not importing the List class directly rather than creating "half references"?

Your current package is org.apache.flink.table.plan.logical.rel, in this package there is a org.apache.flink.table.plan.logical.rel.util, this and util .List package conflicts. So you can try the following 2 way solution:
solution1:

import java.util.List groupSets: List[ImmutableBitSet], aggCalls: List[AggregateCall])

solution2:

import java.{util => JUtil} groupSets: JUtil.List[ImmutableBitSet], aggCalls: JUtil.List[AggregateCall])

Thanks, both solutions look better than the half package import. I will apply one of those.

sunjincheng121 · 2017-03-15T15:19:39Z

...le/src/main/scala/org/apache/flink/table/plan/nodes/datastream/DataStreamOverAggregate.scala

-  extends SingleRel(cluster, traitSet, inputNode)
-  with OverAggregate
-  with DataStreamRel {
+  logicWindow: Window,


Indent 4 space.

sunjincheng121 · 2017-03-15T15:19:57Z

...le/src/main/scala/org/apache/flink/table/plan/nodes/datastream/DataStreamOverAggregate.scala

+  inputNode: RelNode,
+  rowRelDataType: RelDataType,
+  inputType: RelDataType)
+    extends SingleRel(cluster, traitSet, inputNode)


Indent 2 space.

sunjincheng121 · 2017-03-15T15:24:20Z

...le/src/main/scala/org/apache/flink/table/plan/nodes/datastream/DataStreamOverAggregate.scala

+          .asInstanceOf[DataStream[Row]]
+      } // global non-partitioned aggregation
+      else {
+        throw TableException(


Can you supported not-partitioned case in this JIRA.

If needed, I can do it.

sunjincheng121 · 2017-03-15T15:25:37Z

...ries/flink-table/src/main/scala/org/apache/flink/table/runtime/aggregate/AggregateUtil.scala

+import org.apache.calcite.sql.`type`.SqlTypeName.FLOAT
+import org.apache.calcite.sql.`type`.SqlTypeName.INTEGER
+import org.apache.calcite.sql.`type`.SqlTypeName.SMALLINT
+import org.apache.calcite.sql.`type`.SqlTypeName.TINYINT


Can you remove those unused import ?

after an inspection, I realized that the imports you mentioned are used. I think there is no unused import at this moment. Am I missing something?

Yes, I had clone your code.May be in this case,we can use ._ ,
e.g.: import org.apache.flink.table.functions.aggfunctions._ In this way, we can reduce 53 line to 1 line. What do you think?

I see your point, although I thought that wildcard import was not a best practice. It seems that the java and scala implementation are following different conventions. I have no problems with it in principle.

sunjincheng121 · 2017-03-15T15:31:11Z

...ain/scala/org/apache/flink/table/runtime/aggregate/BoundedProcessingOverWindowFunction.scala

+import org.apache.flink.table.functions.Accumulator
+import java.lang.Iterable
+
+class BoundedProcessingOverWindowFunction[W <: Window](


I suggest use ProcessFunction to implement this feature. So that you can manage data flexibly and can use incremental calculations.

@sunjincheng121 thanks for the suggestion. I decided to use Window because it is convenient in the row bounded case. Within the window I apply the incremental aggregation in the same way.

It is not clear to me what are the flexibility advantages in this specific case. Can you be more explicit?

I glad to explain this. IMO. There are several advantages to using ProcessFunction:

OverWindow implementation code consistent, such as: FLINK-5803, FLINK-5804, FLINK-5658 (See @fhueske propose the design in [FLINK-5658][table] support unbounded eventtime over window #3386 )

Because using ProcessFunction can manage their own state, the management window of the data collection, you can customize the trigger window, so in the future when the FOLLOWING supported we can be very convenient support.

For incremental aggregation, window mechanism must increase the implementation of reduceFunction, ProcessFunction in the management of the state at the same time will be very natural support.
What do you think?

Thanks a lot for the clarification. I am really willing to do it right, but at the same time I need to understand. So, please be patient. :-)

When we started discussing the issue with @fhueske (https://issues.apache.org/jira/browse/FLINK-5654?filter=-1) there was a decision to use window, not process function.
Code consistency is pretty much the same, just extening a different interface. I understand that ProcessFunction can manage its state, but window checkpointing should replay all events in case of failure, so we would have consistent processing even without managing this level of granularity in the state. With procTime semantic, we can neglect retraction, and window can anyway customize triggering function.

I don't understand the third point.

The main argument I see for this specific case is that ProcessFunction supports granular state management. Besides the alleged code consistency.

Hi,@huawei-flink about the discussing I think we need @fhueske 's opinion.
Best,
SunJincheng

I just thought about a case where one wants to do a COUNT DISTINCT type of aggregation. How does a processFunction work for that?

As @huawei-flink pointed out, I agreed to use a count window for the bounded OVER ROW case in our previous discussions. Although it would not be consistent with the other OVER windows, I thought this would be an easier solution.

However, the way it is implemented right now with a WindowFunction does not perform eager aggregation but collects all records and applies the WindowFunction at the end. If we want to use count windows, we should implement an org.apache.flink.api.common.functions.AggregateFunction (not to be confused with the Table API interface for aggregation functions) for preaggregation and a WindowFunction for the final assembly of the result row. You can have a look at the AggregateAggFunction and the DataStreamAggregate classes for how an AggreagteFunction is defined and used.

Regarding the aggregation of COUNT DISTINCT, we could implement a custom aggregation function, similar to the retractable min or max aggregation function.

Hi @huawei-flink @fhueske in bounded OVER ROW case, I still recommend using processFunction. But we can just agree to disagree at current time. Because in the continuous progress of flip11, we may change our view.
Best,
SunJIncheng

sunjincheng121 · 2017-03-15T15:42:35Z

Hi @fhueske I'am sorry, I have not seen your comments until I passed over this PR. If I have any mistakes, please correct it.
Best,
SunJIncheng

fhueske · 2017-03-15T16:05:26Z

No worries @sunjincheng121!
Everybody is welcome and encouraged to review pull requests.
Thanks for doing this!

problems.

sunjincheng121 · 2017-03-16T05:11:54Z

...t/java/org/apache/flink/table/api/java/stream/sql/ProcTimeRowStreamAggregationSqlITCase.java

+import org.junit.Ignore;
+import org.junit.Test;
+
+public class ProcTimeRowStreamAggregationSqlITCase extends StreamingMultipleProgramsTestBase {


Please implement the test in Scala.

Why should also the test be implemented in scala?

sunjincheng121 · 2017-03-16T05:43:09Z

...t/java/org/apache/flink/table/api/java/stream/sql/ProcTimeRowStreamAggregationSqlITCase.java

+		expected.add("5,21");
+		expected.add("5,23");
+		expected.add("5,26");
+		expected.add("5,27");


This result does not conform to the semantics of over. that is, in this sql,we must be got the result as follow:

1,0 2,1 2,3 3,3 3,7 3,12 4,6 4,13 4,21 4,24 5,10 5,21 5,33 5,37 5,39

The reason for the error I left the comments in DataStreamOverAggregate.scala

Besides the fix you suggested, which is trivial (and thanks! :-)), it sounds a little odd to define a range with excluding boundaries. could you please point out the document in which this is discussed?

It makes sense anyway, I fixed according to your suggestion.

sunjincheng121 · 2017-03-16T05:47:51Z

...le/src/main/scala/org/apache/flink/table/plan/nodes/datastream/DataStreamOverAggregate.scala

+          inputType)
+
+        inputDS
+          .countWindowAll(lowerbound,1)


lowerbound -> (lowerbound+1)

So, the semantic of between 2 rows and current row does not include the current row and I should count 3 elements?

From the MS SQL Server documentation:

For example, ROWS BETWEEN 2 PRECEDING AND CURRENT ROW means that the window of rows that the function operates on is three rows in size, starting with 2 rows preceding until and including the current row.

So, since lowerBound is already AggregateUtil.getLowerBoundary(...) + 1, we should be good.

sunjincheng121 · 2017-03-16T05:48:11Z

...le/src/main/scala/org/apache/flink/table/plan/nodes/datastream/DataStreamOverAggregate.scala

+          inputType)
+        inputDS
+          .keyBy(partitionKeys: _*)
+          .countWindow(lowerbound,1)


lowerbound -> (lowerbound+1)

sunjincheng121 · 2017-03-16T06:04:18Z

...ain/scala/org/apache/flink/table/runtime/aggregate/BoundedProcessingOverWindowFunction.scala

+import org.apache.flink.table.functions.Accumulator
+import java.lang.Iterable
+
+class BoundedProcessingOverWindowFunction[W <: Window](


I glad to explain this. IMO. There are several advantages to using ProcessFunction:

OverWindow implementation code consistent, such as: FLINK-5803, FLINK-5804, FLINK-5658 (See @fhueske propose the design in [FLINK-5658][table] support unbounded eventtime over window #3386 )

Because using ProcessFunction can manage their own state, the management window of the data collection, you can customize the trigger window, so in the future when the FOLLOWING supported we can be very convenient support.

For incremental aggregation, window mechanism must increase the implementation of reduceFunction, ProcessFunction in the management of the state at the same time will be very natural support.
What do you think?

sunjincheng121 · 2017-03-16T06:06:34Z

...t/java/org/apache/flink/table/api/java/stream/sql/ProcTimeRowStreamAggregationSqlITCase.java

+		expected.add("5,21,10");
+		expected.add("5,23,11");
+		expected.add("5,26,12");
+		expected.add("5,27,13");


This result incorrect.The reason for the error I left the comments in DataStreamOverAggregate.scala

sunjincheng121 · 2017-03-16T06:07:36Z

...t/java/org/apache/flink/table/api/java/stream/sql/ProcTimeRowStreamAggregationSqlITCase.java

+		expected.add("5,10,3");
+		expected.add("5,11,3");
+		expected.add("5,13,2");
+		expected.add("5,13,2");


This result incorrect.The reason for the error I left the comments in DataStreamOverAggregate.scala

sunjincheng121 · 2017-03-16T06:08:12Z

...t/java/org/apache/flink/table/api/java/stream/sql/ProcTimeRowStreamAggregationSqlITCase.java

+		expected.add("5,10,GHI");
+		expected.add("5,10,HIJ");
+		expected.add("5,11,IJK");
+		expected.add("5,13,JKL");


This result incorrect.The reason for the error I left the comments in DataStreamOverAggregate.scala

sunjincheng121 · 2017-03-16T06:08:29Z

...t/java/org/apache/flink/table/api/java/stream/sql/ProcTimeRowStreamAggregationSqlITCase.java

+		expected.add("21");
+		expected.add("23");
+		expected.add("26");
+		expected.add("27");


This result incorrect.The reason for the error I left the comments in DataStreamOverAggregate.scala

sunjincheng121 · 2017-03-16T06:08:59Z

...t/java/org/apache/flink/table/api/java/stream/sql/ProcTimeRowStreamAggregationSqlITCase.java

+		expected.add("5,10");
+		expected.add("5,10");
+		expected.add("5,11");
+		expected.add("5,12");


This result incorrect.The reason for the error I left the comments in DataStreamOverAggregate.scala

style

fhueske

Thanks for the PR @huawei-flink!
I made a few comments.

Thanks, Fabian

fhueske · 2017-03-16T19:45:06Z

...le/src/main/scala/org/apache/flink/table/plan/nodes/datastream/DataStreamOverAggregate.scala

@@ -17,34 +17,41 @@
 */
 package org.apache.flink.table.plan.nodes.datastream

-import org.apache.calcite.plan.{RelOptCluster, RelTraitSet}
+import org.apache.calcite.plan.{ RelOptCluster, RelTraitSet }


This PR has several changes that reformat the code but do not change the logic.
In general, we try to limit PRs to the scope of the issue and avoid reformatting.

It makes the PR harder to review because every reformatting change needs to be checked (was something changed or not). This is especially tiresome when indention is changed.

It makes it more difficult to track changes in the history.

Other users do not necessarily agree with your (or your IDE's) formatting and will format it back. So it might get back and forth.

There is nothing wrong with adding a space between arguments here and there, but please keep reformatting changes to a minimum.

@fhueske sorry about that. Will be more careful in the next one.

No worries. I know that IDEs tend to reformat code but it really makes reviews harder.
Thanks!

fhueske · 2017-03-16T19:57:15Z

...ries/flink-table/src/main/scala/org/apache/flink/table/runtime/aggregate/AggregateUtil.scala

@@ -17,35 +17,62 @@
 */
 package org.apache.flink.table.runtime.aggregate

-import java.util
+import scala.collection.JavaConversions.asScalaBuffer


Can we keep the imports as they are?

I need that import, without it does not build.

fhueske · 2017-03-16T19:59:33Z

...ries/flink-table/src/main/scala/org/apache/flink/table/runtime/aggregate/AggregateUtil.scala

@@ -89,6 +116,58 @@ object AggregateUtil {
        aggregationStateType)
    }
  }
+
+  private[flink] def CreateBoundedProcessingOverWindowFunction(
+      namedAggregates: Seq[CalcitePair[AggregateCall, String]],


Please align the arguments as the other functions do.

fhueske · 2017-03-16T20:00:21Z

...ries/flink-table/src/main/scala/org/apache/flink/table/runtime/aggregate/AggregateUtil.scala

+
+  }
+
+    private[flink] def CreateBoundedProcessingOverGlobalWindowFunction(


fhueske · 2017-03-16T20:02:17Z

...le/src/main/scala/org/apache/flink/table/plan/nodes/datastream/DataStreamOverAggregate.scala

+          inputType)
+        inputDS
+          .keyBy(partitionKeys: _*)
+          .countWindow(lowerbound,1) 


.countWindow(lowerbound, 1) +space

fhueske · 2017-03-16T20:38:37Z

...ries/flink-table/src/main/scala/org/apache/flink/table/runtime/aggregate/AggregateUtil.scala

+  def getLowerBoundary(
+      constants: ImmutableList[RexLiteral],
+      lowerBound: RexWindowBound,
+      input: RelNode):Int = {


input: ReoNode): Int = { +space

fhueske · 2017-03-16T20:44:26Z

...ries/flink-table/src/main/scala/org/apache/flink/table/runtime/aggregate/AggregateUtil.scala

+        inputType,
+        needRetraction = false)
+
+    val aggregationStateType: RowTypeInfo =


fhueske · 2017-03-16T20:51:51Z

.../scala/org/apache/flink/table/runtime/aggregate/BoundedProcessingOverAllWindowFunction.scala

+    var i = 0
+    // setting the accumulators for each aggregation
+    while (i < aggregates.length) {
+      accumulators.setField(i, aggregates(i).createAccumulator())


accumulators can be reset with aggregate.resetAccumulator(acc). So we can initialize once and reuse them

fhueske · 2017-03-16T21:12:43Z

...st/scala/org/apache/flink/table/api/scala/stream/sql/ProcTimeRowBoundedAggregationTest.scala

+import scala.collection.mutable
+import org.apache.flink.types.Row
+
+class ProcTimeRowBoundedAggregationTest extends StreamingWithStateTestBase {


This class is an integration tests because it starts a Flink minicluster. Hence its name should end with ITCase and not Test which would indicate a lightweight unit test.

Each ITCase class adds significantly to the build time of the project because it starts a mini cluster which takes some time. Therefore, we try to keep the number of ITCase classes low and aim to test as much as possible with faster unit tests.

Please add unit test methods that test the translation of queries to org.apache.flink.table.api.scala.stream.sql.WindowAggregateTest.

Please add the following integration tests to org.apache.flink.table.api.scala.stream.sql.SqlITCase

multiple aggregation functions with partitioning

multiple aggregation functions without partitioning

These tests classes contain already a few test methods that you can use as a starting point.

Thank you

@fhueske Should I add all the test unit under the SqlITCase class?

fhueske · 2017-03-16T21:38:21Z

...le/src/main/scala/org/apache/flink/table/plan/nodes/datastream/DataStreamOverAggregate.scala

@@ -106,9 +113,14 @@ class DataStreamOverAggregate(
        if (overWindow.lowerBound.isUnbounded &&
          overWindow.upperBound.isCurrentRow) {
          createUnboundedAndCurrentRowProcessingTimeOverWindow(inputDS)
+        } // lowerbound is a BasicType and upperbound is PRECEEDING or CURRENT ROW
+        else if (overWindow.lowerBound.getOffset.getType.isInstanceOf[BasicSqlType]


What is the check overWindow.lowerBound.getOffset.getType.isInstanceOf[BasicSqlType] for and why do you check if overWindow.upperBound.isPreceding?

Should the condition rather be like this:

else if (overWindow.lowerBound.isPreceding() && !overWindow.lowerBound.isUnbounded() && // bounded preceding overWindow.upperBound.isCurrentRow() && // until current row overWindow.isRows) // is rows window

I guess that is also a way to do it. The check allows to distinguish between time bounded and row bounded. I have no particular affection for my solution, it just worked. I will apply and test yours as well.

Yes, I realized that when looking at PR #3550 that isInstanceOf[BasicSqlType] and .isInstanceOf[IntervalSqlType] distinguishes ROW from RANGE windows. I think using .isRows() is more clear and might also be safer because it appears to be a more public API than the type of the offset.

fhueske · 2017-03-16T22:01:07Z

One more thing. The PR includes a merge commit which makes squashing the commits and merging the PR a lot more difficult (see also the contribution guidelines).

You can avoid merge commits if you branch from the master and just put commits on top. If you want to include somebody else's work, you can use git cherry-pick to pull over a commit. Use git rebase to rebase your commits on the latest master.

Best, Fabian

Modifying Dockerfile to build from local flink-dist as well as release URLs. Logging to stdout. Adding scripts to deploy seamlessly on Docker Swarm. Updating Docker Compose scripts to work correctly. Parameterizing things so these Docker scripts are more generally useful.

docker-entrypoint.sh should error on invalid args Improve docker build.sh cleanup Dockerfile improvements per review Remove unnecessary Dockerfile build steps Now that docker-entrypoint.sh uses 'start-foreground', munging flink-daemon.sh and overwriting the log4j config are not longer necessary. Improve Dockerfile and docker-entrypoint.sh Clean up Dockerfile and improve docker-entrypoint.sh to support '--help' and pass through non-(jobmanager|taskmanager) commands. This closes apache#3205. This closes apache#3494.

…RocksDB keyed state with no key set

… with InputStream#readFully(...)

This closes apache#3538.

…end.getPartitionedState()

The hostname used for the BlobServer was set to the akka address which is invalid for this use. Instead, this adds the hostname to the RpcGateway / AkkaInvocationHandler so that this information is available to the TaskExecutor. This closes apache#3551.

The CEP operator now cleans the registered state for a key. This happens: 1) for the priority queue, when the queue is empty. 2) for the NFA, when its shared buffer is empty. 3) finally the key is removed from the watermark callback service if both the above are empty.

…rmance problems

…ializers This closes apache#3373

…back for Serializers

…eue to prevent memory leaks This closes apache#3548

…anoTime() in 'flink-clients' This closes apache#3384

…onfigurable This closes apache#3374

…mber of retained checkpoints.

…hen generating job graph This closes apache#3455

This is likely only used by Gelly and we have a more featureful implementation allowing for multiple outputs and setting the job name. Deprecation will allow this to be removed in Flink 2.0. This closes apache#3516

…he.flink.streaming.util' This close apache#3532

…or incoming connection

- added missing serialVersionUID - PythonPlan* classes no longer implement serializable - marked several fields as transient - replaced some fields by local variables - input/output files are now being deleted - remvoed some unnecessary casts - renamved several ignored exceptions - close socket in PythonPlanStreamer - simplified PyProcess health check - eliminated several uses of raw types - removed some unthrown exception declarations

…r pushing it (1) fix filterable test rebase and trying fix rexnode parsing create wrapper and update rules

…r pushing it (2) This closes apache#3520. fix compilation failure fix compilation failure again. 1. Deep copy TableSource when we copy TableSourceScan 2. unify push project into scan rule for both batch and stream address comments. expand project list before creating new RexProgram update tests

problems.

style

aggregation and relative window function.

huawei-flink · 2017-03-20T14:42:35Z

sorry about the mess. I don't understand the mess the rebase does with eclipse... I will close this PR and open another one including all the changes and comments

stefanobortoli added 3 commits March 15, 2017 13:25

First implementation of aggregation over procTime row bounded window

0e33399

First implementation of aggregation over procTime row bounded window

77a7eff

sunjincheng121 reviewed Mar 15, 2017

View reviewed changes

Implemented not partitioned aggregation, and fixed indent and import

13e7dc3

problems.

sunjincheng121 reviewed Mar 16, 2017

View reviewed changes

implemented test in scala, fixed window boundary and improved import

a594387

style

fhueske reviewed Mar 16, 2017

View reviewed changes

fhueske mentioned this pull request Mar 17, 2017

[FLINK-5654] - Add processing time OVER RANGE BETWEEN x PRECEDING aggregation to SQL #3550

Closed

stefanobortoli and others added 13 commits March 20, 2017 15:25

First implementation of aggregation over procTime row bounded window

6d719ac

[FLINK-6001] Fix ContinuousEventTimeTrigger firing without state

514ea67

[FLINK-6061] [state backends] Throw IllegalStateException when using …

f198a22

…RocksDB keyed state with no key set

[FLINK-6044] Replace all unintentional calls to InputStream#read(...)…

9f9af02

… with InputStream#readFully(...)

[hotfix] [doc] Fix error in ProcessFunction example.

0d21abf

[FLINK-6051] [metrics] [docs] Fix scope keys on Configuration page

08744de

This closes apache#3538.

[FLINK-6018] Properly initialise StateDescriptor in AbstractStateBack…

51f0ddf

…end.getPartitionedState()

[hotfix] Remove auto-boxing in ContinuousEventTimeTrigger

926f35b

[FLINK-5756] [rocksdb] Add mini benchmarks to reproduce 'merge' perfo…

62d4769

…rmance problems

jinmingjian and others added 18 commits March 20, 2017 15:25

[FLINK-5692] [core] Add an Option to Deactivate Kryo Fallback for Ser…

66f3214

…ializers This closes apache#3373

[FLINK-5692] [core] (followups) Add an Option to Deactivate Kryo Fall…

a881b5e

…back for Serializers

[hotfix] [core] Fix/cleanup serialization test for ExecutionConfig

71d6df5

[FLINK-5962] [checkpoints] Remove scheduled cancel-task from timer qu…

323d1a2

…eue to prevent memory leaks This closes apache#3548

[FLINK-4422] [clients] Convert time interval measurements to System.n…

84bf146

…anoTime() in 'flink-clients' This closes apache#3384

[FLINK-4754] [checkpoints] Make number of retained checkpoints user c…

e5597dc

…onfigurable This closes apache#3374

[FLINK-4754] [checkpoints] Small followups to the configuration of nu…

b00c4f5

…mber of retained checkpoints.

[FLINK-5134] [runtime] Aggregate ResourceSpec for chained operators w…

c9b1f59

…hen generating job graph This closes apache#3455

[FLINK-6009] [java api] Deprecate DataSetUtils#checksumHashCode

136ae5a

This is likely only used by Gelly and we have a more featureful implementation allowing for multiple outputs and setting the job name. Deprecation will allow this to be removed in Flink 2.0. This closes apache#3516

[FLINK-6041] [streaming api] Move StreamingFunctionUtils to 'org.apac…

5d49e41

…he.flink.streaming.util' This close apache#3532

[FLINK-5650] [py] Continuously check PyProcess health while waiting f…

794792e

…or incoming connection

[FLINK-5715] Asynchronous snapshots for heap-based keyed state backend

17221ad

[FLINK-3849] [table] Add FilterableTableSource interface and rules fo…

7b8129f

…r pushing it (1) fix filterable test rebase and trying fix rexnode parsing create wrapper and update rules

Implemented not partitioned aggregation, and fixed indent and import

7c65c75

problems.

implemented test in scala, fixed window boundary and improved import

4d89272

style

Moving test to existing IT and window test. Implemented eager

32877c7

aggregation and relative window function.

huawei-flink closed this Mar 20, 2017

huawei-flink deleted the FLINK-5653b branch March 20, 2017 15:34

rmetzger added the component=API/TableSQL label Mar 14, 2019

flinkbot added component=TableSQL/API and removed component=API/TableSQL labels Mar 17, 2022

		@@ -18,8 +18,6 @@

		package org.apache.flink.table.plan.logical.rel

		import java.util


		}

		private[flink] def CreateBoundedProcessingOverGlobalWindowFunction(

[FLINK-5653] Add processing time OVER ROWS BETWEEN x PRECEDING aggregation to SQL #3547

[FLINK-5653] Add processing time OVER ROWS BETWEEN x PRECEDING aggregation to SQL #3547

Conversation

huawei-flink commented Mar 15, 2017

fhueske commented Mar 15, 2017

sunjincheng121 left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fhueske Mar 16, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sunjincheng121 commented Mar 15, 2017

fhueske commented Mar 15, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sunjincheng121 Mar 16, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fhueske left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fhueske Mar 16, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fhueske commented Mar 16, 2017

huawei-flink commented Mar 20, 2017

sunjincheng121 left a comment •

edited

fhueske Mar 16, 2017 •

edited

sunjincheng121 Mar 16, 2017 •

edited

fhueske Mar 16, 2017 •

edited