johnyangk commented on a change in pull request #151: [NEMO-267] Consider
watermark holds in GroupByKeyAndWindowDoFnTransform
URL: https://github.com/apache/incubator-nemo/pull/151#discussion_r231353074
##########
File path:
compiler/frontend/beam/src/main/java/org/apache/nemo/compiler/frontend/beam/transform/GroupByKeyAndWindowDoFnTransform.java
##########
@@ -314,4 +345,31 @@ public TimerInternals timerInternalsForKey(final K key) {
return stateAndTimerForKey.timerInternals;
}
}
+
+ /**
+ * This class wraps the output collector to track the watermark hold of each
key.
+ */
+ final class GBKWOutputCollector implements
OutputCollector<WindowedValue<KV<K, Iterable<InputT>>>> {
+ private final OutputCollector<WindowedValue<KV<K, Iterable<InputT>>>>
outputCollector;
+ GBKWOutputCollector(final OutputCollector<WindowedValue<KV<K,
Iterable<InputT>>>> outputCollector) {
+ this.outputCollector = outputCollector;
+ }
+
+ @Override
+ public void emit(final WindowedValue<KV<K, Iterable<InputT>>> output) {
+ // adds the output timestamp to the watermark hold of each key
+ // +1 to the output timestamp because if the window is [0-5000), the
timestamp is 4999
+ keyAndWatermarkHoldMap.put(output.getValue().getKey(),
+ new Watermark(output.getTimestamp().getMillis() + 1));
Review comment:
Is there a reference to this? (e.g., another Beam runner doing also the same)
In the case of following sequence of elements/watermark with (timestamp):
e1(1), e2(2), w1(3), e3(3)
With the +1 we see it as
e1(2=1+1), e2(3=2+1), w1(3), e3(4=3+1)
Would that result in an incorrect reordering of e2 and w1 (in the
time-scale)?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
