Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id B6639200B5A for ; Thu, 21 Jul 2016 03:42:29 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id B4FF3160A86; Thu, 21 Jul 2016 01:42:29 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id D9976160A64 for ; Thu, 21 Jul 2016 03:42:28 +0200 (CEST) Received: (qmail 22583 invoked by uid 500); 21 Jul 2016 01:42:28 -0000 Mailing-List: contact user-help@flink.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@flink.apache.org Delivered-To: mailing list user@flink.apache.org Received: (qmail 22573 invoked by uid 99); 21 Jul 2016 01:42:27 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Jul 2016 01:42:27 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 309E9C040A for ; Thu, 21 Jul 2016 01:42:27 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.429 X-Spam-Level: * X-Spam-Status: No, score=1.429 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id o6nGkR1tPNYV for ; Thu, 21 Jul 2016 01:42:25 +0000 (UTC) Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com [209.85.220.178]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id E90B45F366 for ; Thu, 21 Jul 2016 01:42:24 +0000 (UTC) Received: by mail-qk0-f178.google.com with SMTP id p74so61798337qka.0 for ; Wed, 20 Jul 2016 18:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=+oCgsUns6vtzfkIWgipjZjnJ7RSak/smlqg3AL0H+uY=; b=kEfn9g5zytACBZfatEne+dzSOa7Uhbeki82CI/5NLsgq359Oe3fTAm7sacs8dGpXXv s5bxQ+XVRag9liRF+1C4Cp4PZdPYySyZBPYx3rSB6CZF2Z46TQFPRivarFRktLbbwpn+ qKRGcOPaYplHjPrAJVJFPz+1Y+BN+8Jiz0WuOpXYdD2XOMmqtFjI5GVP/NXAwfzu1pem HFVe8TqVUTNGU0mg0R7Q9K8ffz/01L6Q2L7wpdOwQpVSUbIlnua3iVl2nhc8Ut0rfN0i h8segeSXkFKLrhVJoJDR4uxHoSKkF82aEgXP8DvP2DElpWKKLivzMv3Y5ob4QzQcOnJx bL7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=+oCgsUns6vtzfkIWgipjZjnJ7RSak/smlqg3AL0H+uY=; b=nEcFfVTxRPlnMtKob+QlastCkunux+OjGuf2dJgOwDa6JKubpBA+5O/53CAG6liYr9 MuVSB8gavTAZv8146sJQKuHyE/ZUmPB65Vrtr2A59Wefd7onnruidVsW3fBubDXth0Z5 ZDfAaV6AEnBHIQeJaxgqfBenSYuQA4wOdVbBtYTTx0lHwI0AJo1hlA23wOqxT1E2apst 9JlCFszHeWuQYqPZ4o9owR/5Lu1lr+bDRoT2WvJ8VFKNc3tfV2NwnMyfelw3U1ZktNoy b4SU+H8AQcI3mtVxLbMW8K6PMxZKlsG9DViDqZujjI73sBLDFRHeRXahscaAx7YBlW7V P1sA== X-Gm-Message-State: ALyK8tJL/LGe56uSvcUAmza1bep26mqNlDuL6OTbJNxWwIpGiB4H11G31WP0E5boZuA+Kk9Io9+CRfHl16lWSQ== X-Received: by 10.55.38.197 with SMTP id m66mr64437011qkm.208.1469065338096; Wed, 20 Jul 2016 18:42:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.139.4 with HTTP; Wed, 20 Jul 2016 18:41:58 -0700 (PDT) In-Reply-To: <2A57CC9D-A649-47D0-8DCE-BF965D62A8FF@uber.com> References: <2A57CC9D-A649-47D0-8DCE-BF965D62A8FF@uber.com> From: Vishnu Viswanath Date: Wed, 20 Jul 2016 21:41:58 -0400 Message-ID: Subject: Re: Processing windows in event time order To: user@flink.apache.org Content-Type: multipart/alternative; boundary=001a11457c06a10fec05381b6ddc archived-at: Thu, 21 Jul 2016 01:42:29 -0000 --001a11457c06a10fec05381b6ddc Content-Type: text/plain; charset=UTF-8 Hi David, You are right, the events in the window are not sorted according to the EventTime hence the processing is not done in an increasing order of timestamp. As you said, you will have to do the sorting yourself in your window function to make sure that you are processing the events in order. What Flink does is (when EventTime is set and timestamp is assigned), it will assign the elements to the Windows based on the EventTime, which otherwise (if using ProcessingTime) might have ended up in a different Window. (as per the ProcessingTime). This is as per my limited knowledge, other Flink experts can correct me if this is wrong. Thanks, Vishnu On Wed, Jul 20, 2016 at 9:30 PM, David Desberg wrote: > Hi all, > > In Flink, after setting the time characteristic to event time and properly > assigning timestamps/watermarks, time-based windows will be created based > upon event time. If we need to process events within a window in event time > order, we can sort the windowed values and process as necessary by applying > a WindowFunction. However, as I understand it, there is no guarantee that > time-based windows will be processed in time order. Is this correct? Or, if > we assume a watermarking system that (for example's sake) does not allow > any late events, is there a way within Flink to guarantee that windows will > be processed (via an applied WindowFunction) in strictly increasing time > order? > > If necessary, I can provide a more concrete explanation of what I mean/am > looking for. > > Thanks! > David --001a11457c06a10fec05381b6ddc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,

You are right, the= events in the window are not sorted according to the EventTime hence the p= rocessing is not done in an increasing order of timestamp.
As you= said, you will have to do the sorting yourself in your window function to = make sure that you are processing the events in order.

=
What Flink does is (when EventTime is set and timestamp is assigned), = it will assign the elements to the Windows based on the EventTime, which ot= herwise (if using ProcessingTime) might have ended up in a different Window= . (as per the ProcessingTime).

This is as per my l= imited knowledge, other Flink experts can correct me if this is wrong.

Thanks,
Vishnu=C2=A0

On Wed, Jul 20, 2016 at 9:30 PM, Da= vid Desberg <david.desberg@uber.com> wrote:
Hi all,

In Flink, after setting the time characteristic to event time and properly = assigning timestamps/watermarks, time-based windows will be created based u= pon event time. If we need to process events within a window in event time = order, we can sort the windowed values and process as necessary by applying= a WindowFunction. However, as I understand it, there is no guarantee that = time-based windows will be processed in time order. Is this correct? Or, if= we assume a watermarking system that (for example's sake) does not all= ow any late events, is there a way within Flink to guarantee that windows w= ill be processed (via an applied WindowFunction) in strictly increasing tim= e order?

If necessary, I can provide a more concrete explanation of what I mean/am l= ooking for.

Thanks!
David

--001a11457c06a10fec05381b6ddc--