Re: Periodic full stream aggregations

2015-04-21 Thread Gyula Fóra
Hey, The current code supports 2 types of aggregations, simple binary reduce: T,T=>T and also the grouped version for this, where the reduce function is applied per a user defined key (so there we keep a map of reduced values). This can already be used to implement fairly complex logic if we trans

Re: Periodic full stream aggregations

2015-04-21 Thread Bruno Cadonna
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gyula, fair enough! I used a bad example. What I really wanted to know is whether your code supports only aggregation like sum, min, and max where you need to pass only a value to the next aggregation or also more complex data structures, e.g., a

Re: Periodic full stream aggregations

2015-04-21 Thread Gyula Fóra
You are right, but you should never try to compute full stream median, thats the point :D On Tue, Apr 21, 2015 at 2:52 PM, Bruno Cadonna < cado...@informatik.hu-berlin.de> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Gyula, > > I read your comments of your PR. > > I have a ques

Re: Periodic full stream aggregations

2015-04-21 Thread Bruno Cadonna
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gyula, I read your comments of your PR. I have a question to this comment: "It only allows aggregations so we dont need to keep the full history in a buffer." What if the user implements an aggregation function like a median? For a median you n

Re: Periodic full stream aggregations

2015-04-21 Thread Gyula Fóra
I have opened a PR for this feature: https://github.com/apache/flink/pull/614 Cheers, Gyula On Tue, Apr 21, 2015 at 1:10 PM, Gyula Fóra wrote: > Thats a good idea, I will modify my PR to that :) > > Gyula > > On Tue, Apr 21, 2015 at 12:09 PM, Fabian Hueske wrote: > >> Is it possible to switch

Re: Periodic full stream aggregations

2015-04-21 Thread Gyula Fóra
Thats a good idea, I will modify my PR to that :) Gyula On Tue, Apr 21, 2015 at 12:09 PM, Fabian Hueske wrote: > Is it possible to switch the order of the statements, i.e., > > dataStream.every(Time.of(4,sec)).reduce(...) instead of > dataStream.reduce(...).every(Time.of(4,sec)) > > I think tha

Re: Periodic full stream aggregations

2015-04-21 Thread Fabian Hueske
Is it possible to switch the order of the statements, i.e., dataStream.every(Time.of(4,sec)).reduce(...) instead of dataStream.reduce(...).every(Time.of(4,sec)) I think that would be more consistent with the structure of the remaining API. Cheers, Fabian 2015-04-21 10:57 GMT+02:00 Gyula Fóra :

Re: Periodic full stream aggregations

2015-04-21 Thread Gyula Fóra
Hi Bruno, Of course you can do that as well. (That's the good part :p ) I will open a PR soon with the proposed changes (first without breaking the current Api) and I will post it here. Cheers, Gyula On Tuesday, April 21, 2015, Bruno Cadonna wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash:

Re: Periodic full stream aggregations

2015-04-21 Thread Bruno Cadonna
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gyula, I have a question regarding your suggestion. Can the current continuous aggregation be also specified with your proposed periodic aggregation? I am thinking about something like dataStream.reduce(...).every(Count.of(1)) Cheers, Bruno On

Periodic full stream aggregations

2015-04-20 Thread Gyula Fóra
Hey all, I think we are missing a quite useful feature that could be implemented (with some slight modifications) on top of the current windowing api. We currently provide 2 ways of aggregating (or reducing) over streams: doing a continuous aggregation and always output the aggregated value (whic