When in processing time?
| Google Cloud Dataflow | Prism Local Runner | Apache Flink | Apache Spark (RDD/DStream based) | Apache Spark Structured Streaming (Dataset based) | Apache Nemo | Hazelcast Jet | Kafka Streams (experimental, not released) | Twister2 | Python Direct FnRunner | |
|---|---|---|---|---|---|---|---|---|---|---|
| Configurable triggering | Yes : fully supported Fully supported in streaming mode. In batch mode, intermediate trigger firings are effectively meaningless. | Yes : fully supported | Yes : fully supported | Yes : fully supported | Partially : fully supported in batch mode | Yes : fully supported | Yes : fully supported | Yes : fully supported | Yes : fully supported | No : default trigger only |
| Event-time triggers | Yes : yes in streaming, fixed granularity in batch Fully supported in streaming mode. In batch mode, currently watermark progress jumps from the beginning of time to the end of time once the input has been fully consumed, thus no additional triggering granularity is available. | Yes : fully supported | Yes : fully supported | Yes : fully supported | Partially : fully supported in batch mode | Yes : fully supported | Yes : fully supported | Yes : fully supported | Yes : fully supported | Partially : the default trigger only Panes fire when the watermark passes the end of the window; other event-time triggers are untested. |
| Processing-time triggers | Yes : yes in streaming, fixed granularity in batch Fully supported in streaming mode. In batch mode, from the perspective of triggers, processing time currently jumps from the beginning of time to the end of time once the input has been fully consumed, thus no additional triggering granularity is available. | Yes : fully supported | Yes : fully supported | Yes : This is Spark streaming's native model Spark processes streams in micro-batches. The micro-batch size is actually a pre-set, fixed, time interval. Currently, the runner takes the first window size in the pipeline and sets it's size as the batch interval. Any following window operations will be considered processing time windows and will affect triggering. | Partially : fully supported in batch mode | Yes : fully supported | Yes : fully supported | Yes : fully supported | Yes : fully supported | No : not implemented Processing-time timers are not wired up. |
| Count triggers | Yes : fully supported Fully supported in streaming mode. In batch mode, elements are processed in the largest bundles possible, so count-based triggers are effectively meaningless. | No : partially supported Prism will double fire on count triggers | Yes : fully supported | Yes : fully supported | Partially : fully supported in batch mode | Yes : fully supported | Yes : fully supported | Yes : fully supported | Yes : fully supported | No : not implemented |
| Composite triggers | Yes : fully supported | Yes : fully supported | Yes : fully supported | Yes : fully supported | Partially : fully supported in batch mode | Yes : fully supported | Yes : fully supported | Partially : | Yes : fully supported | No : not implemented |
| Allowed lateness | Yes : fully supported Fully supported in streaming mode. In batch mode no data is ever late. | Yes : fully supported | Yes : fully supported | No | No : no streaming support in the runner | Yes : fully supported | Yes : fully supported | Partially : | Yes : fully supported | Yes : fully supported Allowed lateness and late-data dropping are applied by ReduceFnRunner. |
| Timers | Partially : non-merging windows Dataflow supports timers in non-merging windows. | Yes : fully supported | Partially : non-merging windows The Flink Runner supports timers in non-merging windows. | Partially : fully supported in batch mode | No : not implemented | No : not implemented | Partially : non-merging windows | Partially : | Yes : Partially | No : not implemented User timers are not wired to the harness. |
Last updated on 2026/08/28
Have you found everything you were looking for?
Was it all useful and clear? Is there anything that you would like to change? Let us know!